[Caml-list] Newbie comment on constructor syntax

[Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Ocaml users,

I just started to develop in OCaml, and must say it is smoother than expected. Although I did C/C++ for decades, I do less errors in Ocaml, both syntactically and in terms of if programs behave as expected. It appears to be much closer to human thinking than C/C++ and I already wonder how I could live without currying and type inference before.

The one thing I find rather non intuitive is that variant constructors can take only one argument - or a tuple. Although I know it is wrong, I always write "Constr a b" instead of "Constr (a, b)". I know syntax is only a minor thing and mostly a matter of taste, but a large fraction of my syntax errors in new code are of this kind (when modifying code it is a bit different). Somehow I think this doesn't go together well with the function call syntax of OCaml. I guess deep in my brain a constructor is a function which takes arguments and returns an element of the type it constructs, so I guess I want to use the usual function call syntax.

My question: Is there some syntax to give a constructor more than one argument which escaped me? Something like if I leave away the * in the definition I can use usual function call syntax in constructions and expressions? I would find this easier to read and to write, especially in matches or nested constructs. Does everybody use camlp4/p5/ppx to customize the syntax to his liking (as chapter 5 of the camlp4 manual suggests)? Or are there some long term advantages of this syntax I don't see as yet?

Best regards,

Michael

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Nicolas Ojeda Bar]

Dear Michael,

No, there is no such syntax.  See

http://caml.inria.fr/pub/ml-archives/caml-list/2001/08/47db53a4b42529708647c9e81183598b.en.html

for more information.

Kind regards,
Nicolas

On 11/6/2015 10:33 AM, Soegtrop, Michael wrote:
> Dear Ocaml users,
>
> I just started to develop in OCaml, and must say it is smoother than expected. Although I did C/C++ for decades, I do less errors in Ocaml, both syntactically and in terms of if programs behave as expected. It appears to be much closer to human thinking than C/C++ and I already wonder how I could live without currying and type inference before.
>
> The one thing I find rather non intuitive is that variant constructors can take only one argument - or a tuple. Although I know it is wrong, I always write "Constr a b" instead of "Constr (a, b)". I know syntax is only a minor thing and mostly a matter of taste, but a large fraction of my syntax errors in new code are of this kind (when modifying code it is a bit different). Somehow I think this doesn't go together well with the function call syntax of OCaml. I guess deep in my brain a constructor is a function which takes arguments and returns an element of the type it constructs, so I guess I want to use the usual function call syntax.
>
> My question: Is there some syntax to give a constructor more than one argument which escaped me? Something like if I leave away the * in the definition I can use usual function call syntax in constructions and expressions? I would find this easier to read and to write, especially in matches or nested constructs. Does everybody use camlp4/p5/ppx to customize the syntax to his liking (as chapter 5 of the camlp4 manual suggests)? Or are there some long term advantages of this syntax I don't see as yet?
>
> Best regards,
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>

Re: [Caml-list] Newbie comment on constructor syntax

[Francois Berenger]

On 11/06/2015 10:33 AM, Soegtrop, Michael wrote:
> Dear Ocaml users,
>
> I just started to develop in OCaml, and must say it is smoother than expected. Although I did C/C++ for decades, I do less errors in Ocaml, both syntactically and in terms of if programs behave as expected. It appears to be much closer to human thinking than C/C++ and I already wonder how I could live without currying and type inference before.
>
> The one thing I find rather non intuitive is that variant constructors can take only one argument - or a tuple. Although I know it is wrong, I always write "Constr a b" instead of "Constr (a, b)". I know syntax is only a minor thing and mostly a matter of taste, but a large fraction of my syntax errors in new code are of this kind (when modifying code it is a bit different). Somehow I think this doesn't go together well with the function call syntax of OCaml. I guess deep in my brain a constructor is a function which takes arguments and returns an element of the type it constructs, so I guess I want to use the usual function call syntax.
>
> My question: Is there some syntax to give a constructor more than one argument which escaped me? Something like if I leave away the * in the definition I can use usual function call syntax in constructions and expressions? I would find this easier to read and to write, especially in matches or nested constructs. Does everybody use camlp4/p5/ppx to customize the syntax to his liking (as chapter 5 of the camlp4 manual suggests)? Or are there some long term advantages of this syntax I don't see as yet?

A dummy suggestion, but maybe you will like it:

let constr a b = Constr (a, b)

> Best regards,
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>

-- 
Regards,
Francois.
"When in doubt, use more types"

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Francois,

> let constr a b = Constr (a, b)

unfortunately this won't work for matches. I will see if I get used to this. If not I will take this as a reason to learn p5 and/or ppx :-)

Best regards,

Michael 
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Gabriel Scherer]

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

The use of camlp{4,5} to change OCaml syntax has always had extremely low
adoption, with some very specific exceptions (notably the lwt-support
syntax of the Ocsigen project). I suspect that this is due to the fact that
integrating a new syntax extension to your project has historically caused
more build-system and deployment trouble than people were willing to
tolerate.

ppx extensions are not designed to allow extending the OCaml syntax, and in
particular I think they are not a good fit for what you are looking for. It
is a large part of their appeal: by being less flexible, they are simpler
and more robust.

I personally believe that currified constructor syntax would be a better
choice, and that using non-currified constructors is a historical mistake
of SML/Caml. But I am also not convinced that efforts to change it today
are worth the trouble, and prefer to concentrate on improving other parts
of the OCaml ecosystem.

Another thing that was touched by your comments is the usefulness of
user-defined patterns (pattern synonyms). I have conflicted opinions on the
question of whether adding pattern synonyms would be a good thing, but
described one aspect of a proposal that I like (but also highlights that
the feature can be a source of implementation complexity) in
  http://gallium.inria.fr/blog/pattern-synonyms-as-expressions/

On Fri, Nov 6, 2015 at 1:20 PM, Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:

> Dear Francois,
>
> > let constr a b = Constr (a, b)
>
> unfortunately this won't work for matches. I will see if I get used to
> this. If not I will take this as a reason to learn p5 and/or ppx :-)
>
> Best regards,
>
> Michael
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>
> --
> 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: 3244 bytes --]

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

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

Dear Gabriel,

thanks for the link, an interesting idea and discussion! And I see that maybe I should come over to Paris to participate ;-) I would agree with Alain Frisch’s final comment that whenever a pattern synonym is used in the RHS, there should be an explicit binder. This would either solve the “trouble” case or make the similarity to (x, x) obvious.

Best regards,

Michael

From: caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] On Behalf Of Gabriel Scherer
Sent: Friday, November 06, 2015 1:34 PM
To: Soegtrop, Michael
Cc: Francois Berenger; caml-list@inria.fr
Subject: Re: [Caml-list] Newbie comment on constructor syntax

The use of camlp{4,5} to change OCaml syntax has always had extremely low adoption, with some very specific exceptions (notably the lwt-support syntax of the Ocsigen project). I suspect that this is due to the fact that integrating a new syntax extension to your project has historically caused more build-system and deployment trouble than people were willing to tolerate.
ppx extensions are not designed to allow extending the OCaml syntax, and in particular I think they are not a good fit for what you are looking for. It is a large part of their appeal: by being less flexible, they are simpler and more robust.
I personally believe that currified constructor syntax would be a better choice, and that using non-currified constructors is a historical mistake of SML/Caml. But I am also not convinced that efforts to change it today are worth the trouble, and prefer to concentrate on improving other parts of the OCaml ecosystem.
Another thing that was touched by your comments is the usefulness of user-defined patterns (pattern synonyms). I have conflicted opinions on the question of whether adding pattern synonyms would be a good thing, but described one aspect of a proposal that I like (but also highlights that the feature can be a source of implementation complexity) in
  http://gallium.inria.fr/blog/pattern-synonyms-as-expressions/
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

Re: [Caml-list] Newbie comment on constructor syntax

[Ashish Agarwal]

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

You might be interested in:
https://github.com/janestreet/ppx_variants_conv

Example:

$ utop
utop # #require "ppx_deriving";;
utop # #require "ppx_variants_conv";;
utop # #require "variantslib";;

type t = A of int | C of int * int [@@deriving variants];;
type t = A of int | C of int * int
val c : int -> int -> t = <fun>
val a : int -> t = <fun>

module Variants :
  sig
    val c : (int -> int -> t) Variantslib.Variant.t
    val a : (int -> t) Variantslib.Variant.t
    val fold :
      init:'a ->
      a:('a -> (int -> t) Variantslib.Variant.t -> 'b) ->
      c:('b -> (int -> int -> t) Variantslib.Variant.t -> 'c) -> 'c
    val iter :
      a:((int -> t) Variantslib.Variant.t -> 'a) ->
      c:((int -> int -> t) Variantslib.Variant.t -> 'b) -> 'b
    val map :
      t ->
      a:((int -> t) Variantslib.Variant.t -> int -> 'a) ->
      c:((int -> int -> t) Variantslib.Variant.t -> int -> int -> 'a) -> 'a
    val descriptions : (string * int) list
  end

(I'm not quite sure why you have to do three #require statements manually.
Related to this <https://github.com/janestreet/ppx_sexp_conv/issues/1>.)


> Does everybody use camlp4/p5/ppx to customize the syntax to his liking

Note that the community is moving to ppx based syntax extensions, and away
from camlp4/5.

> 200k of code

Where do you see that much code? I only see 6000 lines of code.



On Fri, Nov 6, 2015 at 8:09 AM, Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:

> Dear Gabriel,
>
>
>
> thanks for the link, an interesting idea and discussion! And I see that
> maybe I should come over to Paris to participate ;-) I would agree with
> Alain Frisch’s final comment that whenever a pattern synonym is used in the
> RHS, there should be an explicit binder. This would either solve the
> “trouble” case or make the similarity to (x, x) obvious.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
> *From:* caml-list-request@inria.fr [mailto:caml-list-request@inria.fr] *On
> Behalf Of *Gabriel Scherer
> *Sent:* Friday, November 06, 2015 1:34 PM
> *To:* Soegtrop, Michael
> *Cc:* Francois Berenger; caml-list@inria.fr
> *Subject:* Re: [Caml-list] Newbie comment on constructor syntax
>
>
>
> The use of camlp{4,5} to change OCaml syntax has always had extremely low
> adoption, with some very specific exceptions (notably the lwt-support
> syntax of the Ocsigen project). I suspect that this is due to the fact that
> integrating a new syntax extension to your project has historically caused
> more build-system and deployment trouble than people were willing to
> tolerate.
>
> ppx extensions are not designed to allow extending the OCaml syntax, and
> in particular I think they are not a good fit for what you are looking for.
> It is a large part of their appeal: by being less flexible, they are
> simpler and more robust.
>
> I personally believe that currified constructor syntax would be a better
> choice, and that using non-currified constructors is a historical mistake
> of SML/Caml. But I am also not convinced that efforts to change it today
> are worth the trouble, and prefer to concentrate on improving other parts
> of the OCaml ecosystem.
>
> Another thing that was touched by your comments is the usefulness of
> user-defined patterns (pattern synonyms). I have conflicted opinions on the
> question of whether adding pattern synonyms would be a good thing, but
> described one aspect of a proposal that I like (but also highlights that
> the feature can be a source of implementation complexity) in
>   http://gallium.inria.fr/blog/pattern-synonyms-as-expressions/
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>

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

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

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

Dear Ashish,

thanks, the features of this extension like mapping and iteration are very interesting!

> 200k of code

Where do you see that much code? I only see 6000 lines of code.

I was referring to the size in bytes, which appears to be a bit more than 200k.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

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

Re: [Caml-list] Newbie comment on constructor syntax

[Ashish Agarwal]

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

On Fri, Nov 6, 2015 at 10:19 AM, Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:


> I was referring to the size in bytes, which appears to be a bit more than
> 200k.
>

Oh right.

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

[Caml-list] Notation for currying

[Hendrik Boom]

On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote:
> 
> I personally believe that currified constructor syntax would be a better
> choice, and that using non-currified constructors is a historical mistake
> of SML/Caml. But I am also not convinced that efforts to change it today
> are worth the trouble, and prefer to concentrate on improving other parts
> of the OCaml ecosystem.

Perhaps there should be explicit syntax for currying, such as
   f a b _
instead of 
   f a b
That would permit currying in other argument positions:
   f a _ c
though I suspect _ may be the wrong symbol for the current language, and 
I also suspect it's far too late tointroduce it in the current language.

I have noticed that almost a the situations where the compiler thinks I 
mean to curry I actually just left out a parameter by mistake.  The type 
inferences it makes based on these errors usually occur elsewhere and 
are truly mystifying.

-- hendrik

Re: [Caml-list] Notation for currying

[Gabriel Scherer]

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

In a previous life I would write Camlp4 extension for fun, and I used the
syntax
  \( ... _ ...)
to abstract over an anonymous variables (you could also use \1 \2 \3 etc,
and the n-th occurence of _ from left to right was turned into \n, but
mixing numbers and _ was disallowed). It solves Scala's problem that, the
scope of _ being delimited by the closest parentheses, the notation was not
composable -- but arguably enforcing a small scope is a good thing.

This is the kind of features that nobody will ever agree on, so it's too
hard to get them in a language. Nowadays I write "(fun x ->" instead of
"\(", and "x" instead of "_", and it is not that bad.

Arthur Charguéraud has been working on an "easy-type-errors" mode with
better typing error messages for OCaml. You may be interested in his article
  http://www.chargueraud.org/research/2015/ocaml_errors/ocaml_errors.pdf
although I think this specific case of under-application is not discussed
(using too many argument is discussed).

I also find the work on SHErrLoc, by Danfeng Zhang, Andrew C. Myers and
their collaborators, to be very impressive:
  http://www.cs.cornell.edu/Projects/SHErrLoc/

On Sat, Nov 21, 2015 at 6:24 PM, Hendrik Boom <hendrik@topoi.pooq.com>
wrote:

> On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote:
> >
> > I personally believe that currified constructor syntax would be a better
> > choice, and that using non-currified constructors is a historical mistake
> > of SML/Caml. But I am also not convinced that efforts to change it today
> > are worth the trouble, and prefer to concentrate on improving other parts
> > of the OCaml ecosystem.
>
> Perhaps there should be explicit syntax for currying, such as
>    f a b _
> instead of
>    f a b
> That would permit currying in other argument positions:
>    f a _ c
> though I suspect _ may be the wrong symbol for the current language, and
> I also suspect it's far too late tointroduce it in the current language.
>
> I have noticed that almost a the situations where the compiler thinks I
> mean to curry I actually just left out a parameter by mistake.  The type
> inferences it makes based on these errors usually occur elsewhere and
> are truly mystifying.
>
> -- 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: 3512 bytes --]

Re: [Caml-list] Notation for currying

[David Rajchenbach-Teller]

As a side question, is currying really an important language feature? In
my experience, it hinders readability and makes it harder to reason
about types ("wait, is it weakly or strongly polymorphic? exactly which
type variables were generalized?")

After coding a number of years in languages without currying, I haven't
found myself lacking this feature a single time.

Cheers,
 David

On 21/11/15 18:24, Hendrik Boom wrote:
> On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote:
>>
>> I personally believe that currified constructor syntax would be a better
>> choice, and that using non-currified constructors is a historical mistake
>> of SML/Caml. But I am also not convinced that efforts to change it today
>> are worth the trouble, and prefer to concentrate on improving other parts
>> of the OCaml ecosystem.
> 
> Perhaps there should be explicit syntax for currying, such as
>    f a b _
> instead of 
>    f a b
> That would permit currying in other argument positions:
>    f a _ c
> though I suspect _ may be the wrong symbol for the current language, and 
> I also suspect it's far too late tointroduce it in the current language.
> 
> I have noticed that almost a the situations where the compiler thinks I 
> mean to curry I actually just left out a parameter by mistake.  The type 
> inferences it makes based on these errors usually occur elsewhere and 
> are truly mystifying.
> 
> -- hendrik
> 

Re: [Caml-list] Notation for currying

[Gabriel Scherer]

The initial discussion was more about the difference in readability
between two syntaxes for fully-applied functions or constructors,
  f(x, y, z), C(x, y, z)
or
  f x y z, C x y z
I find the latter more readable in many settings, in particular where
functions or constructors are nested. One typical example would be the
"balance" functions for Okasaki-inspired red-black trees, for example
https://www.lri.fr/~filliatr/ftp/ocaml/ds/rbset.ml.html

Compare
    | Red (Red (a,x,b), y, c), z, d ->
        Red (Black (a,x,b), y, Black (c,z,d))
with
    | (Red (Red a x b) y c), z, d
        Red (Black a x b) y (Black c z d)

Note that using this syntax does not in itself require supporting
partial application, even though they are naturally linked in the most
common reading of this syntax as nested unary application.

Now, to your question of "do we need to make it easy to partially
abstract over the last parameter of the function", I think I would
agree with you that this is not essential (especially when the syntax
for abstraction is already lightweight). However, having a good syntax
for application is a rather subtle balance to strike that may require
cooperation of several distinct syntactic elements -- in particular
when you also want to support named parameters (or have a lightweight
enough syntax for records or named tuples that looks like named
parameters). I like named parameters as they often improve the
robustness of APIs -- lightweight records are even better because they
can be both passed and returned.

Finally, in Mezzo ( http://protz.github.io/mezzo/ ) there is a cute
trick that I have not seen anywhere else, and I wonder whether it is
an extraordinary (but ancedotal) coincidence or something that should
be reused. The syntax for function parameters in function prototypes
(declarations, signature items)

   val concat: [a] (consumes list a, consumes list a) -> (list a)

and in function definitions

  val concat [a] (consumes xs: list a, consumes ys: list a): list a =
    ...

is exactly the same.

(See http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-types
, http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-definitions
)

This is only possible because the language has just enough dependent
types to make it natural to name all function parameters in their
types, and even do deep pattern-matching on an argument directly from
the type definition. It reminds us of the strange identification
between types and patterns in CDuce ( http://www.cduce.org/ ).

On Sat, Nov 21, 2015 at 7:05 PM, David Rajchenbach-Teller
<David.Teller@ens-lyon.org> wrote:
> As a side question, is currying really an important language feature? In
> my experience, it hinders readability and makes it harder to reason
> about types ("wait, is it weakly or strongly polymorphic? exactly which
> type variables were generalized?")
>
> After coding a number of years in languages without currying, I haven't
> found myself lacking this feature a single time.
>
> Cheers,
>  David
>
> On 21/11/15 18:24, Hendrik Boom wrote:
>> On Fri, Nov 06, 2015 at 01:34:11PM +0100, Gabriel Scherer wrote:
>>>
>>> I personally believe that currified constructor syntax would be a better
>>> choice, and that using non-currified constructors is a historical mistake
>>> of SML/Caml. But I am also not convinced that efforts to change it today
>>> are worth the trouble, and prefer to concentrate on improving other parts
>>> of the OCaml ecosystem.
>>
>> Perhaps there should be explicit syntax for currying, such as
>>    f a b _
>> instead of
>>    f a b
>> That would permit currying in other argument positions:
>>    f a _ c
>> though I suspect _ may be the wrong symbol for the current language, and
>> I also suspect it's far too late tointroduce it in the current language.
>>
>> I have noticed that almost a the situations where the compiler thinks I
>> mean to curry I actually just left out a parameter by mistake.  The type
>> inferences it makes based on these errors usually occur elsewhere and
>> are truly mystifying.
>>
>> -- 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

Re: [Caml-list] Newbie comment on constructor syntax

[Jonas Jensen]

If you're feeling adventurous, you can try Jun Furuse's ppx extension
that enables curried and partially-applied constructors:
https://bitbucket.org/camlspotter/ppx_curried_constr

On 6 November 2015 at 10:33, Soegtrop, Michael
<michael.soegtrop@intel.com> wrote:
>
> Dear Ocaml users,
>
> I just started to develop in OCaml, and must say it is smoother than expected. Although I did C/C++ for decades, I do less errors in Ocaml, both syntactically and in terms of if programs behave as expected. It appears to be much closer to human thinking than C/C++ and I already wonder how I could live without currying and type inference before.
>
> The one thing I find rather non intuitive is that variant constructors can take only one argument - or a tuple. Although I know it is wrong, I always write "Constr a b" instead of "Constr (a, b)". I know syntax is only a minor thing and mostly a matter of taste, but a large fraction of my syntax errors in new code are of this kind (when modifying code it is a bit different). Somehow I think this doesn't go together well with the function call syntax of OCaml. I guess deep in my brain a constructor is a function which takes arguments and returns an element of the type it constructs, so I guess I want to use the usual function call syntax.
>
> My question: Is there some syntax to give a constructor more than one argument which escaped me? Something like if I leave away the * in the definition I can use usual function call syntax in constructions and expressions? I would find this easier to read and to write, especially in matches or nested constructs. Does everybody use camlp4/p5/ppx to customize the syntax to his liking (as chapter 5 of the camlp4 manual suggests)? Or are there some long term advantages of this syntax I don't see as yet?
>
> Best regards,
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>
> --
> 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

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Jonas,

thanks for the link! It is interesting that others feel enough pain to write 200k of code to get a nicer and more flexible constructor syntax. Also interesting that it takes > 200k of code to do this even with ppx. And I am not sure if this would works for matches - at least there are none in the test files. For sure I need to gather a bit more experience before I dig into this.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Gabriel Scherer]

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

The implementation technique used by Jun Furuse is to duplicate the
implementation of the type-checker, and change only the parts that
type-check constructor applications. This is the least-constraining way to
write type-aware transformations as ppx extensions. A more concise way is
to call compiler-libs for type-checking and postprocess the resulting typed
AST, but this is only reasonable if the input source is expected to be
well-typed.

(There are few limit on the kind of transformations you can do if you are,
in fact, willing to fork the compiler codebase if necessary. But, as Jonas
Jensen mentioned, this is "adventurous" indeed.)

On Fri, Nov 6, 2015 at 1:46 PM, Soegtrop, Michael <
michael.soegtrop@intel.com> wrote:

> Dear Jonas,
>
> thanks for the link! It is interesting that others feel enough pain to
> write 200k of code to get a nicer and more flexible constructor syntax.
> Also interesting that it takes > 200k of code to do this even with ppx. And
> I am not sure if this would works for matches - at least there are none in
> the test files. For sure I need to gather a bit more experience before I
> dig into this.
>
> Best regards,
>
> Michael
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
> --
> 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: 2574 bytes --]

Re: [Caml-list] Newbie comment on constructor syntax

[Florian Weimer]

* Michael Soegtrop:

> The one thing I find rather non intuitive is that variant constructors
> can take only one argument - or a tuple.

Curiously, the argument is not really a tuple.  This does not work:

type x = X of int * int
let c = (1, 2) in X c

> Although I know it is wrong, I always write "Constr a b" instead of
> "Constr (a, b)". I know syntax is only a minor thing and mostly a
> matter of taste, but a large fraction of my syntax errors in new
> code are of this kind (when modifying code it is a bit different).

Maybe it is possible to teach your editor some semantic syntax
highlighting, so that it flags this while typing?

Re: [Caml-list] Newbie comment on constructor syntax

[Norman Hardy]

> On 2015 Nov 8, at 13:16 , Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> * Michael Soegtrop:
> 
>> The one thing I find rather non intuitive is that variant constructors
>> can take only one argument - or a tuple.
> 
> Curiously, the argument is not really a tuple.  This does not work:
> 
> type x = X of int * int
> let c = (1, 2) in X c

However the following works:
# type x  = X of (int * int);;
type x = X of (int * int)
# let c = (1, 2) in X c;;
- : x = X (1, 2)

Re: [Caml-list] Newbie comment on constructor syntax

[Florian Weimer]

* Norman Hardy:

>> On 2015 Nov 8, at 13:16 , Florian Weimer <fw@deneb.enyo.de> wrote:
>> 
>> * Michael Soegtrop:
>> 
>>> The one thing I find rather non intuitive is that variant constructors
>>> can take only one argument - or a tuple.
>> 
>> Curiously, the argument is not really a tuple.  This does not work:
>> 
>> type x = X of int * int
>> let c = (1, 2) in X c
>
> However the following works:
> # type x  = X of (int * int);;
> type x = X of (int * int)
> # let c = (1, 2) in X c;;
> - : x = X (1, 2)

With multiple constructors per type at least, this has a different
in-memory representation: two objects (the constructed value and a
tuple which the value references).

Re: [Caml-list] Newbie comment on constructor syntax

[Stefan Monnier]

>> However the following works:
>> # type x  = X of (int * int);;
>> type x = X of (int * int)
>> # let c = (1, 2) in X c;;
>> - : x = X (1, 2)

> With multiple constructors per type at least, this has a different
> in-memory representation: two objects (the constructed value and a
> tuple which the value references).

Of course, SML (being the less pragmatic brother) does not have this
"wart" and treats "X of int * int" the same as "X of (int * int)".

But this indeed comes at the cost of a less efficient representation.
You can try to "optimize" this away, but it becomes tricky when you
start using functors where type "t" is a parameter and you have
a constructor "X of t".

IOW, there were good pragmatic reasons to introduce this "wart".
This said I think Haskell shows that using a curried constructor
nicely circumvents the problem (of course it comes at the cost of not
being able to do the equivalent of "X of t", but that doesn't seem to
be much of a problem in practice, especially for Haskell where there
are no functors anyway).


        Stefan

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Florian, Norman, 

> > Curiously, the argument is not really a tuple.  This does not work:
> >
> > type x = X of int * int
> > let c = (1, 2) in X c
> 
> However the following works:
> # type x  = X of (int * int);;
> type x = X of (int * int)
> # let c = (1, 2) in X c;;
> - : x = X (1, 2)

Exactly this is what is quite confusing (for the beginner): constructors are a rather odd mix of multiple arguments and tuples. The notation looks like tuples, both in definition and use, but it isn't. And it is not a multiple argument function either, since currying doesn't work. That adding parenthesis makes it a real tuple doesn't make it better, since at some other places a*b and (a*b) are the same.

To me this is quite a scar in the beauty of the language - the kind of thing you can't avoid to look at, if you know what I mean. Of cause it is not really an issue. It is just way disappointing for new users to find this kind of imperfection and it gives a little dent in the enthusiasm. But just a little one ;-)

Best regards,

Michael

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Hendrik Boom]

On Mon, Nov 09, 2015 at 08:09:30AM +0000, Soegtrop, Michael wrote:
> Dear Florian, Norman, 
> 
> > > Curiously, the argument is not really a tuple.  This does not work:
> > >
> > > type x = X of int * int
> > > let c = (1, 2) in X c
> > 
> > However the following works:
> > # type x  = X of (int * int);;
> > type x = X of (int * int)
> > # let c = (1, 2) in X c;;
> > - : x = X (1, 2)
> 
> Exactly this is what is quite confusing (for the beginner): constructors are a rather odd mix of multiple arguments and tuples. The notation looks like tuples, both in definition and use, but it isn't. And it is not a multiple argument function either, since currying doesn't work. That adding parenthesis makes it a real tuple doesn't make it better, since at some other places a*b and (a*b) are the same.
> 
> To me this is quite a scar in the beauty of the language - the kind of thing you can't avoid to look at, if you know what I mean. Of cause it is not really an issue. It is just way disappointing for new users to find this kind of imperfection and it gives a little dent in the enthusiasm. But just a little one ;-)

Parentheses should never be used with a meaning other than indicating 
proper grouping, their original function in high school algebra.
OCaml went partway there by abolishing them as syntax for function 
calls.

-- hendrik

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 09/11/2015 09:09, Soegtrop, Michael wrote:
> The notation looks like tuples, both in definition and use, but it isn't.

The should be not big obstacle to allow using real tuples 
(values/patterns) with multi-argument constructors, thus perhaps 
reducing the confusion.  In expression at least, this should be quite 
straightfoward because it can be understood as a local syntactic 
rewriting ("C e" -> "let (x1, ..., xn) = e in C (x1, ..., xn)" when C is 
a constructor with arity > 1 and "e" is not a syntactic tuple).

See:
http://caml.inria.fr/mantis/view.php?id=6455

-- Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Andreas Rossberg]

On 11/09/2015 11:16 AM, Alain Frisch wrote:
> On 09/11/2015 09:09, Soegtrop, Michael wrote:
>> The notation looks like tuples, both in definition and use, but it isn't.
>
> The should be not big obstacle to allow using real tuples
> (values/patterns) with multi-argument constructors, thus perhaps
> reducing the confusion.  In expression at least, this should be quite
> straightfoward because it can be understood as a local syntactic
> rewriting ("C e" -> "let (x1, ..., xn) = e in C (x1, ..., xn)" when C is
> a constructor with arity > 1 and "e" is not a syntactic tuple).
>
> See:
> http://caml.inria.fr/mantis/view.php?id=6455

Yes please, I would appreciate such sugar. Even more I would appreciate 
generalising that to allowing constructors to be used as first-class 
expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)" 
when C is a constructor with arity > 0). I had to write some AST mapping 
code recently that would have vastly benefited from that.

/Andreas

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 09/11/2015 11:35, Andreas Rossberg wrote:
> On 11/09/2015 11:16 AM, Alain Frisch wrote:
>> On 09/11/2015 09:09, Soegtrop, Michael wrote:
>>> The notation looks like tuples, both in definition and use, but it
>>> isn't.
>>
>> The should be not big obstacle to allow using real tuples
>> (values/patterns) with multi-argument constructors, thus perhaps
>> reducing the confusion.  In expression at least, this should be quite
>> straightfoward because it can be understood as a local syntactic
>> rewriting ("C e" -> "let (x1, ..., xn) = e in C (x1, ..., xn)" when C is
>> a constructor with arity > 1 and "e" is not a syntactic tuple).
>>
>> See:
>> http://caml.inria.fr/mantis/view.php?id=6455
>
> Yes please, I would appreciate such sugar.

I've submitted a quick patch that covers expressions only (not patterns) 
on the Mantis ticket.  I'm not very satisfied with the implementation 
technique nor the lack of symmetry with patterns, so I won't propose it 
for inclusion in this form.

-- Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 09/11/2015 11:35, Andreas Rossberg wrote:
> Yes please, I would appreciate such sugar.

I've now submitted a cleaner implementation, working on both expressions 
and patterns:

https://github.com/ocaml/ocaml/pull/284

> Even more I would appreciate
> generalising that to allowing constructors to be used as first-class
> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
> when C is a constructor with arity > 0). I had to write some AST mapping
> code recently that would have vastly benefited from that.

This is not covered (and now, it could simply be "fun x -> C x" :-)).  I 
don't see anything clever to be done on patterns for "unapplied 
constructors", though.


Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Gabriel Scherer]

If we gave a functional semantic to the unapplied constructor, then I
think that good taste would mandate for the application of this
function and the application of the constructor to be equivalent. This
means that by choosing a tuple-taking function, we commit to the
tuple-application syntax (that nobody likes), and that choosing a
currified function creates an unpleasant inconsistency in the
language.

I don't know whether we could ever manage to transition to a currified
syntax for constructors, but right now it is at least conceivable
because the application syntax is just a concrete syntax choice, it
does not affect typing. Turning unapplied constructor into a function
(tuplified or currified) makes it a typing property, observable at
specification boundaries: we cannot change it.

On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch <alain.frisch@lexifi.com> wrote:
> On 09/11/2015 11:35, Andreas Rossberg wrote:
>>
>> Yes please, I would appreciate such sugar.
>
>
> I've now submitted a cleaner implementation, working on both expressions and
> patterns:
>
> https://github.com/ocaml/ocaml/pull/284
>
>> Even more I would appreciate
>> generalising that to allowing constructors to be used as first-class
>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
>> when C is a constructor with arity > 0). I had to write some AST mapping
>> code recently that would have vastly benefited from that.
>
>
> This is not covered (and now, it could simply be "fun x -> C x" :-)).  I
> don't see anything clever to be done on patterns for "unapplied
> constructors", though.
>
>
> Alain
>
>
> --
> 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

Re: [Caml-list] Newbie comment on constructor syntax

[Andreas Rossberg]

On 11/09/2015 07:08 PM, Gabriel Scherer wrote:
> If we gave a functional semantic to the unapplied constructor, then I
> think that good taste would mandate for the application of this
> function and the application of the constructor to be equivalent. This
> means that by choosing a tuple-taking function, we commit to the
> tuple-application syntax (that nobody likes), and that choosing a
> currified function creates an unpleasant inconsistency in the
> language.
>
> I don't know whether we could ever manage to transition to a currified
> syntax for constructors, but right now it is at least conceivable
> because the application syntax is just a concrete syntax choice, it
> does not affect typing. Turning unapplied constructor into a function
> (tuplified or currified) makes it a typing property, observable at
> specification boundaries: we cannot change it.

Hm, I see your point, but don't you already introduce that problem 
(i.e., commit to tuples) by allowing the `C x` sugar for n-ary 
constructors? Because in a world of curried constructors, `x` would not 
be typed as the tuple of arguments, but only as the first argument of 
the constructor.

/Andreas


> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch <alain.frisch@lexifi.com> wrote:
>> On 09/11/2015 11:35, Andreas Rossberg wrote:
>>>
>>> Yes please, I would appreciate such sugar.
>>
>>
>> I've now submitted a cleaner implementation, working on both expressions and
>> patterns:
>>
>> https://github.com/ocaml/ocaml/pull/284
>>
>>> Even more I would appreciate
>>> generalising that to allowing constructors to be used as first-class
>>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
>>> when C is a constructor with arity > 0). I had to write some AST mapping
>>> code recently that would have vastly benefited from that.
>>
>>
>> This is not covered (and now, it could simply be "fun x -> C x" :-)).  I
>> don't see anything clever to be done on patterns for "unapplied
>> constructors", though.
>>
>>
>> Alain
>>
>>
>> --
>> 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

Re: [Caml-list] Newbie comment on constructor syntax

[Gabriel Scherer]

On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
> Hm, I see your point, but don't you already introduce that problem (i.e.,
> commit to tuples) by allowing the `C x` sugar for n-ary constructors?
> Because in a world of curried constructors, `x` would not be typed as the
> tuple of arguments, but only as the first argument of the constructor.

Yes, it is already problematic, and in fact I'm personally not
completely convinced by this feature -- Alain it "reduces bad
surprises for beginners", but I suspect that adding more magic in this
place could not actually help that much -- at least the current
semantic model is simple.

Another problem with (C x) is the non-trivial performance implications of
  | C x -> x
which actually allocates.

The problem would only get worse if we allowed
  type t = { mutable x : int; mutable y : int }
  type u = Packed of { mutable x : int; mutable y : int }
  let pack x = Packed x
with an observable change in mutability semantics from the same code with
  type u = Packed of t
(but Alain has not suggested adding this feature to decrease surprises
(yet?), and luckily our tuples are immutable.)

I like the revised syntax choice of writing
  type t = A of int and int list
instead of
  type t = A of int * int list
which removes the beginner surprise without introducing other
unpalatable design side-effects. (It is still awkward for GADTs, but
such is life.)

Sometime I think it's wise to avoid local improvements that get stuck
in local maxima.

(This is also my argument against Haskell's choice of using the same
syntax for the pairs (x, y) and the types of pairs (t, u). I guess at
the time they thought that, of course, they would never get type-level
pairs.)

On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
> On 11/09/2015 07:08 PM, Gabriel Scherer wrote:
>>
>> If we gave a functional semantic to the unapplied constructor, then I
>> think that good taste would mandate for the application of this
>> function and the application of the constructor to be equivalent. This
>> means that by choosing a tuple-taking function, we commit to the
>> tuple-application syntax (that nobody likes), and that choosing a
>> currified function creates an unpleasant inconsistency in the
>> language.
>>
>> I don't know whether we could ever manage to transition to a currified
>> syntax for constructors, but right now it is at least conceivable
>> because the application syntax is just a concrete syntax choice, it
>> does not affect typing. Turning unapplied constructor into a function
>> (tuplified or currified) makes it a typing property, observable at
>> specification boundaries: we cannot change it.
>
>
> Hm, I see your point, but don't you already introduce that problem (i.e.,
> commit to tuples) by allowing the `C x` sugar for n-ary constructors?
> Because in a world of curried constructors, `x` would not be typed as the
> tuple of arguments, but only as the first argument of the constructor.
>
> /Andreas
>
>
>
>> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch <alain.frisch@lexifi.com>
>> wrote:
>>>
>>> On 09/11/2015 11:35, Andreas Rossberg wrote:
>>>>
>>>>
>>>> Yes please, I would appreciate such sugar.
>>>
>>>
>>>
>>> I've now submitted a cleaner implementation, working on both expressions
>>> and
>>> patterns:
>>>
>>> https://github.com/ocaml/ocaml/pull/284
>>>
>>>> Even more I would appreciate
>>>> generalising that to allowing constructors to be used as first-class
>>>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
>>>> when C is a constructor with arity > 0). I had to write some AST mapping
>>>> code recently that would have vastly benefited from that.
>>>
>>>
>>>
>>> This is not covered (and now, it could simply be "fun x -> C x" :-)).  I
>>> don't see anything clever to be done on patterns for "unapplied
>>> constructors", though.
>>>
>>>
>>> Alain
>>>
>>>
>>> --
>>> 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
>
>

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 09/11/2015 22:11, Gabriel Scherer wrote:
> Yes, it is already problematic, and in fact I'm personally not
> completely convinced by this feature -- Alain it "reduces bad
> surprises for beginners", but I suspect that adding more magic in this
> place could not actually help that much -- at least the current
> semantic model is simple.

Just to illustrate that the confusion related to n-ary constructors is real:

http://stackoverflow.com/questions/3940345/defining-exceptions-with-tuple-as-argument
http://stackoverflow.com/questions/10306733/ocaml-constructor-unpacking
http://stackoverflow.com/questions/9774671/using-a-variant-type-constructor-with-just-one-tuple-value
http://stackoverflow.com/questions/14818866/int-int-vs-int-int-in-ocaml-sum-type


Now, it's not completely clear that the current proposal is enough to 
reduce significantly the confusion; one could argue that by hiding the 
difference between n-ary constructors and constructors with tuple 
arguments at the value level, one makes it harder for beginners to get 
the right mental model required to understand type inclusion ("type s = 
int * int;; type t = A of s" vs "type t = A of int * int").


-- Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Andreas Rossberg]

> On Nov 9, 2015, at 22:11 , Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
> 
> On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
>> Hm, I see your point, but don't you already introduce that problem (i.e.,
>> commit to tuples) by allowing the `C x` sugar for n-ary constructors?
>> Because in a world of curried constructors, `x` would not be typed as the
>> tuple of arguments, but only as the first argument of the constructor.
> 
> Yes, it is already problematic, and in fact I'm personally not
> completely convinced by this feature -- Alain it "reduces bad
> surprises for beginners", but I suspect that adding more magic in this
> place could not actually help that much -- at least the current
> semantic model is simple.
> 
> Another problem with (C x) is the non-trivial performance implications of
>  | C x -> x
> which actually allocates.

That is already the case for some other patterns, e.g. matching float-only records, isn’t it?

> The problem would only get worse if we allowed
>  type t = { mutable x : int; mutable y : int }
>  type u = Packed of { mutable x : int; mutable y : int }
>  let pack x = Packed x
> with an observable change in mutability semantics from the same code with
>  type u = Packed of t
> (but Alain has not suggested adding this feature to decrease surprises
> (yet?), and luckily our tuples are immutable.)

I haven’t yet used the new records in datatypes feature, but I assume the above would involve to distinct nominal types, so there is no reason to assume them compatible.

> I like the revised syntax choice of writing
>  type t = A of int and int list
> instead of
>  type t = A of int * int list
> which removes the beginner surprise without introducing other
> unpalatable design side-effects. (It is still awkward for GADTs, but
> such is life.)

I am not fond of the revised syntax, because it does not explain why the term-level syntax for constructor application uses tuple notation.

It seems to me that tuples are already engrained in the current syntax and semantics. I doubt it will ever be realistically possible to change their meaning. If you want currying, then the backwards-compatible way would be introducing curried constructors as a new form, in addition to tupled ones. They would have a different type, and nothing would be particularly wrong with that! I would sign a petition for such an extension immediately. :)

/Andreas

> Sometime I think it's wise to avoid local improvements that get stuck
> in local maxima.
> 
> (This is also my argument against Haskell's choice of using the same
> syntax for the pairs (x, y) and the types of pairs (t, u). I guess at
> the time they thought that, of course, they would never get type-level
> pairs.)
> 
> On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
>> On 11/09/2015 07:08 PM, Gabriel Scherer wrote:
>>> 
>>> If we gave a functional semantic to the unapplied constructor, then I
>>> think that good taste would mandate for the application of this
>>> function and the application of the constructor to be equivalent. This
>>> means that by choosing a tuple-taking function, we commit to the
>>> tuple-application syntax (that nobody likes), and that choosing a
>>> currified function creates an unpleasant inconsistency in the
>>> language.
>>> 
>>> I don't know whether we could ever manage to transition to a currified
>>> syntax for constructors, but right now it is at least conceivable
>>> because the application syntax is just a concrete syntax choice, it
>>> does not affect typing. Turning unapplied constructor into a function
>>> (tuplified or currified) makes it a typing property, observable at
>>> specification boundaries: we cannot change it.
>> 
>> 
>> Hm, I see your point, but don't you already introduce that problem (i.e.,
>> commit to tuples) by allowing the `C x` sugar for n-ary constructors?
>> Because in a world of curried constructors, `x` would not be typed as the
>> tuple of arguments, but only as the first argument of the constructor.
>> 
>> /Andreas
>> 
>> 
>> 
>>> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch <alain.frisch@lexifi.com>
>>> wrote:
>>>> 
>>>> On 09/11/2015 11:35, Andreas Rossberg wrote:
>>>>> 
>>>>> 
>>>>> Yes please, I would appreciate such sugar.
>>>> 
>>>> 
>>>> 
>>>> I've now submitted a cleaner implementation, working on both expressions
>>>> and
>>>> patterns:
>>>> 
>>>> https://github.com/ocaml/ocaml/pull/284
>>>> 
>>>>> Even more I would appreciate
>>>>> generalising that to allowing constructors to be used as first-class
>>>>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
>>>>> when C is a constructor with arity > 0). I had to write some AST mapping
>>>>> code recently that would have vastly benefited from that.
>>>> 
>>>> 
>>>> 
>>>> This is not covered (and now, it could simply be "fun x -> C x" :-)).  I
>>>> don't see anything clever to be done on patterns for "unapplied
>>>> constructors", though.
>>>> 
>>>> 
>>>> Alain
>>>> 
>>>> 
>>>> --
>>>> 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
>> 
>> 
> 
> -- 
> 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

Re: [Caml-list] Newbie comment on constructor syntax

[Jeremy Yallop]

On 9 November 2015 at 22:27, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
>> On Nov 9, 2015, at 22:11 , Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
>> I like the revised syntax choice of writing
>>  type t = A of int and int list
>> instead of
>>  type t = A of int * int list
>> which removes the beginner surprise without introducing other
>> unpalatable design side-effects. (It is still awkward for GADTs, but
>> such is life.)
>
> I am not fond of the revised syntax, because it does not explain why the term-level syntax for constructor application uses tuple notation.

In fact, the revised syntax doesn't use tuple notation for constructor
application!  The revised type definition syntax also has a few
additional differences, such as prefix type constructor application,
besides the one Gabriel mentioned.  Here's an example, showing how to
define a data type with a multi-argument constructor and to construct
and match against values, with curried notation:

   # type t = [ A of int and list int ];
   type t = [ A of int and list int ]
   # value x = A 3 [];
   value x : t = A 3 []
   # fun [ A x y -> (x, y) ];
   - : t -> (int * list int) = <fun>

However, partial application of constructors is not supported:

   # A 3;
   Characters 0-3:
     A 3;
     ^^^
   Error: The constructor A expects 2 argument(s),
          but is applied here to 1 argument(s)


Jeremy.

Re: [Caml-list] Newbie comment on constructor syntax

[Hendrik Boom]

On Mon, Nov 09, 2015 at 10:11:30PM +0100, Gabriel Scherer wrote:
> On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg <rossberg@mpi-sws.org> wrote:
> > Hm, I see your point, but don't you already introduce that problem (i.e.,
> > commit to tuples) by allowing the `C x` sugar for n-ary constructors?
> > Because in a world of curried constructors, `x` would not be typed as the
> > tuple of arguments, but only as the first argument of the constructor.
> 
> Yes, it is already problematic, and in fact I'm personally not
> completely convinced by this feature -- Alain it "reduces bad
> surprises for beginners", but I suspect that adding more magic in this
> place could not actually help that much -- at least the current
> semantic model is simple.

If you're looking for a beginner mode that eliminates most surprises, 
the easiest change is to require more explicit type annotations.  Foe 
example, one could require the types of function parameters to be 
explicitly specified.

I find thta this policy makes my code substantially clearer, both to me 
and to the compiler.

--hendrik

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Ocaml Users and Developers,

as a beginner I cannot say much about the rather intricate implications of the various implementation choices. But since a constructor doesn't seem to be a function at all, neither a tuple taking nor a currying one, I would suggest that the constructor declaration syntax makes this clear. e.g. <type a> and <type b> as suggested by Gabriel Scherer. This most likely would avoid some confusion for beginners.

Since both currying and tuple taking constructors can be handy, it would make sense to have "operators", which convert a constructor into a function of the one or the other type. Say if C is a constructor, then C' is a currying function and C" is a tuple taking function. A beginner who comes across this would immediately understand that a constructor is neither a currying nor a tuple taking function, but something else. I guess ' and " wouldn't be possible, but I guess one can find some nice syntax for this. I would prefer to make this conversion explicit rather than an implicit coercion. For beginners it would be a good documentation that there is a difference. As was pointed out in the mail thread, the difference can be hidden to a certain extent, but at some point it would show up and the confusion would be even greater.

The question if the application of a constructor shall follow the tuple or the normal function call style is, as far as I can tell, a purely syntactic choice. Here I would definitely prefer the (C x y) syntax over the C (x, y) simply because I think it is more natural to put the () around an entity rather than at a place where the head symbol gets separated from the arguments. Maybe it be possible to have C of int*int with C (1,2) syntax and C of int and int with (C 1 2) syntax at the same time and promote the latter syntax in tutorials or even give a deprecation warning, but I guess these would then have to be different at the type level.

Another note: it was suggested in this mail thread to enforce type specifications for function arguments to make the life of beginners easier. I would rather not do this. A functional language lives from function arguments and in many cases it is clear what it is and being forced to write this down would be just a nuisance. I enjoy the flexibility to give the types only at interface functions and to leave it away in internal functions where it is clear. People coming from C++, where functional style programming is turned done a lot by the heavy syntax required to write down what you want, will definitely enjoy this. What might help to make the life of beginners easier is to have a compiler option to print the types of all defined functions. I think many people don't start with ocamltop, but with the compiler. In my case I started a project where I thought it is likely easier to learn Ocaml and to write it in Ocaml than to write it in C++. Such projects you don't start with ocamltop. But for high reliability code, it would make sense to have a compiler option to enforce full type specifications of all arguments.

Many thanks for the very interesting and educating discussion!

Best regards,

Michael

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Romain Bardou]

Hello,

In the Mantis thread I proposed that #C or (C) would be the curried 
version of constructor C. I think #C is nice and does not create any 
parsing issue, as constructors are capitalized and if I'm not mistaken 
method names cannot be. And even if they can, # is in a prefix position 
here, it should not create any conflict. (C) was inspired by the syntax 
for symbols like (+), but I like it much less (too many parentheses, one 
extra keystroke, parentheses should just be used for grouping…).

Let's assume that C has arity 2 and we write "C x". I think it would be 
rather confusing if it was not partial application but, instead, x was 
expected to be a pair. On the other hand, "C (x, y)" does look like C is 
an uncurried function. So I don't see any solution that is not confusing 
one way or another, unless we introduce new syntax such as #C.

As a side-note, another wish I have is that one day I'm able to write 
something like #f where f is a field name, to convert it to a getter, 
i.e. (fun x -> x.f). It raises the question of setters as well: ##f to 
get (fun r x -> r.f <- x) or (fun r x -> { r with f = x }). Or, #f is a 
(get, set) pair and we have #?f for the getter only and #!f for the 
setter only. What I'm saying is that if new syntax for constructors is 
added, it would be nice if it were also usable for fields later. This is 
another reason why (C) is bad, as (f) for fields definitely does not work.

I have often had to write (fun x -> C x) by hand, as well as (fun x -> 
x.f), (fun r -> r.f) and (fun r x -> { r with f = x }). In the 
constructor example, quite often C is Some.

I do not often feel the need to write (fun C x -> x) however, except if 
C has arity 2. With arity 1 it already works, and with arity 3 or more I 
usually use a record to name my fields. This may change now that we have 
inline records.

--------- (the rest is off-topic) -----------

By the way, aren't you annoyed to have to write:

   { r with f = { r.f with g = { r.f.g with h = x } } }

especially when field names are long? In one of my programs, I have defined:

   type ('r, 'a) field = { get: 'r -> 'a; set: 'r -> 'a -> 'r }

   let (<.>) f g =
     {
       get = (fun r -> g.get (f.get r));
       set = (fun r x -> f.set r (g.set (f.get r) x));
     }

If #f was a new syntax which built the field record above, we could write:

   (#f <.> #g <.> #h).set r x

Instead of the nested { with ... } above. Of course it would be better 
to just be able to write { r with f.g.h = x } in the first place :)

Cheers,

-- Romain

On 10/11/2015 09:27, Soegtrop, Michael wrote:
> Dear Ocaml Users and Developers,
>
> as a beginner I cannot say much about the rather intricate implications of the various implementation choices. But since a constructor doesn't seem to be a function at all, neither a tuple taking nor a currying one, I would suggest that the constructor declaration syntax makes this clear. e.g. <type a> and <type b> as suggested by Gabriel Scherer. This most likely would avoid some confusion for beginners.
>
> Since both currying and tuple taking constructors can be handy, it would make sense to have "operators", which convert a constructor into a function of the one or the other type. Say if C is a constructor, then C' is a currying function and C" is a tuple taking function. A beginner who comes across this would immediately understand that a constructor is neither a currying nor a tuple taking function, but something else. I guess ' and " wouldn't be possible, but I guess one can find some nice syntax for this. I would prefer to make this conversion explicit rather than an implicit coercion. For beginners it would be a good documentation that there is a difference. As was pointed out in the mail thread, the difference can be hidden to a certain extent, but at some point it would show up and the confusion would be even greater.
>
> The question if the application of a constructor shall follow the tuple or the normal function call style is, as far as I can tell, a purely syntactic choice. Here I would definitely prefer the (C x y) syntax over the C (x, y) simply because I think it is more natural to put the () around an entity rather than at a place where the head symbol gets separated from the arguments. Maybe it be possible to have C of int*int with C (1,2) syntax and C of int and int with (C 1 2) syntax at the same time and promote the latter syntax in tutorials or even give a deprecation warning, but I guess these would then have to be different at the type level.
>
> Another note: it was suggested in this mail thread to enforce type specifications for function arguments to make the life of beginners easier. I would rather not do this. A functional language lives from function arguments and in many cases it is clear what it is and being forced to write this down would be just a nuisance. I enjoy the flexibility to give the types only at interface functions and to leave it away in internal functions where it is clear. People coming from C++, where functional style programming is turned done a lot by the heavy syntax required to write down what you want, will definitely enjoy this. What might help to make the life of beginners easier is to have a compiler option to print the types of all defined functions. I think many people don't start with ocamltop, but with the compiler. In my case I started a project where I thought it is likely easier to learn Ocaml and to write it in Ocaml than to write it in C++. Such projects you don't start with ocamltop
 .
 But for high reliability code, it would make sense to have a compiler option to enforce full type specifications of all arguments.
>
> Many thanks for the very interesting and educating discussion!
>
> Best regards,
>
> Michael
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 10/11/2015 11:25, Romain Bardou wrote:
> In the Mantis thread I proposed that #C or (C) would be the curried
> version of constructor C.

If we go in the direction of making n-ary constructors behave as 
constructor taking a tuple (at the expression level) then it seems 
confusing that #C would mean something different for:

   type t = A of int * int

and for:

   type t = A of (int * int)

Moreover, I'm not sure about the benefit:  how often do you need to 
partially apply a constructor?  And it's easy to define manually the 
helper function (let a x y = A (x, y)) if needed.  I don't think adding 
dedicated syntax is justified here.

Andreas suggested that a non-constant unapplied constructor would be 
interpreted as a function (i.e. just A would be interpreted as (fun x -> 
A x)).  This would allow writing for instance "List.map Some l", and 
have the nice consequence that "Some e" becomes equivalent to "(Some) 
e".  The only drawback I can think of with this idea is less useful 
error locations when changing a constant constructor into a non-constant 
one.

Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Romain Bardou]

On 10/11/2015 11:44, Alain Frisch wrote:
> On 10/11/2015 11:25, Romain Bardou wrote:
>> In the Mantis thread I proposed that #C or (C) would be the curried
>> version of constructor C.
>
> If we go in the direction of making n-ary constructors behave as
> constructor taking a tuple (at the expression level) then it seems
> confusing that #C would mean something different for:
>
>    type t = A of int * int
>
> and for:
>
>    type t = A of (int * int)
>
> Moreover, I'm not sure about the benefit:  how often do you need to
> partially apply a constructor?  And it's easy to define manually the
> helper function (let a x y = A (x, y)) if needed.  I don't think adding
> dedicated syntax is justified here.
>
> Andreas suggested that a non-constant unapplied constructor would be
> interpreted as a function (i.e. just A would be interpreted as (fun x ->
> A x)).  This would allow writing for instance "List.map Some l", and
> have the nice consequence that "Some e" becomes equivalent to "(Some)
> e".  The only drawback I can think of with this idea is less useful
> error locations when changing a constant constructor into a non-constant
> one.
>
> Alain
>

That #C would mean something different for the definitions is an issue 
with the syntax and the semantics of constructor definitions I believe, 
which is already rather confusing :)

That being said it's true that most of the time when I use a constructor 
as a function, the constructor has arity 1. In fact, most of the time it 
is Some.

Cheers,

-- 
Romain Bardou

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 10/11/2015 11:55, Romain Bardou wrote:
> That #C would mean something different for the definitions is an issue
> with the syntax and the semantics of constructor definitions I believe,
> which is already rather confusing :)

This confusion is precisely the one I'm trying to address with GPR#284. 
  At the expression and pattern level, things are pretty clear: 
constructors take 0 or 1 argument.  The only subtlety that remains is 
with the type inclusion relation, but this is not at the expression 
level.  Let's not re-introduce more confusion by making it observable 
again at the expression level whether the constructor was defined as "A 
of (int * int)" or "A of int * int".


Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Romain Bardou]

On 10/11/2015 14:17, Alain Frisch wrote:
> On 10/11/2015 11:55, Romain Bardou wrote:
>> That #C would mean something different for the definitions is an issue
>> with the syntax and the semantics of constructor definitions I believe,
>> which is already rather confusing :)
>
> This confusion is precisely the one I'm trying to address with GPR#284.
>   At the expression and pattern level, things are pretty clear:
> constructors take 0 or 1 argument.  The only subtlety that remains is
> with the type inclusion relation, but this is not at the expression
> level.  Let's not re-introduce more confusion by making it observable
> again at the expression level whether the constructor was defined as "A
> of (int * int)" or "A of int * int".

I see: you do not just propose to have a way to extract a tuple from a 
multi-argument constructor. What you propose is to make all constructors 
have only 0 or 1 argument (which may be a tuple). Under the hood, the 
tuple case is flattened to avoid an allocation, but the programmer does 
not have to know anymore (unless he uses Obj I guess).

That would be a great change I believe.

-- 
Romain

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 10/11/2015 14:41, Romain Bardou wrote:
> I see: you do not just propose to have a way to extract a tuple from a
> multi-argument constructor. What you propose is to make all constructors
> have only 0 or 1 argument (which may be a tuple).

That's what already happen at the syntactic level.  I'm not proposing to 
change that, nor the interpretation of type declarations.  The change is 
how constructor expressions and patterns are type-checked (and 
compiled), in order to make transparent at these levels whether the 
constructor was defined as taking a tuple or several arguments.


> Under the hood, the
> tuple case is flattened to avoid an allocation, but the programmer does
> not have to know anymore (unless he uses Obj I guess).

He still needs to know, since:

  module X : sig    type t = A of int * int end
           = struct type t = A of (int * int) end

would still fail.


Alain

Re: [Caml-list] Newbie comment on constructor syntax

[Romain Bardou]

> That being said it's true that most of the time when I use a constructor
> as a function, the constructor has arity 1. In fact, most of the time it
> is Some.

For the record, I'm writing code right now which contains a rather 
common example with arity 2: binary operators in an AST.

type ast =
   | Plus of t * t
   | ...

let add_list l =
   match l with
     | [] -> ...
     | hd :: tl -> List.fold_left (fun a b -> Plus (a, b)) hd tl

It's not partially applied but it does need to be curried. I'm not 
saying that it justifies a new syntax in itself :)

-- 
Romain

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Alain,

> Moreover, I'm not sure about the benefit:  how often do you need to
> partially apply a constructor?  And it's easy to define manually the helper
> function (let a x y = A (x, y)) if needed.  I don't think adding dedicated syntax
> is justified here.

I see the main benefit of an explicit syntax for "constructor term" vs "currying constructor function" vs "tuple constructor function" in making it obvious that there is such a distinction.

I would agree with Romain, that for record fields a "functionify" operator would be of more practical use and also that it would also make sense to use the same "functionify" operator for different constructs which are not functions but have some obvious conversion into functions.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Hendrik Boom]

On Tue, Nov 10, 2015 at 08:27:52AM +0000, Soegtrop, Michael wrote:
> Dear Ocaml Users and Developers,
...
...
> 
> Another note: it was suggested in this mail thread to enforce type 
> specifications for function arguments to make the life of beginners 
> easier. I would rather not do this. A functional language lives from 
> function arguments and in many cases it is clear what it is and being 
> forced to write this down would be just a nuisance. I enjoy the 
> flexibility to give the types only at interface functions and to leave 
> it away in internal functions where it is clear. People coming from 
> C++, where functional style programming is turned done a lot by the 
> heavy syntax required to write down what you want, will definitely 
> enjoy this.

Please, the problem with C++ for functional programming isn't that you 
have to specify the types of functions; it's that the syntax of types in 
C++ is completely inside-out and insane.  I've been programming in C 
since the 70's and I *still* find it confusing.  OCaml type notation, 
like Algol 68 type notation, is a breath of fresh air by comparison.

And of course, that C++ doesn't have first-class functions.  Or has that 
changed recently?

> What might help to make the life of beginners easier is to 
> have a compiler option to print the types of all defined functions. I 
> think many people don't start with ocamltop, but with the compiler. In 
> my case I started a project where I thought it is likely easier to 
> learn Ocaml and to write it in Ocaml than to write it in C++. Such 
> projects you don't start with ocamltop. But for high reliability code, 
> it would make sense to have a compiler option to enforce full type 
> specifications of all arguments.

In any case, the problem with OCaml's apparent typelessness isn't that 
you don't have to write the types, it's that when you see someone  
else's code you can't read the types.

--- hendr9ik

Re: [Caml-list] Newbie comment on constructor syntax

[immanuel litzroth]

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

1) Recent c++ has several syntaxes for specifying types of functions, see
e.g:
http://en.cppreference.com/w/cpp/utility/functional/function

2) C++ has the equivalent of first class functions.

One of the main problems of  functional programming in C++ is that it
doesn't really
support composition of algorithms very well. This guy explains it very well:
https://www.youtube.com/watch?v=BFnhhPehpKw
Greetz,
i


On Tue, Nov 10, 2015 at 3:11 PM, Hendrik Boom <hendrik@topoi.pooq.com>
wrote:

> On Tue, Nov 10, 2015 at 08:27:52AM +0000, Soegtrop, Michael wrote:
> > Dear Ocaml Users and Developers,
> ...
> ...
> >
> > Another note: it was suggested in this mail thread to enforce type
> > specifications for function arguments to make the life of beginners
> > easier. I would rather not do this. A functional language lives from
> > function arguments and in many cases it is clear what it is and being
> > forced to write this down would be just a nuisance. I enjoy the
> > flexibility to give the types only at interface functions and to leave
> > it away in internal functions where it is clear. People coming from
> > C++, where functional style programming is turned done a lot by the
> > heavy syntax required to write down what you want, will definitely
> > enjoy this.
>
> Please, the problem with C++ for functional programming isn't that you
> have to specify the types of functions; it's that the syntax of types in
> C++ is completely inside-out and insane.  I've been programming in C
> since the 70's and I *still* find it confusing.  OCaml type notation,
> like Algol 68 type notation, is a breath of fresh air by comparison.
>
> And of course, that C++ doesn't have first-class functions.  Or has that
> changed recently?
>
> > What might help to make the life of beginners easier is to
> > have a compiler option to print the types of all defined functions. I
> > think many people don't start with ocamltop, but with the compiler. In
> > my case I started a project where I thought it is likely easier to
> > learn Ocaml and to write it in Ocaml than to write it in C++. Such
> > projects you don't start with ocamltop. But for high reliability code,
> > it would make sense to have a compiler option to enforce full type
> > specifications of all arguments.
>
> In any case, the problem with OCaml's apparent typelessness isn't that
> you don't have to write the types, it's that when you see someone
> else's code you can't read the types.
>
> --- hendr9ik
>
> --
> 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: 3840 bytes --]

RE: [Caml-list] Newbie comment on constructor syntax

[Soegtrop, Michael]

Dear Hendrik,

> And of course, that C++ doesn't have first-class functions.  Or has that
> changed recently?

C++11 claims to be a functional language and supports anonymous functions and currying. But as you say: the syntax of types, especially function types, is rather messy in C/C++.

> In any case, the problem with OCaml's apparent typelessness isn't that you
> don't have to write the types, it's that when you see someone else's code
> you can't read the types.

I don't know how others handle this. I came to the conclusion that it might be a good compromise to write explicit types on interface functions and omit them on internal functions. But as newbie I can't tell how readable this is to others or to me in 5 years.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [Caml-list] Newbie comment on constructor syntax

[Gerd Stolpmann]

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

Am Dienstag, den 10.11.2015, 15:30 +0000 schrieb Soegtrop, Michael:
> Dear Hendrik,
> 
> > And of course, that C++ doesn't have first-class functions.  Or has that
> > changed recently?
> 
> C++11 claims to be a functional language

Hmmm, a language whose name is an assignment...

>  and supports anonymous functions and currying.

That's only a small part of the story. I think more important is how
much control a language gives you about side effects, and AFAIK C++
doesn't let you control much, and common programming practice goes into
the opposite direction (e.g. think of stateful iterators).

Gerd

>  But as you say: the syntax of types, especially function types, is rather messy in C/C++.
> 
> > In any case, the problem with OCaml's apparent typelessness isn't that you
> > don't have to write the types, it's that when you see someone else's code
> > you can't read the types.
> 
> I don't know how others handle this. I came to the conclusion that it might be a good compromise to write explicit types on interface functions and omit them on internal functions. But as newbie I can't tell how readable this is to others or to me in 5 years.
> 
> Best regards,
> 
> Michael
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> 

-- 
------------------------------------------------------------
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: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] Newbie comment on constructor syntax

[Alain Frisch]

On 09/11/2015 19:08, Gabriel Scherer wrote:
> If we gave a functional semantic to the unapplied constructor, then I
> think that good taste would mandate for the application of this
> function and the application of the constructor to be equivalent. This
> means that by choosing a tuple-taking function, we commit to the
> tuple-application syntax (that nobody likes), and that choosing a
> currified function creates an unpleasant inconsistency in the
> language.
>
> I don't know whether we could ever manage to transition to a currified
> syntax for constructors, but right now it is at least conceivable
> because the application syntax is just a concrete syntax choice, it
> does not affect typing. Turning unapplied constructor into a function
> (tuplified or currified) makes it a typing property, observable at
> specification boundaries: we cannot change it.

Making it easier to switch in the distant future to currified 
constructors does not seem a strong argument against improving the 
language now (especially reducing bad surprises for beginners).

The tuple-like syntax is not very much liked, but this is partly caused 
by the fact that arguments cannot be manipulated as real tuples.  With 
the proposed change, this argument goes away.

Moreover, *if* we ever wanted to switch to currified constructors, this 
would not be a purely syntactic rewriting anyway, even with the current 
language.  One would need to have access to constructor declarations to 
drive the rewriting process.  If you one allows oneself to get such 
information out of the type checker, doing the rewriting even in 
presence of the currently suggested changes would be possible as well 
(with extra wrapping/unwrapping).


Alain


>
> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch <alain.frisch@lexifi.com> wrote:
>> On 09/11/2015 11:35, Andreas Rossberg wrote:
>>>
>>> Yes please, I would appreciate such sugar.
>>
>>
>> I've now submitted a cleaner implementation, working on both expressions and
>> patterns:
>>
>> https://github.com/ocaml/ocaml/pull/284
>>
>>> Even more I would appreciate
>>> generalising that to allowing constructors to be used as first-class
>>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)"
>>> when C is a constructor with arity > 0). I had to write some AST mapping
>>> code recently that would have vastly benefited from that.
>>
>>
>> This is not covered (and now, it could simply be "fun x -> C x" :-)).  I
>> don't see anything clever to be done on patterns for "unapplied
>> constructors", though.
>>
>>
>> Alain
>>
>>
>> --
>> 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