[Caml-list] ocaml and named constants

[Caml-list] ocaml and named constants

[David Fox]

I've noticed that there is no notion of a named constant in ML.  I
sort of assumed that the compiler could determine that uses of a
variable after a declaration like

  let mpg_joint_stereo = 1

could be compiled as a constant provided the value was never altered
and no references to the variable were created.  Does the compiler
actually do this?  I can't see how it could do it for a variable that
wasn't module local.  I ask because it seems odd that camlp4 includes
a feature for creating real defined constants that are textually
substituted before compilation begins.  Would it be a better bet to
use a function like

  let is_joint_stereo head = (mpg_mode head) = 1

and hope the compiler inlines the function?

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

Re: [Caml-list] ocaml and named constants

[Xavier Leroy]

> I've noticed that there is no notion of a named constant in ML.  I
> sort of assumed that the compiler could determine that uses of a
> variable after a declaration like
> 
>   let mpg_joint_stereo = 1
> 
> could be compiled as a constant provided the value was never altered
> and no references to the variable were created.  Does the compiler
> actually do this?

Yes, ocamlopt does this for integer constants (and "integer-like"
constants such as characters, booleans, constant constructors)
as part of its integer constant propagation phase.

> I can't see how it could do it for a variable that
> wasn't module local.

The information "mpg_joint_stereo is equal to 1" is stored in the .cmx
file associated with the module, along with other cross-module
optimization information.

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

Another motivation could be to get "constant inlining" in bytecode
and for non-integer constants.

> Would it be a better bet to use a function like
> 
>   let is_joint_stereo head = (mpg_mode head) = 1
> 
> and hope the compiler inlines the function?

Inlining and integer constant propagation are performed
simultaneously, so this would be at best equivalent
(if both the function and the constant are inlined) 
or less efficient (if neither is inlined).

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

Re: [Caml-list] ocaml and named constants

[John Max Skaller]

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.

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

Re: [Caml-list] ocaml and named constants

[Andreas Rossberg]

John Max Skaller wrote:
> 
> > 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.

If you allow arbitrary (dynamically determined) values to be matched
against, then pattern matching has unbound cost. It might not even
terminate in the presence of circular values. OTOH, with the current
form, the cost of pattern matching is always linear in the syntactic
size of the match. I think it is good design to have potentially costly
operations explicit.

Moreover, such matching would most likely rely on structural equality.
Although this is not a technical problem since OCaml already has
structural equality, I would at least consider it questionable to
promote its (implicit!) use through such a feature.

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids.
 If Pac Man affected us as kids, we would all be running around in
 darkened rooms, munching pills, and listening to repetitive music."
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml and named constants

[Luc Maranget]

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

Re: [Caml-list] ocaml and named constants

[John Max Skaller]

Andreas Rossberg wrote:

> >         Is there any semantic reason why
> > one cannot use variables, or even expressions? Apart from
> > the obvious syntactic problem.
> 
> If you allow arbitrary (dynamically determined) values to be matched
> against, then pattern matching has unbound cost.

> OTOH, with the current
> form, the cost of pattern matching is always linear in the syntactic
> size of the match. 

	Unless you use a 'when' construct .. which already
provides what I was asking for. The case when this is most
annoying is for 'manifest constants':

	let c1 = 1
	and c2 = 2
	in match expr with
	| x when x = c1 -> ..
	| x when x = c2 -> ..

where the 'match' construction is still arguably cleaner than
an if/then/else chain

	let x = expr in
	if x = c1 then ..
	else if x = c2 then ..

especially if you're actually matching as well:

	match expr with
	| (x,y) when x = c1 -> ...

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

Re: [Caml-list] ocaml and named constants

[Wolfgang Lux]

John Max Skaller wrote

> 	Unless you use a 'when' construct .. which already
> provides what I was asking for. The case when this is most
> annoying is for 'manifest constants':
> 
> 	let c1 = 1
> 	and c2 = 2
> 	in match expr with
> 	| x when x = c1 -> ..
> 	| x when x = c2 -> ..
>

Maybe it's time to ask for a little syntax extension, viz. to allow for 
multiple when clauses in a pattern matching. (This is similar to what 
is allowed e.g. in Haskell already.) Thus the above matching could be 
rewritten as:

  match expr with
    | x when x = c1 -> ..
        when x = c2 -> ..

The syntax for pattern matchings would have to be changed as follows:

 <pattern-matching> ::= ["|"] <case> { "|" <case> }
 <case> ::= <pattern> "->" <expr>
         |  "when" <expr> "->" <expr> { "when" <expr> "->" <expr> }

And a similar change would apply to <multiple-matching>. 

Wolfgang Lux


--
Wolfgang Lux				  Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik	    FAX: +49-251-83-38259
Universitaet Muenster		      Email: wlux@uni-muenster.de
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml and named constants

[Brian Rogoff]

On Tue, 29 May 2001, Luc Maranget wrote:
> > 
> > 	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.

I read a paper on an SML extension to handle this named constant problem,
here at ftp://ftp.research.bell-labs.com/dist/smlnj/papers/92-tr-aitken.ps
Anyone know why this or some similar approach hasn't caught on? The CamlP4 
approach isn't too bad, but this seems important enough to be in the core 
language. 

This is certainly on my "wish list" for future enhancements, since there
are so many cases where named constants are useful and the current
workarounds are a bit ugly. 

-- Brian


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

Re: [Caml-list] ocaml and named constants

[Luc Maranget]

> 
> On Tue, 29 May 2001, Luc Maranget wrote:
> > > 
> > > 	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.
> 
> I read a paper on an SML extension to handle this named constant problem,
> here at ftp://ftp.research.bell-labs.com/dist/smlnj/papers/92-tr-aitken.ps
> Anyone know why this or some similar approach hasn't caught on? The CamlP4 
> approach isn't too bad, but this seems important enough to be in the core 
> language. 
> 
> This is certainly on my "wish list" for future enhancements, since there
> are so many cases where named constants are useful and the current
> workarounds are a bit ugly. 
> 
> -- Brian
> 
> 
I got the reference and the idea (I think).

These are the so-called ``macros (that work!)''
They give you
  1- Mandatory optimizations (aka inlining)
  2- A different syntax for function and constructor application
     both in patterns.

Stuff for making all that cross module boundaries (allowing data
abstraction and pattern-matching to cohabit) looks a bit
complicated and may not be what you want.

But I have another remark
as far a ``manifest constants'' are the issue, Polymorphic
variants
(http://caml.inria.fr/ocaml/htmlman/manual003.html)
seem to do the job.

After all, provided you do not care much about the actual value of Foo)
you can write :

match x with
| `Foo -> ...
| `Bar -> ...
| _    -> ...

In place of

const Foo = 0
const Bar = 1

match x with
| Foo -> ...
| Bar -> ...
| _   -> ...



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

Re: [Caml-list] ocaml and named constants

[Brian Rogoff]

On Thu, 31 May 2001, Luc Maranget wrote:
> But I have another remark
> as far a ``manifest constants'' are the issue, Polymorphic
> variants
> (http://caml.inria.fr/ocaml/htmlman/manual003.html)
> seem to do the job.
> 
> After all, provided you do not care much about the actual value of Foo)

Ah, the problem for me is that I really do care about the actual value for 
the constants. It turns out that I may process binary file formats (GDSII
is the canonical example) where I want the name to correspond to a number. 
Of course, I can and do do it by hand (or use P4) by writing the equivalent of 
Ada's 'Pos and 'Val attributes for enumerated types. I would use plain old 
sum types too since I don't need them to be open for extension. It's a bit 
more cumbersome than I'd like it since I have to specify the mapping twice 
(constructor -> integer and integer -> constructor) which is cumbersome.

-- Brian


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

Re: [Caml-list] ocaml and named constants

[John Max Skaller]

Luc Maranget wrote:

> But I have another remark as far a ``manifest constants'' are the issue, Polymorphic
> variants seem to do the job.
> 
> After all, provided you do not care much about the actual value of Foo)
> you can write :
> 
> match x with
> | `Foo -> ...
> | `Bar -> ...
> | _    -> ...

In the 'real world' the constants are often integers or strings
whose values are dictated by standards, and this technique
requires providing two functions to map the value to and
from variants.

Sometimes this is OK. Sometimes, it is a problem: for example
the library Posix support is lacking all the error codes
and socket options available on some platforms,
and there is no workaround (other than magic).

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

Re: [Caml-list] ocaml and named constants

[David Fox]

Brian Rogoff <bpr@best.com> writes:

> On Thu, 31 May 2001, Luc Maranget wrote:
> > But I have another remark
> > as far a ``manifest constants'' are the issue, Polymorphic
> > variants
> > (http://caml.inria.fr/ocaml/htmlman/manual003.html)
> > seem to do the job.
> > 
> > After all, provided you do not care much about the actual value of Foo)
> 
> Ah, the problem for me is that I really do care about the actual value for 
> the constants. It turns out that I may process binary file formats (GDSII
> is the canonical example) where I want the name to correspond to a number. 

I too run into a lot of situations where I care about the actual value
for my constants because of the various exteral C libraries I use.
However, I am satisfied with the "x when x = a -> ..."  solution if it
gives the same optimization that "3 -> ..." would.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr