Browse thread
How to cleanly encode "quasi-constants"?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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