[Caml-list] ReasonML concrete syntax

[Caml-list] ReasonML concrete syntax

[Robert Muller]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

The team developing ReasonML seems to be experimenting with concrete syntax
in an effort to make it feel as familiar and natural as possible to
JavaScript programmers. Seems like a good idea. But the present version
seems to hardwire parentheses awkwardly for function definitions and calls.
Parentheses are required for both function definitions and calls. So one
writes

let incr(n) = n + 1       and   incr(5)

but not

let incr n = n + 1        or    incr 5

Fair enough, but for multi-argument functions the parser seems to unroll
the parenthesized items (both parameters & arguments) to leave curried
functions. E.g.,

let add(m, n) = m + n  or equivalently let add = (m, n) => m + n

then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, n) =
... isn't a pattern matching a pair, it's the JS-style sequence of input
parameters and the definition unrolls to let add = (m) => (n) => ... . So
add(5) : int -> int and all three of add(5, 3), add(5)(3) and { let add5 =
add(5);  add5(3) } are 8. There's probably a way to write an add function
of type int * int -> int, but I don't know how to write it.

I'm wondering what the OCaml community makes of this. I find it awkward.
Bob Muller

[-- Attachment #2: Type: text/html, Size: 1501 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

Hi Bob, you can find more details about the syntax change and discussion in
this slightly outdated PR: https://github.com/facebook/reason/pull/1299

Long story short, you can write let add((m, n)) = m + n.

Note that the ReasonML project actually includes several long-time members
of the OCaml community. I feel that the new syntax has very well received
in the JavaScript community and it will lead to wider OCaml adoption. It's
a win-win situation.

Regards,

Yawar

On Sun, Dec 10, 2017 at 1:12 PM, Robert Muller <robert.muller2@gmail.com>
wrote:

> The team developing ReasonML seems to be experimenting with concrete
> syntax in an effort to make it feel as familiar and natural as possible to
> JavaScript programmers. Seems like a good idea. But the present version
> seems to hardwire parentheses awkwardly for function definitions and calls.
> Parentheses are required for both function definitions and calls. So one
> writes
>
> let incr(n) = n + 1       and   incr(5)
>
> but not
>
> let incr n = n + 1        or    incr 5
>
> Fair enough, but for multi-argument functions the parser seems to unroll
> the parenthesized items (both parameters & arguments) to leave curried
> functions. E.g.,
>
> let add(m, n) = m + n  or equivalently let add = (m, n) => m + n
>
> then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, n) =
> ... isn't a pattern matching a pair, it's the JS-style sequence of input
> parameters and the definition unrolls to let add = (m) => (n) => ... . So
> add(5) : int -> int and all three of add(5, 3), add(5)(3) and { let add5 =
> add(5);  add5(3) } are 8. There's probably a way to write an add function
> of type int * int -> int, but I don't know how to write it.
>
> I'm wondering what the OCaml community makes of this. I find it awkward.
> Bob Muller
>
>
>

[-- Attachment #2: Type: text/html, Size: 2513 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Viet Le]

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

Such a terrible way to cave in to appear more JS-esque. I really hope OCaml
community doesn't adopt this style because it's confusing, inelegant and
superficial.

Viet.

On Mon, 11 Dec 2017 at 00:11, Yawar Amin <yawar.amin@gmail.com> wrote:

> Hi Bob, you can find more details about the syntax change and discussion
> in this slightly outdated PR: https://github.com/facebook/reason/pull/1299
>
> Long story short, you can write let add((m, n)) = m + n.
>
> Note that the ReasonML project actually includes several long-time members
> of the OCaml community. I feel that the new syntax has very well received
> in the JavaScript community and it will lead to wider OCaml adoption. It's
> a win-win situation.
>
> Regards,
>
> Yawar
>
> On Sun, Dec 10, 2017 at 1:12 PM, Robert Muller <robert.muller2@gmail.com>
> wrote:
>
>> The team developing ReasonML seems to be experimenting with concrete
>> syntax in an effort to make it feel as familiar and natural as possible to
>> JavaScript programmers. Seems like a good idea. But the present version
>> seems to hardwire parentheses awkwardly for function definitions and calls.
>> Parentheses are required for both function definitions and calls. So one
>> writes
>>
>> let incr(n) = n + 1       and   incr(5)
>>
>> but not
>>
>> let incr n = n + 1        or    incr 5
>>
>> Fair enough, but for multi-argument functions the parser seems to unroll
>> the parenthesized items (both parameters & arguments) to leave curried
>> functions. E.g.,
>>
>> let add(m, n) = m + n  or equivalently let add = (m, n) => m + n
>>
>> then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, n)
>> = ... isn't a pattern matching a pair, it's the JS-style sequence of input
>> parameters and the definition unrolls to let add = (m) => (n) => ... . So
>> add(5) : int -> int and all three of add(5, 3), add(5)(3) and { let add5 =
>> add(5);  add5(3) } are 8. There's probably a way to write an add function
>> of type int * int -> int, but I don't know how to write it.
>>
>> I'm wondering what the OCaml community makes of this. I find it awkward.
>> Bob Muller
>>
>>
>>
> --
Kind regards,
Viet

[-- Attachment #2: Type: text/html, Size: 3199 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Ian Zimmerman]

On 2017-12-11 05:50, Viet Le wrote:

> Such a terrible way to cave in to appear more JS-esque. I really hope
> OCaml community doesn't adopt this style because it's confusing,
> inelegant and superficial.

They like it _because_ it is ugly.

<hysterical-rant>Trumpism has civilization on the ropes.</hysterical-rant>

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [Caml-list] ReasonML concrete syntax

[Sven SAULEAU]

> They like it_because_  it is ugly.

This is completely wrong. The Reasonml team folks are very close to OCaml (as well as Facebook projects in general).

Please read the email I just wrote, there's more detail about that move.


On 11/12/2017 07:45, Ian Zimmerman wrote:
> On 2017-12-11 05:50, Viet Le wrote:
>
>> Such a terrible way to cave in to appear more JS-esque. I really hope
>> OCaml community doesn't adopt this style because it's confusing,
>> inelegant and superficial.
> They like it _because_ it is ugly.
>
> <hysterical-rant>Trumpism has civilization on the ropes.</hysterical-rant>
>

--

Sven SAULEAU

+33 6 28 69 51 44

Re: [Caml-list] ReasonML concrete syntax

[Sven SAULEAU]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

Hi,

The reason behind that move (from Reasonml version 2 to 3), is that it feels more natural to JavaScript developers.

Since it's quite a new language and their main target are JS developers this kinda make sense to me but I agree with Viet, as a ML fan I don't like this new syntax.

Also I hope it won't confuse them about functional programming concepts. Partial application for example looks not clear at all that way:

let add = (x, y) => x + y;
let addFive = add(5);
let eleven = addFive(6);
let twelve = addFive(7);

In JavaScript add* functions clearly only take one argument.

has very well received in the JavaScript community and it will lead to wider OCaml adoption

I'm afraid it probably won't, if they are used to the JavaScript syntax. Reasonml is also meant to be used in the web more than used through OCaml.

Sven.

On 11/12/2017 06:50, Viet Le wrote:
Such a terrible way to cave in to appear more JS-esque. I really hope OCaml community doesn't adopt this style because it's confusing, inelegant and superficial.

Viet.

On Mon, 11 Dec 2017 at 00:11, Yawar Amin <yawar.amin@gmail.com<mailto:yawar.amin@gmail.com>> wrote:
Hi Bob, you can find more details about the syntax change and discussion in this slightly outdated PR: https://github.com/facebook/reason/pull/1299

Long story short, you can write let add((m, n)) = m + n.

Note that the ReasonML project actually includes several long-time members of the OCaml community. I feel that the new syntax has very well received in the JavaScript community and it will lead to wider OCaml adoption. It's a win-win situation.

Regards,

Yawar

On Sun, Dec 10, 2017 at 1:12 PM, Robert Muller <robert.muller2@gmail.com<mailto:robert.muller2@gmail.com>> wrote:
The team developing ReasonML seems to be experimenting with concrete syntax in an effort to make it feel as familiar and natural as possible to JavaScript programmers. Seems like a good idea. But the present version seems to hardwire parentheses awkwardly for function definitions and calls. Parentheses are required for both function definitions and calls. So one writes

let incr(n) = n + 1       and   incr(5)

but not

let incr n = n + 1        or    incr 5

Fair enough, but for multi-argument functions the parser seems to unroll the parenthesized items (both parameters & arguments) to leave curried functions. E.g.,

let add(m, n) = m + n  or equivalently let add = (m, n) => m + n

then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, n) = ... isn't a pattern matching a pair, it's the JS-style sequence of input parameters and the definition unrolls to let add = (m) => (n) => ... . So add(5) : int -> int and all three of add(5, 3), add(5)(3) and { let add5 = add(5);  add5(3) } are 8. There's probably a way to write an add function of type int * int -> int, but I don't know how to write it.

I'm wondering what the OCaml community makes of this. I find it awkward.
Bob Muller



--
Kind regards,
Viet


--

Sven SAULEAU

+33 6 28 69 51 44

[-- Attachment #2: Type: text/html, Size: 6469 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Evgeny Khramtsov]

Mon, 11 Dec 2017 07:50:02 +0100
Sven SAULEAU <sven.sauleau@xtuc.fr> wrote:

> The reason behind that move (from Reasonml version 2 to 3), is that
> it feels more natural to JavaScript developers.

If you develop software for idiots, only idiots will use it (c)

Come on, if you cannot learn a new syntax, you're an idiot. No
exceptions.

Re: [Caml-list] ReasonML concrete syntax

[=?gb18030?B?Qm9i?=]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1188 bytes --]

Let¡¯s be civil. Note that I did not write a single line of reason, but I understand it¡¯s intention to use a more familiar function application syntax and it seems to be appreciated by quite a few people.
 There are issues though, the parens are overloaded in too many context, if it uses ¡®[¡® for tuple like what typescript did, then such ambiguity would be removed 


·¢×ÔÎÒµÄiPhone

------------------ Original ------------------
From: Evgeny Khramtsov <xramtsov@gmail.com>
Date: ÖÜÒ»,12ÔÂ 11,2017 3:12 ÏÂÎç
To: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] ReasonML concrete syntax



Mon, 11 Dec 2017 07:50:02 +0100
Sven SAULEAU <sven.sauleau@xtuc.fr> wrote:

> The reason behind that move (from Reasonml version 2 to 3), is that
> it feels more natural to JavaScript developers.

If you develop software for idiots, only idiots will use it (c)

Come on, if you cannot learn a new syntax, you're an idiot. No
exceptions.

-- 
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

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Evgeny Khramtsov]

Mon, 11 Dec 2017 15:22:14 +0800
"Bob" <bob.hongbo.zhang@foxmail.com> wrote:

> but I understand it’s intention to use a more familiar function
> application syntax

Well, I understand this too, but this doesn't change my opinion.

Re: [Caml-list] ReasonML concrete syntax

[Paolo Donadeo]

On Mon, Dec 11, 2017 at 7:54 AM, Evgeny Khramtsov <xramtsov@gmail.com> wrote:
> If you develop software for idiots, only idiots will use it (c)
> Come on, if you cannot learn a new syntax, you're an idiot. No
> exceptions.

I couldn't disagree more.

If on one side what you state ("if you cannot learn a new syntax,
you're an idiot") is essentially true, on the other side "no
exception" means that you don't count as an exception. If you cannot
put a pair of parentesis around parameters...

To be clear I consider the JS syntax, in the context of functional
programming, ugly and inelegant but all in all OCaml is not that
bright example of elegant syntax. I like OCaml because I can go beyond
appearance of the syntax and because the OCaml community is
traditionally a small but strong community of real and practical
programmers.

And having OCaml (because ReasonML is OCaml) running in the browser is
priceless, with or without a couple of parentesis.


-- 
Paolo

Re: [Caml-list] ReasonML concrete syntax

[Guillaume Huysmans]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

OCaml already runs in browsers thanks to js_of_ocaml or BuckleScript,
there's no need for another syntax.


On Mon, Dec 11, 2017 at 7:54 AM, Evgeny Khramtsov <xramtsov@gmail.com>
wrote:

> If you develop software for idiots, only idiots will use it (c)
> Come on, if you cannot learn a new syntax, you're an idiot. No
> exceptions.

I couldn't disagree more.

If on one side what you state ("if you cannot learn a new syntax,
you're an idiot") is essentially true, on the other side "no
exception" means that you don't count as an exception. If you cannot
put a pair of parentesis around parameters...

To be clear I consider the JS syntax, in the context of functional
programming, ugly and inelegant but all in all OCaml is not that
bright example of elegant syntax. I like OCaml because I can go beyond
appearance of the syntax and because the OCaml community is
traditionally a small but strong community of real and practical
programmers.

And having OCaml (because ReasonML is OCaml) running in the browser is
priceless, with or without a couple of parentesis.


--
Paolo

--
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

[-- Attachment #2: Type: text/html, Size: 2234 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Paolo Donadeo]

On Sun, Dec 17, 2017 at 5:01 PM, Guillaume Huysmans
<ghuysmans99@gmail.com> wrote:
> OCaml already runs in browsers thanks to js_of_ocaml or BuckleScript,
> there's no need for another syntax.

I know, I used both ;-)

So, actually, why caring about the syntax of another language?

Honestly I don't understand this argument. Someone out there created
another (concrete) syntax for OCaml. If you like it use it otherwise
let them alone.

My point was that there is a huge difference between "I don't like
ReasonML syntax" and "ReasonML users are idiots".


-- 
Paolo

Re: [Caml-list] ReasonML concrete syntax

[Ian Zimmerman]

On 2017-12-17 17:55, Paolo Donadeo wrote:

> So, actually, why caring about the syntax of another language?

Because, being backed by FB, Reason will _become_ the normal Ocaml, and
even those who dislike it will in practice be forced to use it.  That is
the core of this disagreement.

> Honestly I don't understand this argument. Someone out there created
> another (concrete) syntax for OCaml. If you like it use it otherwise
> let them alone.

But _you_ won't be "let alone" for long.

> My point was that there is a huge difference between "I don't like
> ReasonML syntax" and "ReasonML users are idiots".

Yes, I agree.  I'm completely with the former, but I never said the
latter nor do I support it.  Nonetheless there are many people who are
no idiots but whose choices I reflexively reject.  (My first post in
this thread provides some context.)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [Caml-list] ReasonML concrete syntax

[Robert Muller]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Sun, Dec 17, 2017 at 3:13 PM, Ian Zimmerman <itz@very.loosely.org> wrote:

> On 2017-12-17 17:55, Paolo Donadeo wrote:
>
> > So, actually, why caring about the syntax of another language?
>
> Because, being backed by FB, Reason will _become_ the normal Ocaml, and
> even those who dislike it will in practice be forced to use it.  That is
> the core of this disagreement.
>

Exactly! Reason may be great, but OCaml is effectively being expropriated
by a huge, powerful organization. Reason is presently just an "alternate
syntax" but if it's successful, OCaml could easily devolve into an obscure
early intermediate language in a Reason compiler.

As I understand it, the OCaml community isn't paying much attention to the
Reason design process. That process is heavily influenced by JS so there
are ample opportunities for unrepairable mistakes.

RM


> > Honestly I don't understand this argument. Someone out there created
> > another (concrete) syntax for OCaml. If you like it use it otherwise
> > let them alone.
>
> But _you_ won't be "let alone" for long.
>
> > My point was that there is a huge difference between "I don't like
> > ReasonML syntax" and "ReasonML users are idiots".
>
> Yes, I agree.  I'm completely with the former, but I never said the
> latter nor do I support it.  Nonetheless there are many people who are
> no idiots but whose choices I reflexively reject.  (My first post in
> this thread provides some context.)
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet, fetch the TXT record for the domain.
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 3007 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

Hi Bob,

On Sun, Dec 17, 2017 at 3:49 PM, Robert Muller <robert.muller2@gmail.com>
wrote:

> [...]
> As I understand it, the OCaml community isn't paying much attention to the
> Reason design process. That process is heavily influenced by JS so there
> are ample opportunities for unrepairable mistakes.
>

You have a misunderstanding on this matter. The Reason team contains some
very seasoned OCaml hackers. The new syntax of version 3 was mostly
designed (IIUC) and implemented by the maintainer of Merlin. These are not
script kiddies trying to push JavaScript sensibilities everywhere. These
are OCaml people who are trying very carefully to design a syntax that
appeals to a massive number of people.

Also, you have another misunderstanding about reparability. One of the key
components of the Reason toolkit is refmt, the reformatting tool, which
they use to automatically and seamlesly upgrade users to the new syntax. In
fact this is how they pulled off the version 2 -> version 3 syntax
upgrade--they provided a shell script wrapper with the correct invocation
to do the syntax change.

So you see, the Reason project has made it so it can easily back out of
mistakes. They've thought about this very carefully. I repeat my invitation
to you to come and talk to them in their chat server, discord.gg/reasonml .
Perhaps that will give you some reassurance.

Regards,

Yawar

[-- Attachment #2: Type: text/html, Size: 1948 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Evgeny Khramtsov]

Sun, 17 Dec 2017 20:34:20 -0500
Yawar Amin <yawar.amin@gmail.com> wrote:

> These
> are OCaml people who are trying very carefully to design a syntax that
> appeals to a massive number of people.

There is a very similar story: Erlang and Elixir. If somebody doesn't
know: Elixir runs in Erlang VM (BEAM) and has Ruby-like syntax (Erlang,
on its turn, has obscure for many Prolog-like syntax). No doubt, Elixir
became more popular than Erlang (at least, judging by Github stars),
but still not popular enough (below top20 in any language charts). I
think this is because it's still functional language and this distracts
many. Furthermore, such separation splitted the community into two
camps, writing the same tools/programs, but only in different languages.
What's worse, now all job offers contain Erlang/Elixir requirement
(which makes no sense to me, frankly).

TL;DR: I doubt those guys from Facebook can make Reason significantly
more popular than OCaml, no matter what syntax they choose: they also
need to change functional paradigm.

Re: [Caml-list] ReasonML concrete syntax

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Mon, Dec 18, 2017 at 5:43 PM Evgeny Khramtsov <xramtsov@gmail.com> wrote:

>
> There is a very similar story: Erlang and Elixir. If somebody doesn't
> know: Elixir runs in Erlang VM (BEAM) and has Ruby-like syntax (Erlang,
> on its turn, has obscure for many Prolog-like syntax). No doubt, Elixir
> became more popular than Erlang (at least, judging by Github stars),
> but still not popular enough (below top20 in any language charts). I
> think this is because it's still functional language and this distracts
> many. Furthermore, such separation splitted the community into two
> camps, writing the same tools/programs, but only in different languages.
> What's worse, now all job offers contain Erlang/Elixir requirement
> (which makes no sense to me, frankly).
>
>
FWIW, I think the Erlang community is greatly benefiting from the Elixir
community and vice versa. I'd hope the same thing happens with ReasonML and
OCaml.

Elixir got a pretty firm ground to stand on since you have many years of
(industrial) backing in the Erlang ecosystem. But a lot of the better
improvements in the quality-of-life of a programmer is a direct result of
Elixir's core team wanting to improve notation, error reporting and so on
for the developer. These changes are definitely improving Erlang as well.

I think it is wrong to see these things as "wars". People, when
programming, are subjective and prefer different notations. I've always
been partial to statically typed ML languages such as OCaml and Standard
ML, and I find their notation more clear than e.g., the Erlang or Haskell
notation[0]. But judging by people in general, '{' / '}' bracketed notation
stemming from a language such a C looks to be extremely popular and familar
to people. To the point where "Erlang syntax is ugly", in which as much is
misunderstood about its semantics as are its syntax.

The key point is that you have a large group of programmers, mostly
Javascript, Python or Ruby people, who would never ever pick up Erlang due
to its syntax. But they'll gladly pick Elixir as their core language. All
we have to teach them is proper error handling Erlang/OTP style and they'll
easily give back to the community at large. If there are a good argument
for diversity in an ecosystem, this is really it.

[0] I may be "Erlang user of the year, 2017", and have many years of Erlang
experience, but I've always lamented that the language has no static type
system.

[-- Attachment #2: Type: text/html, Size: 3043 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Gary Trakhman]

[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]

Being an experienced clojure/lisp expatriat, it's easy to not get too
attached to syntax, since few see the value of the one I like the most.
Ocaml syntax was pretty strange, but the mental model of the code itself
was not that different from what I was doing before.  Reason looks like
another half day or so of learning.  I see these as fixed costs.  It's
usually in the language community's interest to lower the barrier to entry
because it increases the chance of a future contribution.  I don't really
see how an additional syntax can threaten or take away from ocaml in the
large.  And my personal opinion is, 'whatever, it's just syntax'.  The
repetitive things should be easy and small and the weird occasional stuff
can be weird.  Tuples fall into the bucket of things I don't usually want
to use, so making a notation sacrifice there seems relatively fine.  In
fact, I'm pretty annoyed by semicolon separators in lists/arrays and the
general leading-semicolon style, since no other language does it that way.
Why shouldn't the more common use-case be 'terser'? Bare tuples are
confusing like that.

I guess when I see a bikeshedding flame war like this, I just wonder what
other silent bystanders like me think, who are happy to be using an
expressive, type-safe language like ocaml (hey, it's not java) but not
specifically attached to any implementation detail.  I think it's pretty
interesting what the Reason team is doing with cross-syntax compilers,
since having great AST-level tooling makes writing editor tooling and
ultimately end user code much easier, and that addresses recurring costs
that I face day to day at work more than any syntax does.

On Mon, Dec 18, 2017 at 12:01 PM Jesper Louis Andersen <
jesper.louis.andersen@gmail.com> wrote:

> On Mon, Dec 18, 2017 at 5:43 PM Evgeny Khramtsov <xramtsov@gmail.com>
> wrote:
>
>>
>> There is a very similar story: Erlang and Elixir. If somebody doesn't
>> know: Elixir runs in Erlang VM (BEAM) and has Ruby-like syntax (Erlang,
>> on its turn, has obscure for many Prolog-like syntax). No doubt, Elixir
>> became more popular than Erlang (at least, judging by Github stars),
>> but still not popular enough (below top20 in any language charts). I
>> think this is because it's still functional language and this distracts
>> many. Furthermore, such separation splitted the community into two
>> camps, writing the same tools/programs, but only in different languages.
>> What's worse, now all job offers contain Erlang/Elixir requirement
>> (which makes no sense to me, frankly).
>>
>>
> FWIW, I think the Erlang community is greatly benefiting from the Elixir
> community and vice versa. I'd hope the same thing happens with ReasonML and
> OCaml.
>
> Elixir got a pretty firm ground to stand on since you have many years of
> (industrial) backing in the Erlang ecosystem. But a lot of the better
> improvements in the quality-of-life of a programmer is a direct result of
> Elixir's core team wanting to improve notation, error reporting and so on
> for the developer. These changes are definitely improving Erlang as well.
>
> I think it is wrong to see these things as "wars". People, when
> programming, are subjective and prefer different notations. I've always
> been partial to statically typed ML languages such as OCaml and Standard
> ML, and I find their notation more clear than e.g., the Erlang or Haskell
> notation[0]. But judging by people in general, '{' / '}' bracketed notation
> stemming from a language such a C looks to be extremely popular and familar
> to people. To the point where "Erlang syntax is ugly", in which as much is
> misunderstood about its semantics as are its syntax.
>
> The key point is that you have a large group of programmers, mostly
> Javascript, Python or Ruby people, who would never ever pick up Erlang due
> to its syntax. But they'll gladly pick Elixir as their core language. All
> we have to teach them is proper error handling Erlang/OTP style and they'll
> easily give back to the community at large. If there are a good argument
> for diversity in an ecosystem, this is really it.
>
> [0] I may be "Erlang user of the year, 2017", and have many years of
> Erlang experience, but I've always lamented that the language has no static
> type system.
>

[-- Attachment #2: Type: text/html, Size: 5231 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Evgeny Khramtsov]

Mon, 18 Dec 2017 17:00:33 +0000
Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:

> FWIW, I think the Erlang community is greatly benefiting from the
> Elixir community and vice versa. I'd hope the same thing happens with
> ReasonML and OCaml.  

I disagree. Those requests in my bugtracker "Make it work with Elixir"
are annoying.

> Elixir got a pretty firm ground to stand on since you have many years
> of (industrial) backing in the Erlang ecosystem. But a lot of the
> better improvements in the quality-of-life of a programmer is a
> direct result of Elixir's core team wanting to improve notation,
> error reporting and so on for the developer. These changes are
> definitely improving Erlang as well.  

I don't see this as an improvement to Erlang. This can be considered
by some as an improvement *over* Erlang, but in fact Elixir community
doesn't bring anything back. I'm maintaining software with around 20
dependencies, none of them are in Elixir.

> I think it is wrong to see these things as "wars". People, when
> programming, are subjective and prefer different notations. I've
> always been partial to statically typed ML languages such as OCaml
> and Standard ML, and I find their notation more clear than e.g., the
> Erlang or Haskell notation[0]. But judging by people in general,
> '{' / '}' bracketed notation stemming from a language such a C looks
> to be extremely popular and familar to people. To the point where
> "Erlang syntax is ugly", in which as much is misunderstood about its
> semantics as are its syntax.  

My point is actually the syntax doesn't matter a lot. There are really
great underrated languages because of this bias (Red/System is such an
example, where the code `f x (g y)` could be written as `f x g y`, i.e.
without brackets at all). But I have a problem learning new syntax just
to appease the majority. And seems like now I have to do this, simply
because the job market has changed. What if I say you must learn
Reason, like it or not?

> The key point is that you have a large group of programmers, mostly
> Javascript, Python or Ruby people, who would never ever pick up
> Erlang due to its syntax. But they'll gladly pick Elixir as their
> core language. All we have to teach them is proper error handling
> Erlang/OTP style and they'll easily give back to the community at
> large. If there are a good argument for diversity in an ecosystem,
> this is really it.  

Yah, like, increasing userbase on 2%. Sounds great :)

> [0] I may be "Erlang user of the year, 2017", and have many years of
> Erlang experience, but I've always lamented that the language has no
> static type system.  

Lacking the type system is definitely one of the main disadvantages of
Erlang (or Elixir), I agree.

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Sun, Dec 17, 2017 at 3:49 PM, Robert Muller <robert.muller2@gmail.com>
wrote:

> [...]
> Exactly! Reason may be great, but OCaml is effectively being expropriated
> by a huge, powerful organization.
>

Also, sorry, but this is pure hyperbole.

The Reason team has a select few people who have to, like any other tools
team, make the case to every potential internal client about why to use
their tool. They don't automatically get full Facebook backing just because
they exist. In fact, they have to compete against the much more well-known
Flow project for JavaScript type annotations. Their biggest win so far as
is they're migrating the Facebook Messenger webapp to Reason and are about
halfway there.

In fact they are tossing around the idea of building tools that
automatically display your OCaml code to you in your favourite syntax, so
you don't have to care about what others are using.

So it's far from a foregone conclusion that Reason syntax will take over
the OCaml ecosystem.

Regards,

Yawar

[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hi Sven,

On Mon, Dec 11, 2017 at 1:50 AM, Sven SAULEAU <sven.sauleau@xtuc.fr> wrote:

> [...]
> I'm afraid it probably won't, if they are used to the JavaScript syntax.
> Reasonml is also meant to be used in the web more than used through OCaml.
>

ReasonML adoption automatically means OCaml adoption, because ReasonML _is_
OCaml. People will be learning about and using HM type inference, modules
and functors, polymorphic variants, and all the good stuff. Don't let the
syntax fool you ;-)

Also, ReasonML itself is meant to target all platforms that OCaml itself
targets. Right now the Reason team is focusing on the JavaScript + React
use case to prove out the technology and appeal to a wide base. But they
also use jbuilder and opam to target bytecode and native. There are no
restrictions.

By the way, to the people calling the syntax ugly and its users idiots,
please tone yourselves down and think about why OCaml has been around in a
niche for 20 years but Rust took off in less than five.

Thanks,

Yawar

[-- Attachment #2: Type: text/html, Size: 1503 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Sven SAULEAU]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

Yawar,

Yes, you're right. Once they will get those concepts I hope the syntax isn't a blocker anymore.

On 11/12/2017 16:51, Yawar Amin wrote:
Hi Sven,

On Mon, Dec 11, 2017 at 1:50 AM, Sven SAULEAU <sven.sauleau@xtuc.fr<mailto:sven.sauleau@xtuc.fr>> wrote:

[...]

I'm afraid it probably won't, if they are used to the JavaScript syntax. Reasonml is also meant to be used in the web more than used through OCaml.

ReasonML adoption automatically means OCaml adoption, because ReasonML _is_ OCaml. People will be learning about and using HM type inference, modules and functors, polymorphic variants, and all the good stuff. Don't let the syntax fool you ;-)

Also, ReasonML itself is meant to target all platforms that OCaml itself targets. Right now the Reason team is focusing on the JavaScript + React use case to prove out the technology and appeal to a wide base. But they also use jbuilder and opam to target bytecode and native. There are no restrictions.

By the way, to the people calling the syntax ugly and its users idiots, please tone yourselves down and think about why OCaml has been around in a niche for 20 years but Rust took off in less than five.

Thanks,

Yawar


--

Sven SAULEAU

+33 6 28 69 51 44

[-- Attachment #2: Type: text/html, Size: 2158 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[David Brown]

On Mon, Dec 11, 2017 at 10:51:57AM -0500, Yawar Amin wrote:

>By the way, to the people calling the syntax ugly and its users idiots, please
>tone yourselves down and think about why OCaml has been around in a niche for
>20 years but Rust took off in less than five.

I think this is deeper than just syntax.  Rust has had the advantage
of being able to learn from everything that happened with languages in
the interim (both good and bad).

Although, I do think I'm a lot less bothered by syntax differences
than many other programmers are, I do remember a distinct learning
period with Ocaml that was essentially how to write various constructs
in its syntax.  I know of several other developers that came away from
an Ocaml experience with a bad taste, just because of the syntax.

But, I do think there are a few things Rust has gotten right that have
contributed to its taking off:

  - The cargo "culture".  Somehow, they managed to get the development
    of properly-versioned, well-encapsulated packages (crates) to be
    part of the culture of the language.  Starting with the "cargo"
    tool really helped this a lot.

  - Tied to this, management of the namespace of packages.  Every
    crate lives in its own namespace, and the imports between the
    crates are explicit (and don't have to be the same for a given
    dependency).  This allows conflicting dependencies to be resolved
    by just bringing in both versions.  (The language's strong
    distaste of global mutables helps this as well).

The first is kind of a hard thing to bring to an existing language
culture, although I think Ocaml is doing a pretty good job with this.
The second is a problem I've run into with Ocaml.  The ML basis system
handles this quite well, so this is clearly something that can easily
be handled in a language like Ocaml, but it would be challenging to
change the way modules and namespaces work without significantly
breaking existing code.

Personally, I've been doing a lot of Rust programming recently,
because it is a reasonable language, and there are likely crates.  I
do wish I had something, though, with garbage collection, and a strong
type system, and would really love to see Ocaml (or something derived
from it) fit this.  A vast majority of the code I write does not need
the complexity of the memory management and borrow checker from Rust,
but I want the rest of the infrastructure around the language.

David

Re: [Caml-list] ReasonML concrete syntax

[Louis Roché]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

> By the way, to the people calling the syntax ugly and its users idiots,
> please tone yourselves down and think about why OCaml has been around in a
> niche for 20 years but Rust took off in less than five.
>

"That's the reason why IT is a pop culture, not an engineering field"

[-- Attachment #2: Type: text/html, Size: 626 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

With this invaluable insight, I believe this discussion is concluded.

On Mon, Dec 11, 2017 at 10:49 PM, Louis Roché <louis@louisroche.net> wrote:

>
> By the way, to the people calling the syntax ugly and its users idiots,
>> please tone yourselves down and think about why OCaml has been around in a
>> niche for 20 years but Rust took off in less than five.
>>
>
> "That's the reason why IT is a pop culture, not an engineering field"
>

[-- Attachment #2: Type: text/html, Size: 1092 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Oliver Bandel]

Zitat von Louis Roché <louis@louisroche.net> (Tue, 12 Dec 2017 03:49:25 +0000)

>> By the way, to the people calling the syntax ugly and its users idiots,
>> please tone yourselves down and think about why OCaml has been around in a
>> niche for 20 years but Rust took off in less than five.
>>
>
> "That's the reason why IT is a pop culture, not an engineering field"


Which really means:

   "That's the reason why IT is a pop culture, not a popculture."

Re: [Caml-list] ReasonML concrete syntax

[Gerd Stolpmann]

[-- Attachment #1.1: Type: text/plain, Size: 2563 bytes --]

Hi,

funnily I made similar decision in the programming language I'm
currently developing (because of the commercial background it's closed
source so far, so no pointer). The reasoning is simply that "normal"
people are so used to writing functions with the parenthesized notation
that they do not even recognize functions without. For tuples, there is
a separate notation with square brackets in my language, so no conflict
(you can still write tuplified functions). Another reason is that
notations that do not have a clear syntactical end mark are more
difficult to understand (although, with currified functions this is only
an illusion).

In short, the argument is that f(x1,g(x2,x3)) looks more familiar than f
x1 (g x2 x3).

Personally I dislike that, but I'm not normal, and my language is not
designed for myself.

Gerd


On 10.12.17 19:12, Robert Muller wrote:
> The team developing ReasonML seems to be experimenting with concrete
> syntax in an effort to make it feel as familiar and natural as
> possible to JavaScript programmers. Seems like a good idea. But the
> present version seems to hardwire parentheses awkwardly for function
> definitions and calls. Parentheses are required for both function
> definitions and calls. So one writes
>
> let incr(n) = n + 1       and   incr(5)
>
> but not
>
> let incr n = n + 1        or    incr 5
>
> Fair enough, but for multi-argument functions the parser seems to
> unroll the parenthesized items (both parameters & arguments) to leave
> curried functions. E.g.,
>
> let add(m, n) = m + n  or equivalently let add = (m, n) => m + n
>
> then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m,
> n) = ... isn't a pattern matching a pair, it's the JS-style sequence
> of input parameters and the definition unrolls to let add = (m) => (n)
> => ... . So add(5) : int -> int and all three of add(5, 3), add(5)(3)
> and { let add5 = add(5);  add5(3) } are 8. There's probably a way to
> write an add function of type int * int -> int, but I don't know how
> to write it.
>
> I'm wondering what the OCaml community makes of this. I find it awkward.
> Bob Muller
>
>

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Ian Zimmerman]

On 2017-12-11 15:40, Gerd Stolpmann wrote:

> although, with currified functions this is only an illusion

As they say, "this".  The alternative syntax will lead to people never
learning about partial application.

Does your own language curry multiple arguments by default like Ocaml
does?  If yes, then (IMO) your choice is a mistake, in spite of the
(good) arguments you give for it.

I would be more tolerant about such syntax in a SML-like language where
multiple arguments are modelled with tuples in most cases.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [Caml-list] ReasonML concrete syntax

[Viet Le]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

Yawar, crediting the popularity of Rust because of syntax is misleading.
Mozilla has marketing budget and people behind Rust have build very active
community with weekly newsletter and know how to market. OCaml is mostly
used by academia and some industry players, and marketing is not being
emphasized.

ReasonML is not gaining because of syntax, it's because of huge marketing
effort and easy to follow tutorials and examples and catchy websites. OCaml
documentation is as plain as plain can get. Rust has a few catchy websites,
tutorials and free books as well.

Viet.

On 11 December 2017 at 16:10, Ian Zimmerman <itz@very.loosely.org> wrote:

> On 2017-12-11 15:40, Gerd Stolpmann wrote:
>
> > although, with currified functions this is only an illusion
>
> As they say, "this".  The alternative syntax will lead to people never
> learning about partial application.
>
> Does your own language curry multiple arguments by default like Ocaml
> does?  If yes, then (IMO) your choice is a mistake, in spite of the
> (good) arguments you give for it.
>
> I would be more tolerant about such syntax in a SML-like language where
> multiple arguments are modelled with tuples in most cases.
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> To reply privately _only_ on Usenet, fetch the TXT record for the domain.
>
> --
> 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
>



-- 
Kind regards,
Viet

[-- Attachment #2: Type: text/html, Size: 2625 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yotam Barnoy]

Rust ditched its syntax before release in favor of a syntax more
geared towards the kind of programmers they wanted to attract. This
wasn't a bad decision.

Many people on this mailing list seem to be unaware of the fact that
Reason is really catching on. It's simply a human reality that we like
to try things that are close to what we already know. Bringing OCaml's
syntax close to a language like Javascript, which has countless
developers nowadays, means that a much higher percentage of those
people will want to try out OCaml/Reason. And ultimately, a language
is only as good as its ecosystem -- having the best-designed language
in the world is meaningless if only a few people are using it.

I'm not one of those people who enjoys Reason's syntax (aside from the
issues they fixed in OCaml's syntax), but I appreciate what the Reason
people have done, and I expect Reason to soon eclipse OCaml in terms
of number of users. I don't see this as a bad thing -- Reason's
creators seem to really love OCaml and want to contribute back to the
community.

On Mon, Dec 11, 2017 at 11:47 AM, Viet Le <vietlq85@gmail.com> wrote:
> Yawar, crediting the popularity of Rust because of syntax is misleading.
> Mozilla has marketing budget and people behind Rust have build very active
> community with weekly newsletter and know how to market. OCaml is mostly
> used by academia and some industry players, and marketing is not being
> emphasized.
>
> ReasonML is not gaining because of syntax, it's because of huge marketing
> effort and easy to follow tutorials and examples and catchy websites. OCaml
> documentation is as plain as plain can get. Rust has a few catchy websites,
> tutorials and free books as well.
>
> Viet.
>
> On 11 December 2017 at 16:10, Ian Zimmerman <itz@very.loosely.org> wrote:
>>
>> On 2017-12-11 15:40, Gerd Stolpmann wrote:
>>
>> > although, with currified functions this is only an illusion
>>
>> As they say, "this".  The alternative syntax will lead to people never
>> learning about partial application.
>>
>> Does your own language curry multiple arguments by default like Ocaml
>> does?  If yes, then (IMO) your choice is a mistake, in spite of the
>> (good) arguments you give for it.
>>
>> I would be more tolerant about such syntax in a SML-like language where
>> multiple arguments are modelled with tuples in most cases.
>>
>> --
>> Please don't Cc: me privately on mailing lists and Usenet,
>> if you also post the followup to the list or newsgroup.
>> To reply privately _only_ on Usenet, fetch the TXT record for the domain.
>>
>> --
>> 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
>
>
>
>
> --
> Kind regards,
> Viet

Re: [Caml-list] ReasonML concrete syntax

[Robert Muller]

[-- Attachment #1: Type: text/plain, Size: 4210 bytes --]

Apologies for igniting a bit of a syntax flame war; it wasn't my intention.
The Reason project is fantastic and I hope it's successful. I'm concerned
with teaching OCaml (or possibly Reason) not to JS programmers but to
first-year university students and to students being introduced to algebra.
(In the US, that means middle-school and high-school). I hope that to the
greatest extent possible, the use of parentheses in Reason will be
consistent with their most common use in algebra -- for grouping. OCaml
isn't perfect on this score but the n-argument function accepting an
n-tuple seems like the right thing. I'm hoping that I won't have to explain
to students things like

let add(m, n) = m + n
add(5)

or

let add((m, n)) = m + n

I feel that many of the Reason syntax diffs with OCaml are improvements but
this sort of thing is a step backward IMHO that won't be helpful to JS
programmers anyway.
Bob Muller


On Mon, Dec 11, 2017 at 12:10 PM, Yotam Barnoy <yotambarnoy@gmail.com>
wrote:

> Rust ditched its syntax before release in favor of a syntax more
> geared towards the kind of programmers they wanted to attract. This
> wasn't a bad decision.
>
> Many people on this mailing list seem to be unaware of the fact that
> Reason is really catching on. It's simply a human reality that we like
> to try things that are close to what we already know. Bringing OCaml's
> syntax close to a language like Javascript, which has countless
> developers nowadays, means that a much higher percentage of those
> people will want to try out OCaml/Reason. And ultimately, a language
> is only as good as its ecosystem -- having the best-designed language
> in the world is meaningless if only a few people are using it.
>
> I'm not one of those people who enjoys Reason's syntax (aside from the
> issues they fixed in OCaml's syntax), but I appreciate what the Reason
> people have done, and I expect Reason to soon eclipse OCaml in terms
> of number of users. I don't see this as a bad thing -- Reason's
> creators seem to really love OCaml and want to contribute back to the
> community.
>
> On Mon, Dec 11, 2017 at 11:47 AM, Viet Le <vietlq85@gmail.com> wrote:
> > Yawar, crediting the popularity of Rust because of syntax is misleading.
> > Mozilla has marketing budget and people behind Rust have build very
> active
> > community with weekly newsletter and know how to market. OCaml is mostly
> > used by academia and some industry players, and marketing is not being
> > emphasized.
> >
> > ReasonML is not gaining because of syntax, it's because of huge marketing
> > effort and easy to follow tutorials and examples and catchy websites.
> OCaml
> > documentation is as plain as plain can get. Rust has a few catchy
> websites,
> > tutorials and free books as well.
> >
> > Viet.
> >
> > On 11 December 2017 at 16:10, Ian Zimmerman <itz@very.loosely.org>
> wrote:
> >>
> >> On 2017-12-11 15:40, Gerd Stolpmann wrote:
> >>
> >> > although, with currified functions this is only an illusion
> >>
> >> As they say, "this".  The alternative syntax will lead to people never
> >> learning about partial application.
> >>
> >> Does your own language curry multiple arguments by default like Ocaml
> >> does?  If yes, then (IMO) your choice is a mistake, in spite of the
> >> (good) arguments you give for it.
> >>
> >> I would be more tolerant about such syntax in a SML-like language where
> >> multiple arguments are modelled with tuples in most cases.
> >>
> >> --
> >> Please don't Cc: me privately on mailing lists and Usenet,
> >> if you also post the followup to the list or newsgroup.
> >> To reply privately _only_ on Usenet, fetch the TXT record for the
> domain.
> >>
> >> --
> >> 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
> >
> >
> >
> >
> > --
> > Kind regards,
> > Viet
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 5857 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

Hi Bob,

On Mon, Dec 11, 2017 at 1:56 PM, Robert Muller <robert.muller2@gmail.com>
wrote:

> Apologies for igniting a bit of a syntax flame war; it wasn't my intention.
>

I felt that most people here had a very good discussion. I just didn't like
that a couple of people resorted to name-calling. I get that they don't
like something, there's no need to belittle others who do.


> The Reason project is fantastic and I hope it's successful. I'm concerned
> with teaching OCaml (or possibly Reason) not to JS programmers but to
> first-year university students and to students being introduced to algebra.
>

Very interesting that parenthesis syntax is closer to high-school algebra
function syntax. I really do hope that Reason or something like it becomes
popular as a teaching language. I've heard that some high schools in the
States are teaching C++ to kids as their first language. If we can present
OCaml/Reason as a good alternative, we can save kids from having to learn
C++ :-D

Regards,

Yawar

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Marshall]

> On Dec 11, 2017, at 11:10 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> 
>  It's simply a human reality that we like
> to try things that are close to what we already know. 

Yes, and I would go further.  There are too many tools and languages to explore; any time spent exploring one has an opportunity cost in lost exploration of something else that might be useful or just cool.

Any moderately experienced programmer can learn a lot about a new language that’s not too different just by learning a few core concepts, looking at some code, and trying to write some simple programs.   Past experience plays a big role, though.  If you’d never seen OO programming, reading C++ or Java or OO-style Python or OO-style Javascript requires a bit more learning, but once you know the concepts from one, you can guess a lot about another.  The same point holds for FP.  And it holds for syntax in general.  Everyone knows C/Java/Javascript/a million other languages style syntax.  If you come from that world and try to learn Lisp or Haskell or an ML-family language, you have to do a bit of study before you can even start experimenting seriously.  Then you might ask:  “Is it worth it right now?  There all of these other tools or languages I want to learn.  This new language with the weird syntax sounds cool, and I know I’m smart enough to learn it, but I’m busy.   I have other priorities at the moment.  Maybe I’ll learn it another time.”  And then you never get back to it, because there are always too many things to learn, and you know, you have to have a life, too.  And maybe if the syntax had seemed more intuitive, by the time you put the new language with the weird syntax aside for the time being, you would have already written your first little program in it, because you could guess how to write it just from looking at a little bit of sample code and reading a screenfull of background info.  And by now you would have taken the first step understanding the new language, and might be starting to wonder whether this could be a very useful tool to learn more thoroughly.

I like ML-style syntax, but I know that that makes me weird among programmers. :-)

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

Hi Viet,

> On Dec 11, 2017, at 11:47, Viet Le <vietlq85@gmail.com> wrote:

> Mozilla has marketing budget and people behind Rust have build very active community with weekly newsletter and know how to market. OCaml is mostly used by academia and some industry players, and marketing is not being emphasized.

You need to have something to market. One of the things the Rust community markets is their familiar C-like syntax. Also, I think it’s a stretch to say that Mozilla has a Rust-dedicated marketing budget. Their Rust budget is most likely taken up by infrastructure and devops.

> ReasonML is not gaining because of syntax, it's because of huge marketing effort and easy to follow tutorials and examples and catchy websites.

Like I said, syntax is one of the things the Reason team is marketing heavily and it’s a big selling point. They’re not magically generating buzz just because they’re throwing a lot of blog posts out there and seeing what sticks.

I agree with you that syntax is not the only factor in a language’s popularity. But it is a significant factor. The fact that people here are discussing syntax proves that.

Regards,

Yawar

Re: [Caml-list] ReasonML concrete syntax

[Ian Zimmerman]

On 2017-12-11 16:47, Viet Le wrote:

> Yawar, crediting the popularity of Rust because of syntax is
> misleading.

Clearly this wasn't meant as a reply to my post.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [Caml-list] ReasonML concrete syntax

[Gerd Stolpmann]

[-- Attachment #1.1: Type: text/plain, Size: 1565 bytes --]

On 11.12.17 17:10, Ian Zimmerman wrote:
> On 2017-12-11 15:40, Gerd Stolpmann wrote:
>
>> although, with currified functions this is only an illusion
> As they say, "this".  The alternative syntax will lead to people never
> learning about partial application.
>
> Does your own language curry multiple arguments by default like Ocaml
> does?  If yes, then (IMO) your choice is a mistake, in spite of the
> (good) arguments you give for it.

Yes, it does. I consider it only as a notation, and it's a compromise
because

f x1 x2 x3 <=> ((f x1) x2) x3

doesn't work anymore as an explanation of how multiple args are
(semantically) treated. It would read

f(x1,x2,x3) <=>
  let f1 = f(x1) in
  let f2 = f1(x2) in
  f2(x3)

which works but is ugly and hides more than it explains. On the
implementation side there is no difference.

But I can live with that. This language isn't intended to be used in CS
courses, and the engineers diving deeper into it will still be happy
that partial application works out of the box.

Gerd
>
> I would be more tolerant about such syntax in a SML-like language where
> multiple arguments are modelled with tuples in most cases.
>

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Sebastien Ferre]

The Scala notation is an interesting alternative, IMO.

They have two notations, f(x,y) and f(x)(y), the latter being the
curryfied version allowing partial application.

They also have a notation for partial application
of the non-curryfied form,  f(x,_) and f(_,y), with
the advantage that not only the last argument can missing.

The notation f(x,y) can be used for two different types of f
- (x:Int, y:Int) => Int  (no OCaml equivalent)
- (p:(Int,Int)) => Int   (OCaml: int * int -> int)
   In that case, f(x,y) is an abbreviation for f((x,y))

---
Sébastien

On 12/11/2017 07:30 PM, Gerd Stolpmann wrote:
> On 11.12.17 17:10, Ian Zimmerman wrote:
>> On 2017-12-11 15:40, Gerd Stolpmann wrote:
>>
>>> although, with currified functions this is only an illusion
>> As they say, "this".  The alternative syntax will lead to people never
>> learning about partial application.
>>
>> Does your own language curry multiple arguments by default like Ocaml
>> does?  If yes, then (IMO) your choice is a mistake, in spite of the
>> (good) arguments you give for it.
> 
> Yes, it does. I consider it only as a notation, and it's a compromise
> because
> 
> f x1 x2 x3 <=> ((f x1) x2) x3
> 
> doesn't work anymore as an explanation of how multiple args are
> (semantically) treated. It would read
> 
> f(x1,x2,x3) <=>
>    let f1 = f(x1) in
>    let f2 = f1(x2) in
>    f2(x3)
> 
> which works but is ugly and hides more than it explains. On the
> implementation side there is no difference.
> 
> But I can live with that. This language isn't intended to be used in CS
> courses, and the engineers diving deeper into it will still be happy
> that partial application works out of the box.
> 
> Gerd
>>
>> I would be more tolerant about such syntax in a SML-like language where
>> multiple arguments are modelled with tuples in most cases.
>>
> 

Re: [Caml-list] ReasonML concrete syntax

[Evgeny Khramtsov]

Wed, 13 Dec 2017 09:22:05 +0100
Sebastien Ferre <Sebastien.Ferre@irisa.fr> wrote:

> They have two notations, f(x,y) and f(x)(y), the latter being the
> curryfied version allowing partial application.

This is too complex for JavaScript developers.

RE: [Caml-list] ReasonML concrete syntax

[David Allsopp]

Evgeny Khramtsov wrote:
> Wed, 13 Dec 2017 09:22:05 +0100
> Sebastien Ferre <Sebastien.Ferre@irisa.fr> wrote:
> 
> > They have two notations, f(x,y) and f(x)(y), the latter being the
> > curryfied version allowing partial application.
> 
> This is too complex for JavaScript developers.

Speaking as (I think) OCaml's only Windows-by-preference core developer, a sometime viola player[1], a countertenor[2], a sometime "expert" Visual Basic developer, one who has written quite a lot of ML and quite a lot of non-trivial JavaScript, and probably holder of many other oft-insulted categories, may I observe that in the archives of these threads, it's rare that the ones hurling the insults paint the greatest pictures of either their arguments or themselves...

One of the many differences between the Standard ML basis library and OCaml's stdlib which I find interesting is that SML typically eschews currying unless it's clearly beneficial, preferring signatures like 'a * 'b -> 'c unless 'a -> 'b -> 'c is clearly useful. Standard ML also has stricter rules on the parentheses for tuples, of course.

In terms of why you might want to be "hiding" currying, or at least making it need less immediate explanation when learning the language, consider, for example, explaining the difference between:

let f x y = print_int x; print_int y in
f 42

and

let f x = print_int x; print_int in
f 42

(I'm guessing with its web-based heritage that Reason programming involves a few side-effects)

From my limited experience of teaching beginners to ML - both those who have programmed and those who haven't - I'd say that currying is probably one of the concepts requiring the most explanation; certainly much more than call-by-value vs lazy, or even immutable values. I can certainly see why the Reason team are doing so much to try to make it seem more familiar.


David


[1] https://en.wikipedia.org/wiki/Viola_jokes
[2] http://myweb.tiscali.co.uk/stnicolaschurch/mus-altos.html

Re: [Caml-list] ReasonML concrete syntax

[Marshall]

> On Dec 13, 2017, at 4:37 AM, David Allsopp <dra-news@metastack.com> wrote:
> 
> In terms of why you might want to be "hiding" currying, or at least making it need less immediate explanation when learning the language, consider, for example, explaining the difference between:
> 
> let f x y = print_int x; print_int y in
> f 42
> 
> and
> 
> let f x = print_int x; print_int in
> f 42

Apart from ReasonML, this is interesting.  Why do these behave differently?  I don’t understand yet.

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

In the second example, the second `print_int` never gets called.

On Wed, Dec 13, 2017 at 11:38 AM, Marshall <marshall@logical.net> wrote:

>
> > On Dec 13, 2017, at 4:37 AM, David Allsopp <dra-news@metastack.com>
> wrote:
> >
> > In terms of why you might want to be "hiding" currying, or at least
> making it need less immediate explanation when learning the language,
> consider, for example, explaining the difference between:
> >
> > let f x y = print_int x; print_int y in
> > f 42
> >
> > and
> >
> > let f x = print_int x; print_int in
> > f 42
>
> Apart from ReasonML, this is interesting.  Why do these behave
> differently?  I don’t understand yet.
>
>
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 1700 bytes --]

RE: [Caml-list] ReasonML concrete syntax

[David Allsopp]

Yawar Amin wrote:
> On Wed, Dec 13, 2017 at 11:38 AM, Marshall <mailto:marshall@logical.net> wrote:
> > On Dec 13, 2017, at 4:37 AM, David Allsopp <mailto:dra-news@metastack.com> wrote:
> >
> > > In terms of why you might want to be "hiding" currying, or at least making it need
> > > less immediate explanation when learning the language, consider, for example,
> > > explaining the difference between:
> > >
> > > let f x y = print_int x; print_int y in
> > > f 42
> > >
> > > and
> > >
> > > let g x = print_int x; print_int in
> > > g 42

(code amended to give the functions different names)

> > Apart from ReasonML, this is interesting.  Why do these behave differently?
> > I don’t understand yet.
>
> In the second example, the second `print_int` never gets called.

No, both functions have the same type (int -> int -> unit) and if they're applied to two integers then each will print both of them to stdout. The difference is when they're partially applied - [f] prints nothing; [g] prints 42. It's slightly less unclear in lambda form:

let f =
  fun x ->
    fun y ->
      print_int x;
      print_int y

let g =
  fun x ->
    print_int x;
    fun y ->
      print_int y


David
 

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

Hi David, ah yes, you're right of course. Interestingly, the Reason
formatting tool reformats both of these into:

let g1 = (x) => {
  print_int(x);
  print_int
};

let g2 = (x) => {
  print_int(x);
  (y) => print_int(y)
};

I think it makes it very easy to tell that the latter just includes a
redundant eta abstraction and can be simplified to the former.

Regards,

Yawar


On Wed, Dec 13, 2017 at 12:20 PM, David Allsopp <dra-news@metastack.com>
wrote:

> Yawar Amin wrote:
> > On Wed, Dec 13, 2017 at 11:38 AM, Marshall <mailto:marshall@logical.net>
> wrote:
> > > On Dec 13, 2017, at 4:37 AM, David Allsopp <mailto:
> dra-news@metastack.com> wrote:
> > >
> > > > In terms of why you might want to be "hiding" currying, or at least
> making it need
> > > > less immediate explanation when learning the language, consider, for
> example,
> > > > explaining the difference between:
> > > >
> > > > let f x y = print_int x; print_int y in
> > > > f 42
> > > >
> > > > and
> > > >
> > > > let g x = print_int x; print_int in
> > > > g 42
>
> (code amended to give the functions different names)
>
> > > Apart from ReasonML, this is interesting.  Why do these behave
> differently?
> > > I don’t understand yet.
> >
> > In the second example, the second `print_int` never gets called.
>
> No, both functions have the same type (int -> int -> unit) and if they're
> applied to two integers then each will print both of them to stdout. The
> difference is when they're partially applied - [f] prints nothing; [g]
> prints 42. It's slightly less unclear in lambda form:
>
> let f =
>   fun x ->
>     fun y ->
>       print_int x;
>       print_int y
>
> let g =
>   fun x ->
>     print_int x;
>     fun y ->
>       print_int y
>
>
> David
>
>

[-- Attachment #2: Type: text/html, Size: 2791 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Hendrik Boom]

On Wed, Dec 13, 2017 at 09:22:05AM +0100, Sebastien Ferre wrote:
> 
> The Scala notation is an interesting alternative, IMO.
> 
> They have two notations, f(x,y) and f(x)(y), the latter being the
> curryfied version allowing partial application.
> 
> They also have a notation for partial application
> of the non-curryfied form,  f(x,_) and f(_,y), with
> the advantage that not only the last argument can missing.

I understand currying; I first encountered it in the 60's when 
studying combinatory logic. 

But I find it a nuisance in progrmming in OCaml, becuse it oftern 
happens by accident, and results in mysterious type errors, or none at 
all.

That's why I'd like to see currying only happen explicitly; most of 
the time Ocaml figures I'm currying it's a mistake.

-- hendrik

Re: [Caml-list] ReasonML concrete syntax

[Robert Muller]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

The case that I was trying to make to the ReasonML designers ---
unsuccessfully I guess --- is that the best way to lower the
barrier-to-entry for JS coders to ReasonML is to stick with the ML
tradition of writing k-ary functions with k-tuples and *simply not tell
them about currying at all* until they're up and running. As I understand
it, their parser unrolls the tuples

let f = (x, y, z) => ... become let f = x => y => z => ...

Then whenever an unsuspecting JS coder accidentally calls f with too few
arguments, f(a, b), they don't get an understandable type error because
f(a, b) is of function type and they get some weird error with arrows in it.
I hope they'll revisit this issue but it sounds like a done deal.
Bob


On Wed, Dec 13, 2017 at 12:39 PM, Hendrik Boom <hendrik@topoi.pooq.com>
wrote:

> On Wed, Dec 13, 2017 at 09:22:05AM +0100, Sebastien Ferre wrote:
> >
> > The Scala notation is an interesting alternative, IMO.
> >
> > They have two notations, f(x,y) and f(x)(y), the latter being the
> > curryfied version allowing partial application.
> >
> > They also have a notation for partial application
> > of the non-curryfied form,  f(x,_) and f(_,y), with
> > the advantage that not only the last argument can missing.
>
> I understand currying; I first encountered it in the 60's when
> studying combinatory logic.
>
> But I find it a nuisance in progrmming in OCaml, becuse it oftern
> happens by accident, and results in mysterious type errors, or none at
> all.
>
> That's why I'd like to see currying only happen explicitly; most of
> the time Ocaml figures I'm currying it's a mistake.
>
> -- hendrik
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 2815 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Viet Le]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

Great point, Robert. Sounds like wasted effort for me. Maybe they should
undo this one. Other deviations were fine though.

Viet.


On Wed, 13 Dec 2017 at 17:56, Robert Muller <robert.muller2@gmail.com>
wrote:

> The case that I was trying to make to the ReasonML designers ---
> unsuccessfully I guess --- is that the best way to lower the
> barrier-to-entry for JS coders to ReasonML is to stick with the ML
> tradition of writing k-ary functions with k-tuples and *simply not tell
> them about currying at all* until they're up and running. As I understand
> it, their parser unrolls the tuples
>
> let f = (x, y, z) => ... become let f = x => y => z => ...
>
> Then whenever an unsuspecting JS coder accidentally calls f with too few
> arguments, f(a, b), they don't get an understandable type error because
> f(a, b) is of function type and they get some weird error with arrows in it.
> I hope they'll revisit this issue but it sounds like a done deal.
> Bob
>
>
> On Wed, Dec 13, 2017 at 12:39 PM, Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
>
>> On Wed, Dec 13, 2017 at 09:22:05AM +0100, Sebastien Ferre wrote:
>> >
>> > The Scala notation is an interesting alternative, IMO.
>> >
>> > They have two notations, f(x,y) and f(x)(y), the latter being the
>> > curryfied version allowing partial application.
>> >
>> > They also have a notation for partial application
>> > of the non-curryfied form,  f(x,_) and f(_,y), with
>> > the advantage that not only the last argument can missing.
>>
>> I understand currying; I first encountered it in the 60's when
>> studying combinatory logic.
>>
>> But I find it a nuisance in progrmming in OCaml, becuse it oftern
>> happens by accident, and results in mysterious type errors, or none at
>> all.
>>
>> That's why I'd like to see currying only happen explicitly; most of
>> the time Ocaml figures I'm currying it's a mistake.
>>
>> -- hendrik
>>
>> --
>> 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
>>
>
> --
Kind regards,
Viet

[-- Attachment #2: Type: text/html, Size: 3527 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Yawar Amin]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]

Hi Bob, come hang out at the ReasonML Discord, you'll find that there's a
lot of work ongoing to give the user better error messages as well as keep
the benefits of auto-currying. I'm fairly sure they're thinking about ways
to mitigate the problem of applying too few arguments (which I think
affects OCaml too).

On Wed, Dec 13, 2017 at 12:55 PM, Robert Muller <robert.muller2@gmail.com>
wrote:

> The case that I was trying to make to the ReasonML designers ---
> unsuccessfully I guess --- is that the best way to lower the
> barrier-to-entry for JS coders to ReasonML is to stick with the ML
> tradition of writing k-ary functions with k-tuples and *simply not tell
> them about currying at all* until they're up and running. As I understand
> it, their parser unrolls the tuples
>
> let f = (x, y, z) => ... become let f = x => y => z => ...
>
> Then whenever an unsuspecting JS coder accidentally calls f with too few
> arguments, f(a, b), they don't get an understandable type error because
> f(a, b) is of function type and they get some weird error with arrows in it.
> I hope they'll revisit this issue but it sounds like a done deal.
> Bob
>
>
> On Wed, Dec 13, 2017 at 12:39 PM, Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
>
>> On Wed, Dec 13, 2017 at 09:22:05AM +0100, Sebastien Ferre wrote:
>> >
>> > The Scala notation is an interesting alternative, IMO.
>> >
>> > They have two notations, f(x,y) and f(x)(y), the latter being the
>> > curryfied version allowing partial application.
>> >
>> > They also have a notation for partial application
>> > of the non-curryfied form,  f(x,_) and f(_,y), with
>> > the advantage that not only the last argument can missing.
>>
>> I understand currying; I first encountered it in the 60's when
>> studying combinatory logic.
>>
>> But I find it a nuisance in progrmming in OCaml, becuse it oftern
>> happens by accident, and results in mysterious type errors, or none at
>> all.
>>
>> That's why I'd like to see currying only happen explicitly; most of
>> the time Ocaml figures I'm currying it's a mistake.
>>
>> -- hendrik
>>
>> --
>> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3630 bytes --]

Re: [Caml-list] ReasonML concrete syntax

[Nicolas Boulay]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Have you look at ELM ? That's a functional language for the web that
enforce the last best practice of JavaScript web development. For me, it
miss only a true module system.

http://elm-lang.org/

2017-12-10 19:12 GMT+01:00 Robert Muller <robert.muller2@gmail.com>:

> The team developing ReasonML seems to be experimenting with concrete
> syntax in an effort to make it feel as familiar and natural as possible to
> JavaScript programmers. Seems like a good idea. But the present version
> seems to hardwire parentheses awkwardly for function definitions and calls.
> Parentheses are required for both function definitions and calls. So one
> writes
>
> let incr(n) = n + 1       and   incr(5)
>
> but not
>
> let incr n = n + 1        or    incr 5
>
> Fair enough, but for multi-argument functions the parser seems to unroll
> the parenthesized items (both parameters & arguments) to leave curried
> functions. E.g.,
>
> let add(m, n) = m + n  or equivalently let add = (m, n) => m + n
>
> then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, n) =
> ... isn't a pattern matching a pair, it's the JS-style sequence of input
> parameters and the definition unrolls to let add = (m) => (n) => ... . So
> add(5) : int -> int and all three of add(5, 3), add(5)(3) and { let add5 =
> add(5);  add5(3) } are 8. There's probably a way to write an add function
> of type int * int -> int, but I don't know how to write it.
>
> I'm wondering what the OCaml community makes of this. I find it awkward.
> Bob Muller
>
>
>

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]