Re: [Caml-list] List.fold_left vs. Hashtbl.fold

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> ... but I'm curious about this "dubious" point. Is it something that has
> already been discussed in the context of OCaml and I've missed the
> relevant discussion? Or is it something there are results available
> elsewhere? Either way, pointers on that would be very much appreciated!

My personal issue with Scala syntax is that the scope of the anonymous
function is entirely implicit: if you write (li.map(_ + 1)) it will
desugar into (li.map (x => x + 1)) (apparently to the first
parenthesis level), but (if (_) foo else bar) desugars to (fun x => if
x foo bar), and ((_ : Int) + 1) to (fun x => (x : Int) + 1); there is
no explicit enclosing boundary, the scope is the "smallest expression
that contains the underscore" for some notion of "containing" that I
don't find particularly intuitive on the examples above.

I think implicit scopes are a "dubious" idea and would really want an
explicit construction to mark the scope of these doubly anonymous
functions. The problem is that you have to find a really light syntax,
as the value of this construction is precisely its concision. In my
young years I used to think that Camlp4 syntax extensions could be
beneficial, and I wrote an extension for this purpose (  :
http://bluestorm.info/camlp4/pa_holes.ml.html  ). It allows to write
for example (\ \2 \1) for the swap function: (\ ... ) delimits the
abstraction scope and variable are written \n (_ would be another
compromise: less expressive on the ordering, but shorter).

Another upside of these syntax is that they give light thunking for
free: proponents of lazy evaluation like the fact that some control
construct can be defined as simple functions under a lazy stragy,
while writing
  if b (fun () -> e1) (fun () -> e2)
is too painful to be viable in ML. Well,
  if b (\ e1) (\ e2)
(using the convenition that there is always at least one parameter) is better.

> And thanks for your efforts in fueling language design discussion on
> this list!, I really appreciate it and the resulting discussions.

It's a double-edged sword: it's easy to get lost in mundane details or
ultimately void debates about "the next programming language" on a
list that is really about OCaml users. I wasn't sure already that
discussion of Scala's implicit function syntax was in-topic, but well.
I'll try to keep my side of the discussion not too long.

Daniel Bünzli wrote:
> I have the *impression* that currying is essential when you want to devise dsls and combinators that integrate naturally in the host language. But I may be wrong.

I don't know. "function application is just space" is indeed a
convenient syntax to emulate other syntaxes (for example embed a
concatenative language through cunning continuation-passing-style),
but that doesn't need to go away with non-currified functions, which
is about applying all arguments, not necessarily forcing a tupled
syntax. Only partial application would be less convenient (but you can
still explicitly define functions-that-return-functions). That would
certainly need more experimentation.

On Fri, Nov 30, 2012 at 11:06 AM, Stefano Zacchiroli <zack@upsilon.cc> wrote:
> On Fri, Nov 30, 2012 at 10:53:21AM +0100, Gabriel Scherer wrote:
>> My personal opinion is that currying is overrated
>
> Very much agreed!
>
>> and we should think about language design without currying, and with a
>> nice short syntax for partial application (inspired by Scala's
>> admittedly dubious (foo _ bar) syntax for (fun x -> foo x bar)).
>
> ... but I'm curious about this "dubious" point. Is it something that has
> already been discussed in the context of OCaml and I've missed the
> relevant discussion? Or is it something there are results available
> elsewhere? Either way, pointers on that would be very much appreciated!
>
> And thanks for your efforts in fueling language design discussion on
> this list!, I really appreciate it and the resulting discussions.
>
> Cheers.
> --
> Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
> Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
> Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
> « the first rule of tautology club is the first rule of tautology club »
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs