headers
Jacques Garrigue | 1 Nov 2000 01:44
Picon
Picon

Re: ocaml to c variant hashes

From: Chris Hecker <checker <at> d6.com>

> Hi, I'm looking at the lablGL stuff, and came across a utility that
> computes the ocaml hash value for a given variant name.  The
> var2def.ml file in the package preprocesses a variables file and
> outputs a C header with the appropriate hash values.  The ml file
> contains a function, hash_variant	that does this hash, but that
> function is copied from the source code to the compiler.  This
> doesn't seem like a very robust way to do this, since the internal
> hash function could change at any time (in fact, the comment in the
> code says hash_variant is from ctype.ml, but it's now in btype.ml).
> 
> What's the right way to do this?  I can think of 3 ways:
> 
> 1.  Like var2def.ml, and just hope the internal hash function doesn't change.

This is the right way. You can consider this as "the definition" of
how to hash a variant. Basically it only assumes that all ocaml
architectures support 31-bit integers efficiently. As I do not see any
risk of this becoming false, and as 32-bit architectures are still
around for a while, there is no compelling reason to change it.

Only if 32-bit architectures disappear, and ocaml support 63-bit
integers everywhere, there could be a discussion of changing this
hashing function, but I suppose this would be publicized enough.

As to whether you should use var2def.ml, or use the C hash_variant
function, this is basically a question of efficiency: I prefer
preprocessing because runtime cost is null, and you can put the values
in static tables. You can also use switch, but beware of code size
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Houben | 1 Nov 2000 08:38
Picon
Picon

Re: Why does the order in the Makefile matter?

On Sat, 28 Oct 2000, Pierre Weis wrote:

> Hence, when the entire program is made of multiple implementation
> files, those files must be linked in any order that is compatible with
> the static binding rule: no definition can be linked if it refers to
> an identifier that is defined after the definition at hand.  In
> addition, expressions to be computed must evidently appear in any
> order compatible with the desired runtime behaviour.

I completely understand this point, and I agree that there are legal 
Caml programs that have a different behavior depending on the order
of the .cmo file linking. However, every program I write (and I suppose
that's true for most of us) has an invariant behavior under all legal
permutations of the .cmo files. Mostly because I only have 1 .ml file
that actually does anything; the rest only contain side-effect-free
definitions.

So it would be nice if the compiler itself could put the .cmo files in an order
compatible with the static binding rule. This would remove the tedium of
putting the .cmo files in an appropriate order from the programmer.

Would this be difficult to implement?
Perhaps this could be made a compiler switch?

Stephan
--

-- 
ir. Stephan H.M.J. Houben
tel. +31-40-2474358 / +31-40-2743497
e-mail: stephanh <at> win.tue.nl
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Pitts | 1 Nov 2000 12:51
Picon
Picon
Favicon

Research Associateship in Metaprogramming Languages


    POSTDOCTORAL RESEARCH ASSOCIATE IN METAPROGRAMMMING LANGUAGES
				at the
	     UNIVERSITY OF CAMBRIDGE COMPUTER LABORATORY
			    Cambridge, UK

We are seeking a postdoctoral Research Associate to work on
implementing an exciting new approach to representing, computing and
reasoning about syntactical structures that involve variable-binding.

START DATE: 1 January 2001, or as soon as possible thereafter.

SALARY: 16,775--25,213 GBP per year, depending on age and
qualifications.

DURATION: 3 years.

THE PROJECT: 

People who create software systems that manipulate syntactical
structures (interpreters, compilers, proof checkers, proof assistants,
etc) agree that dealing with variable-binding constructs, renaming of
bound variables, capture-free substitution, etc, is very often a
nightmare. Despite the efforts of many smart people, no clear winner
has emerged from the different approaches to this problem that have
been proposed so far---name-carrying terms, de Bruijn nameless terms,
higher order abstract syntax.

We have a new approach to this long-standing problem based on some
simple mathematics to do with permuting variables. We think it is very
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Houben | 1 Nov 2000 16:15
Picon
Picon

question on integrating the toplevel in an O'Caml app

Hello list,

At our department, we have currently an application that allows
"Graphical programming", i.e. the user can connect modules (which
act like functions) on the screen with a mouse. It is somewhat similar
to systems like AVS.

Currently, the application is written in C++ and extremely unstable.
It is also not very simple to write new modules, because of all the issues
of memory management, since the user can create, delete, connect
and disconnect modules in an arbitrary order.

I thought that it would be much nicer to have such a system in O'Caml.
Essentially, every graph the user can draw can directly tarnslated
into an O'Caml expression. So I would like to be able to do the
following tasks:

1. Read in a .cmo/.cmi file and find out what functions (and what types)
   are defined in it.
2. Assemble an expression using the functions in .1
3. Type-checking and evaluating the function.

These all seem things the interpreter does now. In the crudest set-up,
I would simply send string to the interpreter. However, a better
approach might be to actually send the AST to the interpreter.

I also need to get the type information. A crude approach would be again
to ask the interpreter to evaluate something like module M = Blah, 
and look at the result. again, I suppose a better approach would be
to get the data structure inside the compiler back.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ohad Rodeh | 2 Nov 2000 15:53
Picon
Picon
Favicon

Assert

I have a problem with the assert solution. It does not
indicate the line number in the source code. For example, running the
program:

let _ = 
  try 
    raise Not_found
  with _ -> assert false

Results in: 
  Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
  496)

	Ohad. 

On Tue, 31 Oct 2000, Mattias Waldau wrote:

> Nice idea with 'with Not_found -> assert false'.
> 
> 1. But why can't the assert-information be available for all raise? wouldn't
> that be the same?
> 
> 2. If the we cannot include this in 'raise', how can I automate it, so that
> I get the assert-behaviourif I keep the asserts, and the normal behaviour
> otherwise. I normally don't deliver code with assert enabled.
> 
> /mattias
> 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pierre Weis | 2 Nov 2000 16:42
Picon
Picon
Favicon

Re: Redefinition doesn't work

> >>>>> "Pierre" == Pierre Weis <Pierre.Weis <at> inria.fr> writes:
> > It is not only a question of type. As I mentioned in my previous
> > message, if you allow the user to ``rebind'' some basic functions,
> > such as map or iter, the behaviour of the compiler can be
> > unpredictable.
> 
> It never seems to bother Lisp users.
> 
> 
>         Stefan

Absolutely right. In the same vein we have: the absence of static
type-checking ``never seems to bother Lisp users'', the absence of GC
``never seems to bother C users'', the absence of dynamically
allocated arrays ``never seems to bother Pascal users'', the absence
of pattern matching ``never seems to bother Pascal users''...

So what ? Users of these languages have very often to fight against
the absence of these features. In Caml, we chose to provide them to
the user in a simple and rigorous way.

Conversely, we try to avoid the addition of features that can confuse
the users in some situations (and in my mind the rebinding of
identifiers belongs to this category). To be precise, I implemented
this feature long time ago in Caml: it was named the #relet directive
of the toplevel. It had the type-checking constraints I mentioned. So
it was safe. But it was confusing, since people quickly started to
imagine that it meant : everything that mentioned the old function
should now behave as if the old function were the new one. So they
asked this relet feature to be applied recursively everywhere in their
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pierre Weis | 2 Nov 2000 18:29
Picon
Picon
Favicon

Re: Where did the exception occur?

> Maybe a little example in the Ref. Manual or the FAQ would be useful, as
> I'm not the first one to be caught by this problem?
[...]

Let me propose this little tutorial for the debugger...

Launching the debugger:
-----------------------

Given the following obviously wrong program written in file
uncaught.ml, (the program raises an uncaught exception Not_found, when
evaluating the expression find_address "INRIA", since "IRIA" (and not
"INRIA") has been added to the list of adresses):

(* file uncaught.ml *)

let l = ref [];;

let find_address name = List.assoc name !l;;

let add_address name adress = l := (name, address) :: ! l;;

add_address "IRIA" "Rocquencourt";;

print_string (find_address "INRIA"); print_newline ();;

If you want to find where and why this exception has been raised, you
have to:

1) compile the program in debug mode:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trevor Jim | 2 Nov 2000 19:05
Picon

Re: Redefinition doesn't work

If anyone is interested in static, incremental type inference (which
allows type safe redefinitions without #use), I worked out how to do
this for core ML in a paper in POPL '96.  As someone noted earlier, of
course this does not address the semantic issues (of changing
List.map, for example).

-Trevor
Permalink | Reply | 0 comments |
headers
Pierre Weis | 2 Nov 2000 19:22
Picon
Picon
Favicon

Re: Why does the order in the Makefile matter?

> On Sat, 28 Oct 2000, Pierre Weis wrote:
> 
> > Hence, when the entire program is made of multiple implementation
> > files, those files must be linked in any order that is compatible with
> > the static binding rule: no definition can be linked if it refers to
> > an identifier that is defined after the definition at hand.  In
> > addition, expressions to be computed must evidently appear in any
> > order compatible with the desired runtime behaviour.
> 
> I completely understand this point, and I agree that there are legal 
> Caml programs that have a different behavior depending on the order
> of the .cmo file linking. However, every program I write (and I suppose
> that's true for most of us) has an invariant behavior under all legal
> permutations of the .cmo files. Mostly because I only have 1 .ml file
> that actually does anything; the rest only contain side-effect-free
> definitions.

Hmm, no initializations ? For instance table allocations and
computations of default values are often considered side-effect free,
even if the initializations can perform some assignments.

Anyway what about identifiers redefinition ? Then the linking order
will influence the semantics (due to the binding of identifiers in
closures). Also, if there are more than one compatible linking order,
the compiler should prove that all those linking orders will lead to
the same semantics ?

> So it would be nice if the compiler itself could put the .cmo files
> in an order compatible with the static binding rule. This would
> remove the tedium of putting the .cmo files in an appropriate order
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicolas barnier | 2 Nov 2000 19:45
Picon
Favicon

Re: Assert

Ohad Rodeh wrote:
> 
> I have a problem with the assert solution. It does not
> indicate the line number in the source code. For example, running the
> program:
>
>   Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
>   496)

>From the users manual :

exception Assert_failure of (string * int * int)

     Exception raised when an assertion fails. The arguments are the
location of 
the pattern-matching in the source code (file name, position of first
character,
						    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
position of last character).
^^^^^^^^^^^^^^^^^^^^^^^^^^

-- Nicolas
Permalink | Reply | 1 comment |

Gmane