Re: How to cleanly encode "quasi-constants"?

Re: How to cleanly encode "quasi-constants"?

[Marcin 'Qrczak' Kowalczyk]

Tue, 27 Jun 2000 12:12:50 -0700 (PDT), Brian Rogoff <bpr@best.com> pisze:

> I admit I'm also fond of the Revised syntax.

Sorry, I'm new: what is the Revised syntax? Where can I read about it?

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/            GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

Re: How to cleanly encode "quasi-constants"?

[Daniel de Rauglaudre]

Hello,

> Tue, 27 Jun 2000 12:12:50 -0700 (PDT), Brian Rogoff <bpr@best.com> pisze:
> 
> > I admit I'm also fond of the Revised syntax.
> 
> Sorry, I'm new: what is the Revised syntax? Where can I read about it?

It is a alternative syntax for Ocaml proposed in Camlp4, supposed to
fix some syntax problems in the language.

     http://caml.inria.fr/camlp4/manual/

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Re: How to cleanly encode "quasi-constants"?

[Julian Assange]

Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:

> Hello,
> 
> > Tue, 27 Jun 2000 12:12:50 -0700 (PDT), Brian Rogoff <bpr@best.com> pisze:
> > 
> > > I admit I'm also fond of the Revised syntax.
> > 
> > Sorry, I'm new: what is the Revised syntax? Where can I read about it?
> 
> It is a alternative syntax for Ocaml proposed in Camlp4, supposed to
> fix some syntax problems in the language.
> 
>      http://caml.inria.fr/camlp4/manual/

The revised syntax is cleaner, but drops so much syntactic sugar, that the 
language becomes ugly due to its verbosity.

Cheers,
Julian.

Re: How to cleanly encode "quasi-constants"?

[Brian Rogoff]

On 1 Jul 2000, Julian Assange wrote:
> The revised syntax is cleaner, but drops so much syntactic sugar, that the 
> language becomes ugly due to its verbosity.

As usual, opinions like this are much more useful and interesting when 
butressed by concrete examples. What's the sugar you miss, infixes? 
You can use p4 to get those. Something else? 

-- Brian

Re: How to cleanly encode "quasi-constants"?

[Marcin 'Qrczak' Kowalczyk]

01 Jul 2000 20:01:54 +1000, Julian Assange <proff@iq.org> pisze:

> The revised syntax is cleaner, but drops so much syntactic sugar,
> that the language becomes ugly due to its verbosity.

It introduces many []'s. Haskell uses optional layout to avoid that
many brackets and separators. In OCaml it would look similar to this:

value rec iter_row f row = do
    List.iter
       (fun (_, fi) -> match row_field_repr fi with
            Rpresent (Some ty) -> f ty
            Reither _ tl _     -> List.iter f tl
            _                  -> ())
       row.row_fields
    return (match (repr row.row_more).desc with
        Tvariant row -> iter_row f row
        Tvar -> do
            Misc.may (fun (_, l) -> List.iter f l) row.row_name
            return (List.iter f row.row_bound)
        _ -> assert False)

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/            GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

RE: How to cleanly encode "quasi-constants"?

[Don Syme]

You have spotted a problem with ML-style type systems - they are not great
at encoding the kind of "phasing" of initialization that you refer to
(neither most are other type systems, though of course one could imagine a
type system that allowed you to express this sort of thing).  However, the
"constants" you refer to can encode quite complex computations (including
allocation of data structures, e.g. let x = [2;3;5]]), which is a big
advantage compared to, say, C, but it does not cover everything.  So in
practice people tend to make do with constant values until the
initialization sequence gets too complicated, then move to references, but
with the knowledge that these references are set once-for-all.  Hiding the
references behind functions is, as you say, often a good idea.

Basically, don't be afraid of using references for this kind of thing - it's
one of the reasons they are in the language.

Cheers,
Don


-----Original Message-----
From: David.Mentre@irisa.fr [mailto:David.Mentre@irisa.fr]
Sent: 20 June 2000 17:00
To: caml-list@inria.fr
Subject: How to cleanly encode "quasi-constants"?


Hello dear camlists,

I'm still learning caml and functionnal programming, so this is maybe a
newbie question. Please don't be too rude.

In my program, I have variables that can only be modified once
(potentially at initialization time after parsing command line and done
some computation) and then are never modified for a very long time (rest
of program execution). I call them "quasi-constants", they have a
write-once semantic. They are used throught the program so it is very
painfull to propagate them along function calls (i.e. these variables
need a global scope, at least from a programmer point of view).

Right now, I'm using constants (let var = ...) or mutable references
(let var := ...) to encode such things.

However I'm not satisfied. With constants, I obviously can only modify
them at compile time. With mutables, I can modify them but potentially
at any time, meaning potential bugs. So my question is: 

 What is the Right Way(tm) to encode such a thing in an ML like
 language and more specifically in OCaml?

I was thinking of using a functor (return a module with functions
referencing these quasi-constants and quasi-constants values given at
module creation). Is it right? It is also possible to use functions,
however is seems impracticable for a real program (this approach creates
a function many pages long):

# let create_manipulator v =
  let f1 () = v 
  and f2 x = v+x in (f1, f2);;
  val create_manipulator : int -> (unit -> int) * (int -> int) = <fun>
# let (g1, g2) = create_manipulator 3;;
val g1 : unit -> int = <fun>
val g2 : int -> int = <fun>
# g1 ();;
- : int = 3


Two side questions:

 - is there such a problem tackled in a big program ? (ocaml compiler?)

 - it seems to me that Arg.Set and Arg.Clear types have this semantic
   (an option is only set at parse time).



Best regards,
david
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

How to cleanly encode "quasi-constants"?

[David Mentré]

Hello dear camlists,

I'm still learning caml and functionnal programming, so this is maybe a
newbie question. Please don't be too rude.

In my program, I have variables that can only be modified once
(potentially at initialization time after parsing command line and done
some computation) and then are never modified for a very long time (rest
of program execution). I call them "quasi-constants", they have a
write-once semantic. They are used throught the program so it is very
painfull to propagate them along function calls (i.e. these variables
need a global scope, at least from a programmer point of view).

Right now, I'm using constants (let var = ...) or mutable references
(let var := ...) to encode such things.

However I'm not satisfied. With constants, I obviously can only modify
them at compile time. With mutables, I can modify them but potentially
at any time, meaning potential bugs. So my question is: 

 What is the Right Way(tm) to encode such a thing in an ML like
 language and more specifically in OCaml?

I was thinking of using a functor (return a module with functions
referencing these quasi-constants and quasi-constants values given at
module creation). Is it right? It is also possible to use functions,
however is seems impracticable for a real program (this approach creates
a function many pages long):

# let create_manipulator v =
  let f1 () = v 
  and f2 x = v+x in (f1, f2);;
  val create_manipulator : int -> (unit -> int) * (int -> int) = <fun>
# let (g1, g2) = create_manipulator 3;;
val g1 : unit -> int = <fun>
val g2 : int -> int = <fun>
# g1 ();;
- : int = 3


Two side questions:

 - is there such a problem tackled in a big program ? (ocaml compiler?)

 - it seems to me that Arg.Set and Arg.Clear types have this semantic
   (an option is only set at parse time).



Best regards,
david
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

Re: How to cleanly encode "quasi-constants"?

[Christian Rinderknecht]

Hi David,

I think it's worth reading the caml-list thread "one-time initialization",
starting at http://caml.inria.fr/caml-list/1005.html.

Personnally, in the particular situation you mention, I would do the
following.

In a Second(ary) module you define a functor taking as argument a module
with all the globals you need.

second.mli
----------

module type S =
  sig
    type type0 = ...
    val const0 : type0
  end

module Run (Args : S) : 
  sig 
    val entry_point : unit -> unit
  end

second.ml
---------
module type S =
  sig
    type type0 = ...
    val const0 : type0
    ...
  end

module Run = functor (M : S) ->
  struct
    open M
    ... (* From here you handle "real" constants" [const0] etc. *)
    let entry_point () = ...
  end

By the way, note that in OCaml, contrary to SML, you cannot define a
functor at top-level (this would require extra syntax), i.e. whose name is
mapped to a file name.


Now in your Main module:

main.ml
-------

module Args =
  struct
    type type0 = ...
    let quasi_const0 : (type0 option) ref = ref (None)
    ...

    let _ = Arg.parse .... (* Initialization by side-effects of
                              [quasi_const0] etc. *)

    let const0 = 
      match !quasi_const0 with
        None -> failwith "Missing arg" (* Or whatever *)
      | Some (v) -> v
    ...

  end

module Go = Second.Run (Args)

let _ = Go.entry_point ()


Note that name [Go] is necessary (Second.Run(Args).enty_point() does
not work).


Hope this helps,


Christian

--------------------------------------------------------------------
Christian Rinderknecht          Christian.Rinderknecht@polyspace.com
PolySpace Technologies          Tel: 04.76.61.54.17
c/o INRIA                       Fax: 04.76.61.54.09
655, Av. de l'Europe            http://www.polyspace.com/
F-38330 Montbonnot St Martin

On 20 Jun 2000, David Mentré wrote:

> In my program, I have variables that can only be modified once
> (potentially at initialization time after parsing command line and done
> some computation) and then are never modified for a very long time (rest
> of program execution).

Re: How to cleanly encode "quasi-constants"?

[Daniel de Rauglaudre]

> Right now, I'm using constants (let var = ...) or mutable references
> (let var := ...) to encode such things.
> 
> However I'm not satisfied. With constants, I obviously can only modify
> them at compile time. With mutables, I can modify them but potentially
> at any time, meaning potential bugs.

I am not sure I understand your point, but the construction "let var =
..." does not define *compile time* constants: the expression "..." is
computed at *run time*. It can be any computation.

Typically, a program using the Xlib would start with:
    let dpy = xOpenDisplay "" in ...

The computation of xOpenDisplay "" is a very complicated computation of the
Xlib, creating a connection to the X server. But the variable "dpy" is not
mutable and then is never modified nor modifiable in the rest of the program.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Re: How to cleanly encode "quasi-constants"?

[Remi VANICAT]

Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:

> I am not sure I understand your point, but the construction "let var =
> ..." does not define *compile time* constants: the expression "..." is
> computed at *run time*. It can be any computation.

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)

-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat

Re: How to cleanly encode "quasi-constants"?

[Pierre Weis]

> 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)
> 
> -- 
> Rémi Vanicat
> vanicat@labri.u-bordeaux.fr
> http://dept-info.labri.u-bordeaux.fr/~vanicat

When you have a definition in a program as:

 let var = func constant_argument;;

then the value to bind to var is evaluated once and for all, i.e.
the expression ``func constant_argument'' will be evaluated and its
value bound to var.

Strictly speaking, this is not evaluated at compiled time: it is
evaluated at ``launch time'' when the program is initialized. In
effect this cannot be evaluated at compile time, since it would
necessitate the compiler to have acces to the ``func'' function, hence
to have access to all the functions accessed from ``func'''s body,
hence potentially access to the entire program. It means the compiler
should evaluate an unrestricted computation. Since we donnot want to
have the compiler looping, we thus need to detect looping programs and
this is not trivial (!).

If you can compute the constants by another Caml program of your own,
you can write those constants directly in your code: this way they
would not be computed at runtime as desired.

All the best,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: How to cleanly encode "quasi-constants"?

[Julian Assange]

Pierre Weis <Pierre.Weis@inria.fr> writes:

> have the compiler looping, we thus need to detect looping programs and
> this is not trivial (!).

This work can be performed by the user with the aid of a device known
as a `bordometer'. Compile-time evulation by lisp and scheme compilers
is incredibly useful, and I see no particular reason caml could not
apply the same technique.

Cheers,
Julian.

Re: How to cleanly encode "quasi-constants"?

[Daniel de Rauglaudre]

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

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/

Re: How to cleanly encode "quasi-constants"?

[Brian Rogoff]

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

Re: How to cleanly encode "quasi-constants"?

[Daniel de Rauglaudre]

On Tue, Jun 27, 2000 at 12:12:50PM -0700, Brian Rogoff wrote:

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

The only solution would be to adopt another syntax for quotations. For that
the only solution is to change the lexer (lib/plexer.ml) in Camlp4, or to
use another lexer, a copy of this lexer with another way to represent
quotations. But which one? which other syntax?

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/