[Caml-list] The rec/nonrec debate

[Caml-list] The rec/nonrec debate

[Dario Teixeira]

Hi,


As you know, there is in OCaml some asymmetry regarding the rec/nonrec 
defaults for type and value declarations.  Types are recursive by default
and there's no way to "unrecurse" them, whereas values are by default not
recursive and can be made recursive via the "rec" keyword.

The unrecursiveness of type declarations is cause for some chagrin, as a 
recent ticket on Mantis demonstrates [1].

Here's something I wonder: if one were to wipe the slate clean, is there 
consensus among the community about the best defaults?  I'm leaning towards
having nonrec as the default behaviour for *both* types and values, and
using "rec" as the keyword for recursive types and values.  This scheme
would obviate the need for an actual "nonrec" keyword.

Obviously, such a change would be too intrusive to make to OCaml.  However, 
since people are working on "Next Generation ML" languages like Mezzo [2],
I think it would be good to get the community's pulse on this subject.
(Btw, from the examples posted on Mezzo's homepage, it seems to use the
same defaults as OCaml).

Your thoughts?

Best regards,
Dario Teixeira

[1] http://caml.inria.fr/mantis/view.php?id=6016
[2] http://gallium.inria.fr/~protzenk/mezzo-lang/

Re: [Caml-list] The rec/nonrec debate

[David House]

At Jane Street we have a syntax extension that allows one to write
"type nonrec t = ...".

I too think that non-recursive is the right default. My argument is
mostly as follows: it's nice to have nonrecursive values be the
default, because shadowing is so useful. And it's confusing to have
two different defaults for types and values.

I also agree that we can't change this for ocaml.

On 20 May 2013 15:31, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> Hi,
>
>
> As you know, there is in OCaml some asymmetry regarding the rec/nonrec
> defaults for type and value declarations.  Types are recursive by default
> and there's no way to "unrecurse" them, whereas values are by default not
> recursive and can be made recursive via the "rec" keyword.
>
> The unrecursiveness of type declarations is cause for some chagrin, as a
> recent ticket on Mantis demonstrates [1].
>
> Here's something I wonder: if one were to wipe the slate clean, is there
> consensus among the community about the best defaults?  I'm leaning towards
> having nonrec as the default behaviour for *both* types and values, and
> using "rec" as the keyword for recursive types and values.  This scheme
> would obviate the need for an actual "nonrec" keyword.
>
> Obviously, such a change would be too intrusive to make to OCaml.  However,
> since people are working on "Next Generation ML" languages like Mezzo [2],
> I think it would be good to get the community's pulse on this subject.
> (Btw, from the examples posted on Mezzo's homepage, it seems to use the
> same defaults as OCaml).
>
> Your thoughts?
>
> Best regards,
> Dario Teixeira
>
> [1] http://caml.inria.fr/mantis/view.php?id=6016
> [2] http://gallium.inria.fr/~protzenk/mezzo-lang/
>
>
> --
> 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] The rec/nonrec debate

[Julien Blond]

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

I agree that making recursitivy more explicit is... well... more explicit
:) But I wonder if, in this case, this is truly relevant. In fact, when I
look at OCaml programs, I see many recursive types and very few type
shadowing. That is, making types non recursive would add some "rec" or
"nonrec" keywords everywhere just to avoid a type alias in a rare case.
From readability point of view, I'm not sure it's a good deal. In the
programs I know, the ratio seems to be something like 70/30 for nonrec/rec
function while, this time, shadowing is quite often used. Here, explicit
"rec" allows us to avoid more "nonrec" elsewhere to continue using
shadowing.



2013/5/20 David House <dhouse@janestreet.com>

> At Jane Street we have a syntax extension that allows one to write
> "type nonrec t = ...".
>
> I too think that non-recursive is the right default. My argument is
> mostly as follows: it's nice to have nonrecursive values be the
> default, because shadowing is so useful. And it's confusing to have
> two different defaults for types and values.
>
> I also agree that we can't change this for ocaml.
>
> On 20 May 2013 15:31, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> > Hi,
> >
> >
> > As you know, there is in OCaml some asymmetry regarding the rec/nonrec
> > defaults for type and value declarations.  Types are recursive by default
> > and there's no way to "unrecurse" them, whereas values are by default not
> > recursive and can be made recursive via the "rec" keyword.
> >
> > The unrecursiveness of type declarations is cause for some chagrin, as a
> > recent ticket on Mantis demonstrates [1].
> >
> > Here's something I wonder: if one were to wipe the slate clean, is there
> > consensus among the community about the best defaults?  I'm leaning
> towards
> > having nonrec as the default behaviour for *both* types and values, and
> > using "rec" as the keyword for recursive types and values.  This scheme
> > would obviate the need for an actual "nonrec" keyword.
> >
> > Obviously, such a change would be too intrusive to make to OCaml.
>  However,
> > since people are working on "Next Generation ML" languages like Mezzo
> [2],
> > I think it would be good to get the community's pulse on this subject.
> > (Btw, from the examples posted on Mezzo's homepage, it seems to use the
> > same defaults as OCaml).
> >
> > Your thoughts?
> >
> > Best regards,
> > Dario Teixeira
> >
> > [1] http://caml.inria.fr/mantis/view.php?id=6016
> > [2] http://gallium.inria.fr/~protzenk/mezzo-lang/
> >
> >
> > --
> > 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
>

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

Re: [Caml-list] The rec/nonrec debate

[David House]

On 20 May 2013 16:18, Julien Blond <julien.blond@gmail.com> wrote:
> I agree that making recursitivy more explicit is... well... more explicit :)
> But I wonder if, in this case, this is truly relevant. In fact, when I look
> at OCaml programs, I see many recursive types and very few type shadowing.

Interesting. I think I see the opposite. Although both are reasonably common.

Re: [Caml-list] The rec/nonrec debate

[Dario Teixeira]

Hi,

> I agree that making recursitivy more explicit is... well... more explicit :)
> But I wonder if, in this case, this is truly relevant. In fact, when I look at
> OCaml programs, I see many recursive types and very few type shadowing.
> That is, making types non recursive would add some "rec" or "nonrec"
> keywords everywhere just to avoid a type alias in a rare case. From
> readability point of view, I'm not sure it's a good deal. In the programs
> I know, the ratio seems to be something like 70/30 for nonrec/rec function
> while, this time, shadowing is quite often used. Here, explicit "rec" allows
> us to avoid more "nonrec" elsewhere to continue using shadowing.


In my opinion, even if a statistical analysis of a large corpus of OCaml code
were to show that shadowing is much rarer than recursive type definitions,
the case could still be made that having nonrec as the common default
for both types and values would still be preferable for a) consistency, and
b) avoiding the need to have both "rec" and "nonrec" as keywords.

On a tangent, I also find it interesting that Mezzo has adopted the Haskell
convention of type declarations being head-first.  Not that I disagree: in fact,
one could argue there is some inconsistency in the ML/OCaml convention
of declaring types head-last and values head-first...

Cheers,
Dario

Re: [Caml-list] The rec/nonrec debate

[Richard W.M. Jones]

On Mon, May 20, 2013 at 09:18:48AM -0700, Dario Teixeira wrote:
> On a tangent, I also find it interesting that Mezzo has adopted the
> Haskell convention of type declarations being head-first.  Not that
> I disagree: in fact, one could argue there is some inconsistency in
> the ML/OCaml convention of declaring types head-last and values
> head-first...

IME the OCaml convention is an endless source of confusion for
programmers coming from other languages.  For example compared to
C++'s vector<T>.

By the way, why does Mezzo have to be a completely new language?
Just change the syntax of OCaml and force people to put:

  syntax 4.00;;

at the top of old code (default to new syntax).  The worst that
happens is you have to carry around lots of old parsers in your
compiler.

Rich.

Re: [Caml-list] The rec/nonrec debate

[Dario Teixeira]

Hi,

> IME the OCaml convention is an endless source of confusion for

> programmers coming from other languages.  For example compared to
> C++'s vector<T>.
> 
> By the way, why does Mezzo have to be a completely new language?
> Just change the syntax of OCaml and force people to put:

Well, the Mezzo team can correct me on this, but my impression is that
Mezzo is a research project in a preliminary stage.  They have a new
type system based on permissions, which seems like an interesting
approach to manage side-effects without the disadvantages of monads
or the solutions used by languages such as Clean or Disciple.  But of
course, the question remains whether this new approach will prove to
be convenient in practice.  There's always the risk of straying too much
away from the convenience of ML, and creating a type system which
though more powerful than ML's, has the disadvantage that requires too
many type annotations (type inference may not be easy in your new
type system), or produces undecipherable error messages...

In any case, Mezzo is very different from OCaml, so it makes sense
to call it a new language.  And while they're at it, it also makes sense
to start afresh with a cleaner syntax which incorporates the lessons
that the Caml community learnt over the past couple of decades --
like rec/nonrec/shadowing situation, or making type and value
declarations uniformly head-first.

Cheers,
Dario

Re: [Caml-list] The rec/nonrec debate

[Török Edwin]

On 05/20/2013 05:31 PM, Dario Teixeira wrote:
> Obviously, such a change would be too intrusive to make to OCaml.  However, 
> since people are working on "Next Generation ML" languages like Mezzo [2],
> I think it would be good to get the community's pulse on this subject.
> (Btw, from the examples posted on Mezzo's homepage, it seems to use the
> same defaults as OCaml).
> 
> Your thoughts?

Functions should definitely be non-recursive by default (like in OCaml), to at
least explicitly make you think about the termination/stack usage consequences.

For types I'd prefer non-recursive by default, but only for consistency reasons.

For 'rec' on functions it'd be nice if there was a way to require
tail-recursivity, and have the compiler reject the code if its not actually
tail-recursive or calls non-tail-recursive functions.
But what should be the default? If we apply the same reasoning as for 'rec'
(require explicity action for possibly unsafe structure), then
tail-recursive-required should be default, and you'd need a 'nontail' keyword.
That may be somewhat unpractical though, as most tree-handling code would have
to be full of 'nontail'.

Perhaps a more practical approach would be to have this only at the
documentation level, i.e. Mezzo's equivalent of ocamldoc would show a red 'non
tail recursive' marker in the function's doc to alert users to the
non-tail-recursive functions (and a green tail-recursive marker for others).
In fact this might be a nice improvement to ocamldoc too.

Best regards,
--Edwin

Re: [Caml-list] The rec/nonrec debate

[Dario Teixeira]

Hi,
 

> Perhaps a more practical approach would be to have this only at the
> documentation level, i.e. Mezzo's equivalent of ocamldoc would show a red 
> 'non tail recursive' marker in the function's doc to alert users to the
> non-tail-recursive functions (and a green tail-recursive marker for others).
> In fact this might be a nice improvement to ocamldoc too.

Yeah, I agree that having explicit tail/nontail keywords would be a bit much,
and perhaps this particular problem would be better solved at a different level.
It would be indeed great if an OCamldoc-like tool were to make this explicit.
Another good place to make this analysis would be in some sort of OCaml-lint.

Cheers,
Dario

[Caml-list] Re: The rec/nonrec debate

[Hongbo Zhang]

On 5/20/13 10:31 AM, Dario Teixeira wrote:
> Hi,
>
Hi,
    I would like to have a self keyword (for the convenience of 
copy-paste and metaprogramming :-))

--------------
    type 'a t = A of 'a self | B of 'a self | C of string

    type 'a t1 = A of 'a self | B of 'a self | C of string | D of int
----
    If we don't like to introduce a new keyword, just replace self with 
an existing keyword , e.g, rec.
>
> As you know, there is in OCaml some asymmetry regarding the rec/nonrec
> defaults for type and value declarations.  Types are recursive by default
> and there's no way to "unrecurse" them, whereas values are by default not
> recursive and can be made recursive via the "rec" keyword.
>
> The unrecursiveness of type declarations is cause for some chagrin, as a
> recent ticket on Mantis demonstrates [1].
>
> Here's something I wonder: if one were to wipe the slate clean, is there
> consensus among the community about the best defaults?  I'm leaning towards
> having nonrec as the default behaviour for *both* types and values, and
> using "rec" as the keyword for recursive types and values.  This scheme
> would obviate the need for an actual "nonrec" keyword.
>
> Obviously, such a change would be too intrusive to make to OCaml.  However,
> since people are working on "Next Generation ML" languages like Mezzo [2],
> I think it would be good to get the community's pulse on this subject.
> (Btw, from the examples posted on Mezzo's homepage, it seems to use the
> same defaults as OCaml).
>
> Your thoughts?
>
> Best regards,
> Dario Teixeira
>
> [1] http://caml.inria.fr/mantis/view.php?id=6016
> [2] http://gallium.inria.fr/~protzenk/mezzo-lang/
>
>

Re: [Caml-list] The rec/nonrec debate

[Alain Frisch]

On 05/20/2013 04:31 PM, Dario Teixeira wrote:
> The unrecursiveness of type declarations is cause for some chagrin, as a
> recent ticket on Mantis demonstrates [1].

As I explain on this Mantis ticket, I don't believe that the implicit 
recursiveness of type declarations is the real cause of the problem. 
The same problem would still exist if the type declarations were 
non-recursive by default or if we add a "nonrec" modifier.  Consider:


   type t = X | Y

   module M = struct
      type t = A | B

      type s = {
       foo: (* I cannot refer to the outer "t" *);
       bar: t
      }
   end

What's missing, in my opinion, is not really a way to control 
recursiveness of type declarations, but rather to refer to components 
from outer scopes.


Alain

Re: [Caml-list] The rec/nonrec debate

[Boris Yakobowski]

On Tue, May 21, 2013 at 10:25 AM, Alain Frisch <alain@frisch.fr> wrote:
> What's missing, in my opinion, is not really a way to control recursiveness
> of type declarations, but rather to refer to components from outer scopes.

We (the Frama-C team) tend to agree with this analysis. Within
Frama-C, most types are called "t" because of signature constraints,
and the impossibility to refer to a previous instances of t is a real
problem.

--
Boris