[Caml-list] What about polymorphic methods?

[Caml-list] What about polymorphic methods?

[Alessandro Baretta]

I am writing a very simple class to handle bidirectional 
(bidi) lists in an object-functional manner. I have come up 
with a curious problem. The following text is the toplevel's 
output when it is passed my code.

#
type 'a bidi = Elem of 'a bidi * 'a * 'a bidi | Null
class ['a, 'b, 'c] bidi_list :
   'a list ->
   object
     method head : 'a bidi
     method left_iter : ('a -> 'b) -> 'b list
     method right_iter : ('a -> 'c) -> 'c list
     method tail : 'a bidi
     val first : 'a bidi
     val last : 'a bidi
   end
#   new bidi_list [1;2;3;4;5];;
- : (int, '_a, '_b) bidi_list = <obj>


The basic idea is that I want to convert a value with type 
'a list to a value belonging to class ['a] bidi_list. Now, 
if I leave 'b and 'c out of the parameter list my code 
refuses to compile, but even when I add 'b and 'c as type 
parameters, the type checker specializes them to '_b and 
'_c, which are not polymorphic.

Is there any way, then, to define polymorphic versions of 
the two iterators?

Alex Baretta

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[Jacques Garrigue]

From: Alessandro Baretta <alex@baretta.com>

>      method left_iter : ('a -> 'b) -> 'b list
>      method right_iter : ('a -> 'c) -> 'c list
> 
> Is there any way, then, to define polymorphic versions of 
> the two iterators?

Indeed, iterators are one of the major reasons to have polymorphic
methods in ocaml (the other one being implicit subtyping of
arguments). They are already in CVS, and will be present in ocaml
3.05.

With the CVS version, you would have to write

   method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
   method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...

Of course, 'b is no longer a parameter of the class.
Note that polymorphic methods can only be called on objects whose type
is (at least partially) known, so you may have to add a few extra type
annotations to your code.

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[John Prevost]

>>>>> "jg" == Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> writes:

    jg> With the CVS version, you would have to write

    jg>    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
    jg>    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...

    jg> Of course, 'b is no longer a parameter of the class.  Note
    jg> that polymorphic methods can only be called on objects whose
    jg> type is (at least partially) known, so you may have to add a
    jg> few extra type annotations to your code.

They're coming back?  Woohoo!

What will the restrictions on typing be, precisely?

John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[John Max Skaller]

Alessandro Baretta wrote:

> Great! That's what I need! Two questions now: how soon will this be 
> officially released? 

I can't answer that but ..

> And, is the CVS version stable enough for production quality code?

.. it's not fair on the ocaml team to expect them to answer that.
So I'll answer for them: the team has a genuine desire to build
a product of finest quality. Heh, and they're good at it!

You must decide if the even higher standard of the release
is needed for your project. FYI I'm using the CVS release
now. In my opinion, it is a better program than the one
in the 3.04 distribution. I haven't had any trouble with it


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Possible use for camlp4

[John Max Skaller]

Hmm.. can camlp4 generate C?
If so.. how about some language for generating
Ocaml/C binding code? Surely that would make
handling things easier than the existing macro solution?

Generating such bindings automatically (eg by SWIG)
is hard. Making it easier to hand write them should
be much easier.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[Alexander V. Voinov]

Hi John et al.

John Max Skaller wrote:
> 
> Hmm.. can camlp4 generate C?
> If so.. how about some language for generating
> Ocaml/C binding code? Surely that would make
> handling things easier than the existing macro solution?

When I worked with Arity/Prolog many years ago I extremely enjoyed its
_inline C_ feature, which allowed exactly what you would think of it,
and it was very useful. It had also a "traditional" (swiggable we would
say nowadays) interface to C.

Is it possible to implement such an inline C via camlp4?

Alexander
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[Alessandro Baretta]

Jacques Garrigue wrote:

> Indeed, iterators are one of the major reasons to have polymorphic
> methods in ocaml (the other one being implicit subtyping of
> arguments). They are already in CVS, and will be present in ocaml
> 3.05.
> 
> With the CVS version, you would have to write
> 
>    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
>    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...

Great! That's what I need! Two questions now: how soon will 
this be officially released? And, is the CVS version stable 
enough for production quality code?

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[Daniel de Rauglaudre]

Hi,

On Tue, May 28, 2002 at 04:27:27AM +1000, John Max Skaller wrote:

> Hmm.. can camlp4 generate C?

Any program can generate C. For example, this one in OCaml:

   print_string "main () { printf(\"hello, world\\n\"); }\n";
   flush stdout;;

What do you mean by "generate C"? Can you specify, give examples?

Or perhaps you mean "parse C" to include it in an OCaml program? In
this case, no: I did not write any parser with C syntax, because C is
a language of statements and OCaml a language of expressions. The C
syntax is not a good one for the semantics of Camlp4.

Or do you mean if there exist a parser for C program, generating a
syntax tree? I just know that there is a definition of a C syntax tree
somewhere and even somebody having programmed Camlp4 quotations for
this syntax tree (allowing to use the concrete syntax to represent
abstract syntax): I am sorry, I don't remember who, but he recognizes
himself if he reads this mailing list...

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[Daniel de Rauglaudre]

Hi again,

On Tue, May 28, 2002 at 04:27:27AM +1000, John Max Skaller wrote:

> If so.. how about some language for generating
> Ocaml/C binding code? Surely that would make
> handling things easier than the existing macro solution?

Camlp4 cannot do that, because it only treats programs having the
semantics of OCaml to be treated later by the OCaml compiler. The
interface OCaml/C does not have the semantics of OCaml: it is just C
program.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[John Max Skaller]

Daniel de Rauglaudre wrote:

>>Hmm.. can camlp4 generate C?
>>
>What do you mean by "generate C"? Can you specify, give examples?
>

Input:


CBINDING fred:int -> int = fred($1) ENDBINDING

output #1:

extern int fred_binding(int x) { return fred(x); } /* generated C 
function */

output #2:

external fred:int ->int = "fred_binding"; (* ocaml stub *)

The idea is a file of hand written bindings which generate the C code
necessary to wrap a C library. There are two outputs: the C glue code
and the ocaml binding definitions.

The point is to use camlp4 to make it easier to write the C glue code,
by inventing some language syntax which knows about the garbage
collector, heap format, the macros needed to do all that, etc.

That is, the glue code isn't generated *automatically* from a C interface,
like with SWIG. Instead, you have to write the glue code by hand,
as you do now. The difference is that you write it in  a slightly
higher level language than the ugly and error prone C/Ocaml macros
system. In addition, the 'simplified' way of using those macros is sometimes
very inefficient. [eg, making parameters and local variables gc roots
when there is no need]

Just as an example: the keyword 'interruptible' might mean
to use enter/leave blocking section macros.

That is: my suggestion is to design a language CamlCGlue,
which generates C code to bind ocaml to C libraries,
and implement it using camlp4.

BTW: this thought was prompted by the debate as to whether
camlp4 belongs in the standard distribution or not, and unrelated
discussion about building bindings to C libraries.

If there is one thing that Ocaml is perceived as needing more
than anything else for industrial use, it's bindings to more C libraries.
At present, writing them is very very expensive, and maintaining
them is an even worse problem if the target C library is evolving
eg GTK. So .. why not use ocamlp4 to help reduce the problem?


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[Alessandro Baretta]

John Max Skaller wrote:
 > Alessandro Baretta wrote:
 >> And, is the CVS version stable enough for production 
quality code?
 >
 > .. it's not fair on the ocaml team to expect them to 
answer that.
 > So I'll answer for them: the team has a genuine desire to 
build
 > a product of finest quality. Heh, and they're good at it!

I meant no harm. But, you know, sometimes the pre-release
builds of open source projects are known from the very start
to be buggy or unstable, and it is advised to restrict use
only to testing. You know, like Windows 98 for example: use
is advised only for sake of testing the
"blue-screen-of-death-at-startup" feature ;->

 > You must decide if the even higher standard of the release
 > is needed for your project. FYI I'm using the CVS release
 > now. In my opinion, it is a better program than the one
 > in the 3.04 distribution. I haven't had any trouble with it

This is as much as I wanted to hear: no known, obvious,
major flaw. Not like Windows 98, so to speak...

OK, now let me read some documentation on CVS so I can
figure out how to download the source :-)

Alex


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[Jacques Garrigue]

From: John Max Skaller <skaller@ozemail.com.au>

> The idea is a file of hand written bindings which generate the C code
> necessary to wrap a C library. There are two outputs: the C glue code
> and the ocaml binding definitions.
> 
> The point is to use camlp4 to make it easier to write the C glue code,
> by inventing some language syntax which knows about the garbage
> collector, heap format, the macros needed to do all that, etc.
> 
> That is, the glue code isn't generated *automatically* from a C interface,
> like with SWIG. Instead, you have to write the glue code by hand,
> as you do now. The difference is that you write it in  a slightly
> higher level language than the ugly and error prone C/Ocaml macros
> system. In addition, the 'simplified' way of using those macros is sometimes
> very inefficient. [eg, making parameters and local variables gc roots
> when there is no need]

Why not.

> If there is one thing that Ocaml is perceived as needing more
> than anything else for industrial use, it's bindings to more C libraries.
> At present, writing them is very very expensive, and maintaining
> them is an even worse problem if the target C library is evolving
> eg GTK. So .. why not use ocamlp4 to help reduce the problem?

This can help, but a frequent misconception is that gluing is the main
problem with external libraries.
It is for beginners, but for experimented programmers, with a good set
of C macros and sane habits, that's the easy part.  Even cooperating
with the GC is not that hard (as long as you don't try to optimize too
much).

What is really difficult is fancy callback systems, and abstracting
the invariants from the C API (including allocation problems).
Both are hard problems, with very little automated support.
In both cases you must understand how the library works from informal
explanations (or quite often reading the source code) before starting
to code. If the library is very regular, or uses a specific language
like Tcl/Tk, you may end up with some way to speed-up the process, but
in general you need to go into details, and there are exceptions.

So, yes for making things easier, like ocamlidl does already for
instance, but there are no miracles: as long as the external world is
not strongly typed in a language we can understand, the process is
going to be painful.

      Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Possible use for camlp4

[Daniel de Rauglaudre]

Hi,

On Thu, May 30, 2002 at 05:25:19AM +1000, John Max Skaller wrote:

> Input:
> CBINDING fred:int -> int = fred($1) ENDBINDING
> output #1:
> extern int fred_binding(int x) { return fred(x); } /* generated C 
> function */
> output #2:
> external fred:int ->int = "fred_binding"; (* ocaml stub *)

I see... It would be an original use of Camlp4, but it could work.
In Camlp4 you can do what you want while parsing and while printing.
For example, as "printer", you could take the syntax tree, type it
and generate code! :-)

For this specific case, since you use notions which cannot be represented
in the syntax tree (which is not extensible), you would have to do our
output (in particular the #1) at the parsing phase, in your syntax
extension.

> That is: my suggestion is to design a language CamlCGlue,
> which generates C code to bind ocaml to C libraries,
> and implement it using camlp4.

I think it is feasible. If you want some help, in particular for
the implementation of your syntax extension in Camlp4, you can ask
me.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[Lauri Alanko]

On Sat, May 25, 2002 at 12:55:30PM +0900, Jacques Garrigue wrote:
> With the CVS version, you would have to write
> 
>    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
>    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
                         ^^^

Is this type parameter declaration really necessary? Since class type
parameters are explicitly declared already, can't method-specific type
parameters be recognized automatically?


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods?

[Jacques Garrigue]

From: Lauri Alanko <la@iki.fi>
> On Sat, May 25, 2002 at 12:55:30PM +0900, Jacques Garrigue wrote:
> > With the CVS version, you would have to write
> > 
> >    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
> >    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
>                          ^^^
> 
> Is this type parameter declaration really necessary? Since class type
> parameters are explicitly declared already, can't method-specific type
> parameters be recognized automatically?

When writing a class type, you can omit them:

class ['a] collection : object
  method left_iter : ('a -> 'b) -> 'b list
  method right_iter : ('a -> 'b) -> 'b list
end

This is ok because these method types are exact.
However, in an implementation type annotations denote only constraints.
That is, this 'b could actually be instanciated to something inside
the class, or related to another type parameter by a constraint. The
only way to say that it is going to be polymorphic at this level is to
write it explicitly. Try:

class c = object (self)
  method m1 : 'a -> 'a = fun x -> x
  method m2 = self#m1 1
end

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods

[Alessandro Baretta]

Jacques Garrigue wrote:
> 
> Indeed, iterators are one of the major reasons to have polymorphic
> methods in ocaml (the other one being implicit subtyping of
> arguments). They are already in CVS, and will be present in ocaml
> 3.05.
> 
> With the CVS version, you would have to write
> 
>    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
>    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...


Hello Jacques and Caml riders,

I am very excited about the possibilities offered by the 
polymorphic methods of Ocaml 3.04+13, which I have recently 
downloaded and built from the CVS site. Please, allow me one 
more question on this matter.

I do not understand why I have to declare 'b explicitly as a 
"polymorphic" type variable for the two iterators. If I omit 
the explicit generalization of 'b in my bidirectional list 
class, the compiler yields the following error message:
 > Some type variables are unbound in this type:
 >   class ['a] bidi_list :
 >    'a list ->
 >     object
 >       val first : 'a bidi
 >       val last : 'a bidi
 >       method head : 'a bidi
 >       method left_iter : ('a -> 'b) -> 'b list
 >       method right_iter : ('a -> 'c) -> 'c list
 >       method tail : 'a bidi
 >     end
 > The method left_iter has type ('a -> 'b) -> 'b list where
 > 'b is unbound

An analogous error message would be given for right_iter, 
with reference to 'c, if the explicit generalization were 
used for left_iter.

To me, this means that the type checker is able to correctly 
determine the type of the class and of the polymorphic 
methods. It simply refuses to generalize unbound type 
variables without "written consent" from the programmer.

I think that coding a method whose type contains an unbound 
type variable, implicitly means that the programmer desires 
that type variable to be generalized. Since the compiler is 
able to determine what type variables "ought" to be 
generalized, why does it not perform and "implicit" 
generalization, rather than requiring an "explicit" 
generalization in the code?

I hope I am making some sense to somebody. Do excuse me if I 
have used improper terminology, but I am not a professional 
of functional languages and type theory.

Regards,
Alex Baretta

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] What about polymorphic methods

[Jacques Garrigue]

From: Alessandro Baretta <alex@baretta.com>
> > With the CVS version, you would have to write
> > 
> >    method left_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
> >    method right_iter : 'b. ('a -> 'b) -> 'b list = fun f -> ...
>
> I do not understand why I have to declare 'b explicitly as a 
> "polymorphic" type variable for the two iterators. If I omit 
> the explicit generalization of 'b in my bidirectional list 
> class, the compiler yields the following error message:
>  > Some type variables are unbound in this type:
>  >   class ['a] bidi_list :
>  >    'a list ->
>  >     object
>  >       val first : 'a bidi
>  >       val last : 'a bidi
>  >       method head : 'a bidi
>  >       method left_iter : ('a -> 'b) -> 'b list
>  >       method right_iter : ('a -> 'c) -> 'c list
>  >       method tail : 'a bidi
>  >     end
>  > The method left_iter has type ('a -> 'b) -> 'b list where
>  > 'b is unbound
> 
> To me, this means that the type checker is able to correctly 
> determine the type of the class and of the polymorphic 
> methods. It simply refuses to generalize unbound type 
> variables without "written consent" from the programmer.

There are two problems. One is theoretical: while implicit
polymorphisation would work in many cases, it would not work in all
cases. For instance, it does not work with polymorphic recursion:
you would be only able to call inherited methods recursively.
And it's not always clear whether the extra polymorphism was really
intended: as polymorphic methods are not compatible with
non-polymorphic ones, choosing between the two is clearly not
principal. Requiring an annotation is on the safe side.

On the practical side, class typing relies heavily on unification.
This is neat: you can view inheritance as unifying with #c, from a
typing point of view.  This means that once you've assumed a
non-polymorphic type (as you usually do to type recursion), you cannot
go back to the polymorphic one (does not unify).  This problem is only
technical, and it also means you cannot refine method types in
subclasses, so I'm no sure it will stay forever.

Also, I have a feeling that classes in caml are an advanced feature.
They can help you modelling easy to use libraries, or building big
programs.  In both cases, the extra verbosity is only on the producer
side, while the consumer can profit from the extra comfort at very
little cost. For instance with my scheme you don't need annotations in
subclasses.

So I hope these annotations will not mean lots of trouble.
Yet, this is a new feature, and experience will tell us.
In particular if beginners start writing visitor patterns all around,
this may not work that well.

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners