Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
How to cleanly encode "quasi-constants"?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Rogoff <bpr@b...>
Subject: Re: How to cleanly encode "quasi-constants"?
On Mon, 26 Jun 2000, Daniel de Rauglaudre wrote:
> Hello,
> On Fri, Jun 23, 2000 at 04:27:00PM +0200, Remi VANICAT wrote:
> > I have a question about this : is there a way to make easily a compile
> > time constants?
> > (if i have a let var = func constant_argument, and i know that this
> > can't change from an execution to an other, i want it to be evaluated
> > only once)
> You can use preprocessors: i.e. /lib/cpp (general) or Camlp4 (specific to
> Ocaml). In Camlp4, you can do that with "quotations". (I am not sure that
> "easily" is appropriate... :-): you have to learn how Camlp4 works).

This is one of the many very useful features of CamlP4. The desire to do
define compile time constants comes up a lot in my day-to-day
programming, for instance when writing tools to process a particular file
format which uses numbers to indicate types in some way (I'm thinking of
GDSII here). 

One issue with using CamlP4 which has been brought up before is that there 
seems to be some emerging consensus on using ">>" and "<<" for function 
composition, and there is a clash with CamlP4's use of these tokens. Is
there a good solution to this?

I admit I'm also fond of the Revised syntax. Some of our users have a
tough time with OCaml syntax (we have a program which is configured by a 
dynamically loaded file) and some of the changes of Revised
(distinguishing let ... = ...;; from let ... = exp in ..., do .. return e, 
 forced parenthesization of tuples, forcing "&&" and "||", ...) would have 
probably avoided some complaints from these users, who are mostly used to 
C, Perl, and Scheme syntaxes.

-- Brian