RE: [Caml-list] zero-arity constructor

[David Allsopp <dra-news@metastack.com>]

Mark Adams wrote:
> Surely it's preferable to use a syntactically distinct mechanism for this
> subtly different concept.  Given that we're talking about patterns and not
> general expressions here, surely there's plenty of space in the syntax.
> Perhaps something like '*' to mean 0 or more.

Even accepting that _ is already "broken" (well, a special case) as bluestorm explained in terms of that lovely beginners' and not-so-beginners' trap [Foo of int * int] vs [Foo of (int * int)], allowing _ with 0-arity constructors does feel odd, and I don't really want to have to pepper my Makefile rules with -w +28. My personal preference would be that Warning 28 were on by default and that there were a compiler pragma available which camlp4 could use *in the generated ML code* to suppress it (I'm thinking of the MSVC-specific #pragma warning disable 28 - http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx).

> Or is it already too late
> because '_' has already been incorporated and backwards compatibility
> dictates that this cannot be changed?

Presumably there are some camlp4 extensions already taking advantage of it or it wouldn't have been added. But there'd be no reason not to add something as you propose (so [Foo *] for type t = Foo) and set Warning 28 to be on by default for [Foo _] - that would simply mean that 3.11/3.12 code using that syntax would emit warnings in "3.13" rather than actually breaking (unless you've including -warn-error - but that's always seemed to me to be a development option, not a release option...)


David
 

> 
> type ty = A | B
> 
> let test = function
> | A * -> ()
> | B -> ()
> 
> Mark Adams
> 
> on 26/11/10 10:35 PM, bluestorm <bluestorm.dylc@gmail.com> wrote:
> 
> > A quick summary for those like me that didn't follow the change and
> > were baffled to find out that "it's not a bug, it's a feature".
> >
> > The change was asked for by Alain Frisch in 2006 (
> > http://caml.inria.fr/mantis/view.php?id=4052 ) and finally added in
> > ocaml 3.11. The rationale is to make it easy to mechanically -- think
> > camlp4 or another preprocessor -- generate pattern clauses to test for
> > the head constructor of a data type, ignoring it's parameter.
> > Before that change, (K _) would work for all constructors K of arity
> greater
> > than 1, but not for arity 0. After the change, (K _) work even for
> constant
> > constructors. Generating a match clause that says "looks if it's the
> > constructor K, I don't care about the arguments" is much easier as you
> don't
> > have to carry  arity information around.
> >
> > The downside of this behaviour is that the universal pattern _ has an
> > different meaning in this setting. It does not only matches any value
> > (as the manual says :
> > http://caml.inria.fr/pub/docs/manual-ocaml/patterns.html
> > ),
> > but also "matches any number of arguments, possibly 0". The nice
> > compositional interpretation of patterns -- K (p1, .., pN) matches a
> > value with constructor K and whose N arguments match p1..pN -- is lost.
> > Note that this was already the case before the change suggested by
> > Alain Frisch : _ would work for two-arguments constructors as well,
> > while a
> named
> > variable wouldn't -- this is well-known subtle difference between (Foo
> > of
> a
> > * b) and (Foo of (a * b)). The pattern _ ignored any non-zero number
> > of arguments.
> >
> > Note that since ocaml 3.12, there is a warning available for this very
> > error.
> >
> > $ ocaml -warn-help
> > [...]
> > 28 Wildcard pattern given as argument to a constant constructor.
> > [...]
> >
> > $ cat test.ml
> > type ty = A | B
> >
> > let test = function
> > | A _ -> ()
> > | B -> ()
> >
> > $ ocaml -w +28 test.ml
> > File "test.ml", line 4, characters 4-5:
> > Warning 28: wildcard pattern given as argument to a constant
> > constructor
> >
> > I think than, in the end, it's all a matter of compromise.
> >
> > Thanks to Julia and Mehdi for casting light on the dark corners of the
> ocaml
> > syntax!
> >
> > PS : I haven't found that behaviour documented anywhere. Maybe it
> > would be good to describe that special behaviour of _ on constructors
> > in the
> manual?
> >
> > On Fri, Nov 26, 2010 at 11:02 PM, Julia Lawall <julia@diku.dk> wrote:
> >
> >> On Fri, 26 Nov 2010, Mehdi Dogguy wrote:
> >>
> >> > On 11/26/2010 10:46 PM, Julia Lawall wrote:
> >> > > The following code compiles in 3.12.0 but doesn't compile in
> 3.10.2.
> >> > > Is it a bug or a feature?
> >> > >
> >> >
> >> > It's a feature that was implemented in 3.11.0 (iirc).
> >> >
> >> > See: http://caml.inria.fr/mantis/view.php?id=4675 (and other
> >> > related bugreports).
> >>
> >> OK, thanks.  I agree wth those that don't like the change...
> >>
> >> julia
> >>
> >> _______________________________________________
> >> Caml-list mailing list. Subscription management:
> >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> >> Archives: http://caml.inria.fr
> >> 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:
> > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> > Archives: http://caml.inria.fr
> > 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:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs