status of some big "important" features?

status of some big "important" features?

[Chris Hecker]

Hi, what's the status of adding these important (to me :) features:

1.  Overloading?  Now that I'm writing some real ocaml code, not only is the + vs. +. thing ugly and killing me in mixed int/float code (((float i)/.8.*.4.*.pi-.2.*.pi <- yuck!, I'm half way to writing an emacs syntax table that hides the damn . after the arithmetic ops :)), it would really make life easier to have things like fst be definable for ('a,'b) and ('a,'b,'c), etc., or have functions with different numbers of arguments (the label default args only go so far and aren't really dynamic enough).  I know this is hard with type inference, but is it possible?

2.  Module recursion or Tom Hirschowitz's mixin modules?  Forward declarations?  Anything?

3.  Pierre Weis's generics stuff ($a, etc.) from a post in April?  Hopefully as compile-time optimizable as possible where possible to match C++ templates for speed when you don't do something like put generics in a data structure.

Any status updates, dates, addresses to send money to speed things up? :)

Thanks,
Chris

PS.  Minor question I thought of the other day...is there any way to write "nth" for tuples (as opposed to "fst", which is hard-coded to 2-tuples)?  This is related to the overloading and generic questions above, but it also touches on some introspection issues, since nth would need to know the "length" of the tuple to either recurse or loop.  I guess I could use camlp4 for this if I really wanted to...couldn't I?

Re: status of some big "important" features?

[Daniel de Rauglaudre]

Hi,

On Tue, Dec 26, 2000 at 03:47:08PM -0800, Chris Hecker wrote:

> PS.  Minor question I thought of the other day...is there any way to
> write "nth" for tuples (as opposed to "fst", which is hard-coded to
> 2-tuples)?  This is related to the overloading and generic questions
> above, but it also touches on some introspection issues, since nth
> would need to know the "length" of the tuple to either recurse or
> loop.  I guess I could use camlp4 for this if I really wanted
> to...couldn't I?

Impossible in Camlp4, it is a typing problem.

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

A proposal for overloading ...

[Christophe Raffalli]

What follows is a proposal to add overloading to ocaml with the
following properties:

- compatibility of existing code
- simple to implement and understand (it is my opinion)
- not limited to arythmetic operation

The implementation is in two steps:

When parsing an identifier search the list of all value in the
environment having the same name. So at parsing time, the value of an
identifier is a list of Ocaml term. 

At type checking, when type-checking the type of an identifier two cases
occur:
1) there is only one possible value in the list whose type unify with
the required type: in this case we known the real value of the
identifier. (note: in ML type checking implementation, each value in the
environment as a type assigned so we just need to try to unify the
required type with all possible type)
2) there are more than one value whose type unify with the required
type:
in this case we delay the typing-checking of that identifier

* At the end we have a set of identifier whose type checking have been
delayed. It is possible that some identifiers know have only one
possible value (because we got extra typing information). We enter a
loop  until all identifiers have an ambiguous value or all identifier
have been type checked.

Then, if there is still some identifiers with ambiguous value, we choose
one (the first by position in the source code ?), and assign it the
first possible value in the list (this choice insure compatibility with
existing code). This may add extra typing information, so we go back to
step *. It would be good to issue a warning in this case because it may
help detect bugs in the following situation:

let i = ... in
...
let i = ... in
...
i 
...

where both i have the same type and the reference to i reffers to the
first one in the mind of the programmer that did not see the second one.

What do the implementors and users of Ocaml think of this ?
Is it compatible with the complex feature in Ocaml typing  (like
functor, object, type-checking of let rec ..) ?
 
-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI

Re: status of some big "important" features?

[Chris Hecker]

>> PS.  Minor question I thought of the other day...is there any way to
>> write "nth" for tuples (as opposed to "fst", which is hard-coded to
>> 2-tuples)?
>Impossible in Camlp4, it is a typing problem.

Oh, I thought camlp4 had the types available to it.  I must have misunderstood the docs.

Hmm.  So similarly, you couldn't write an introspection thing like this in camlp4:

type foo = {bar:float; baz:int };;
let a = {bar = 1.;baz = 1};;
print_members_camlp4 a;;

Where print_members_camlp4 is hooked by camlp4 to iterate over the members of whatever record was passed to it (or error at compile time if it's not a record)?  That's not possible?

Chris

Re: status of some big "important" features?

[Daniel de Rauglaudre]

Hi,

On Sat, Dec 30, 2000 at 11:30:57AM -0800, Chris Hecker wrote:

> type foo = {bar:float; baz:int };;
> let a = {bar = 1.;baz = 1};;
> print_members_camlp4 a;;
> 
> Where print_members_camlp4 is hooked by camlp4 to iterate over the
> members of whatever record was passed to it (or error at compile
> time if it's not a record)?  That's not possible?

Camlp4 does not know what a type definition is: for it, it is just a
syntax thing. Therefore, in the line "print_member_camlp4 a", Camlp4
does not know what "a" is: for it, it is just "the identifier a",
that's all. The fact that it is a variable previously defined of type
"foo" is typing. If you want to treat that at Camlp4 time, you have to
write a types inference algorithm. A compiler...

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

Re: status of some big "important" features?

[Chris Hecker]

>Camlp4 does not know what a type definition is: for it, it is just a
>syntax thing. Therefore, in the line "print_member_camlp4 a", Camlp4
>does not know what "a" is: for it, it is just "the identifier a",
>that's all. The fact that it is a variable previously defined of type
>"foo" is typing. If you want to treat that at Camlp4 time, you have to
>write a types inference algorithm. A compiler...

Ah, I see.  How hard would it be to hook camlp4 (or another "plugin" type thing, but it would be good if it was the same structure as camlp4) into other stages of the compiler, like after type inference?

Chris

Re: status of some big "important" features?

[Daniel de Rauglaudre]

Hi,

On Sat, Dec 30, 2000 at 05:58:45PM -0800, Chris Hecker wrote:

> Ah, I see.  How hard would it be to hook camlp4 (or another "plugin"
> type thing, but it would be good if it was the same structure as
> camlp4) into other stages of the compiler, like after type
> inference?

Camlp4 allows to make syntax extensions. We could imagine something to
make typing extensions and code generating extensions. But I don't
know how to do that, and even if it is possible in a simple way.

Do other caml-list readers have an opinion about that?

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

Re: status of some big "important" features?

[John Max Skaller]

Daniel de Rauglaudre wrote:
> 
> Hi,
> 
> On Tue, Dec 26, 2000 at 03:47:08PM -0800, Chris Hecker wrote:
> 
> > PS.  Minor question I thought of the other day...is there any way to
> > write "nth" for tuples 

> Impossible in Camlp4, it is a typing problem.

	Requires overloading. Use something like:

	let proj_3_5 (_,_,x,_,_) = x

which is easy enough to define when you need it,
or just write

	(match tup with (_,_,x,_,_) -> x)


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

Re: A proposal for overloading ...

[Didier Remy]

Christophe,

I am afraid that the picture might be far more complicated that what your
description suggests. Of course, two identifiers might have ambiguous
types when considered alone, but become unambiguous when combined together
in a program (this is at the basis of overloading, when the context should
be used to desambiguate). For instance,

        foo: int -> int or string -> string
        bar: string or bool

Then, (for, bar) is ambiguous but (foo bar) is not.  

However, to solve the latter case seems to imply something more complicated
than your simple schema. 

The above example is just a basic example of overloading.  There are many
variations involving ambiguous (maybe polymorphic) local bindings that are
used non-ambiguously for which it is not clearly whether their should be
ambiguity should be resolved or propagated.

In summary you cannot save the effort of a careful formal specification of
what is an overloaded symbol, how overloading is propagated, and how it is
resolved.

> Then, if there is still some identifiers with ambiguous value, we choose
> one (the first by position in the source code ?), and assign it the
> first possible value in the list (this choice insure compatibility with
> existing code). 

Both notions (first position in the code, first possible value in the list)
seems completely meaningless to me. 

Cheers,

    Didier

Re: status of some big "important" features?

[William Chesters]

Daniel de Rauglaudre writes:
 > Camlp4 allows to make syntax extensions. We could imagine something to
 > make typing extensions and code generating extensions. But I don't
 > know how to do that, and even if it is possible in a simple way.
 > 
 > Do other caml-list readers have an opinion about that?

The actual source code for the compiler as it is now is pretty decent, 
remarkably so given its maturity, and it's hard to imagine any useful
"semantic extension" mechanism being much simpler than just hacking the
relevant bits of camlc.

My 2p,
W

Re: A proposal for overloading ...

[Christophe Raffalli]

Didier Remy a écrit :
> 
> Christophe,
> 
> I am afraid that the picture might be far more complicated that what your
> description suggests. Of course, two identifiers might have ambiguous
> types when considered alone, but become unambiguous when combined together
> in a program (this is at the basis of overloading, when the context should
> be used to desambiguate). For instance,
> 
>         foo: int -> int or string -> string
>         bar: string or bool
> 
> Then, (for, bar) is ambiguous but (foo bar) is not.
>
> However, to solve the latter case seems to imply something more complicated
> than your simple schema.

My proposal would not solve this problem automatically but at least it
will give overloading of arithmetical operator (if you still keep
separate constants) and a few others. It is clear that if you want
something more general,
you need an algotihm that implements some kind of bactracking or that
infer all the possible types and altough it is possible, it seems much
more complex ...

> 
> The above example is just a basic example of overloading.  There are many
> variations involving ambiguous (maybe polymorphic) local bindings that are
> used non-ambiguously for which it is not clearly whether their should be
> ambiguity should be resolved or propagated.
> 
> In summary you cannot save the effort of a careful formal specification of
> what is an overloaded symbol, how overloading is propagated, and how it is
> resolved.
> 
> > Then, if there is still some identifiers with ambiguous value, we choose
> > one (the first by position in the source code ?), and assign it the
> > first possible value in the list (this choice insure compatibility with
> > existing code).
> 
> Both notions (first position in the code, first possible value in the list)
> seems completely meaningless to me.

But this is that actual semantics of most functionnal language !

> Cheers,
> 
>     Didier

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI