Re: [Caml-list] ocaml and named constants

[Luc Maranget <Luc.Maranget@inria.fr>]

> 
> Xavier Leroy wrote:
>  
> > > I ask because it seems odd that camlp4 includes
> > > a feature for creating real defined constants that are textually
> > > substituted before compilation begins.
> > 
> > One motivation for this is to be able to put named constants in
> > patterns, e.g.
> > 
> >      match get_next_byte() with
> >        mpg_joint_stereo -> ...
> >      | mpg_78rpm -> ...
> >      | _ -> ...
> > 
> > which cannot be done in plain ML.
> 
> 	Is there any semantic reason why
> one cannot use variables, or even expressions? Apart from
> the obvious syntactic problem.

Not that obvious, I think this would make pattern-matching look
like even more complicated.
It is good to stress on the fact that
in match .. with p ->, p is a pattern
  1. Some value ``whith holes''
  2. Something we programmer and compiler know without any computation.


Just for the sake of avoiding :
if x=mpg_joint_stereo else if x=... else if ...
I would not throw away the simple idea of what a pattern is.

Now the usual Caml answer to such extension of patterns
(the same apply to non-linear patterns such as (x,x))

If you want pattern matching, you can have it !

   match get_next_byte() with
        x when x = mpg_joint_stereo -> ...
      | x when x = mpg_78rpm -> ...
      | _ ->
And, when the mpg_xxx are known constants
some optimization (which does not exist now) could apply, such as
replacing pattern ``x when x=1''  by pattern ``1''.

Hence we need no extension for doing what you wish, we only need more
optimisations.


On the other hand, if we extend pm the way you want
(if I got it right let us assume a backquoting mecanism)
     match get_next_byte() with
        << mpg_joint_stereo >> -> ...
      | << mpg_78rpm >> -> ...
      | _ -> ...
Then we should treat the general case, and 
the semantics can only be
let x = get_next_byte in
if x=mpg_... etc.

The overall benefit of including such a feature is not very clear for me.
Compilation difficulties and programmer errors are, IMHO. on the way.




 -- 
> John (Max) Skaller, mailto:skaller@maxtal.com.au
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr