headers
John Max Skaller | 1 May 2002 01:24
Picon
Picon

Re: Modules and typing

Francois Pottier wrote

>
>This is correct. This problem arises not only with abstract types, but more
>generally, in any programming language that has polymorphism. The most common
>solutions to the data representation issue are
>
> + adopt a uniform representation (e.g. everything-is-a-pointer), as in O'Caml
>
> + require that abstract types are pointer types, as in Modula-3 (?) and, more
>   recently, Cyclone
>
> + pass type information around at runtime, as in the TIL/ML compiler
>
> + adopt two representations, a uniform (boxed) one and a specialized (unboxed)
>   ones, and insert coercions in your code to switch between the two, as in one
>   of Xavier Leroy's papers
>
> + adopt specialized representations only, duplicating polymorphic functions
>   if they have to be used at several types whose representations differ
>
>As far as I can tell, you are interested in exploring the last option.
>
Yes. More precisely, in finding a hybrid system which permits
superior performance without losing too much generality.
I support pointers, so it should be possible
for a single specialisation of a polymorphic function
to be use where all the type variable are under a pointer.

I currently expand products, but sum types use tagged pointers.
(Continue reading)

Permalink | Reply | 2 comments |
headers
T. Kurt Bond | 1 May 2002 01:30

Danvy "Functional Unparsing" style output in OCaml [was: How to read three integers from a text-file... ?]

Francois Pottier writes:
> Check out Olivier Danvy's paper `Functional Unparsing':
> 
>   http://www.brics.dk/RS/98/12/
> 
> It describes a very nice way of programming `printf' within ML's type
> system. `scanf' could be handled in a similar way. Furthermore, this approach
> yields code that is claimed to be more efficient than O'Caml's current
> `printf' implementation (because the overhead of interpreting format strings
> is lower). Lastly, it scales up to more expressive format directives, such as
> a directive for printing a list.
> 
> It might be worth adding a module that implements Danvy-style `printf' and
> `scanf' to the standard library. Has anyone written such a module already?
> Otherwise, I might consider doing it.

Back during an earlier discussion of Danvy-style output (probably on
this) I implemented a simple module for this (possibly starting from
some code that flew by on the list).

This round of discussion prompted me to go back and finish it up and
knock of a few of the rough edges and package it up.  Here's the README:

Cpsio is an Objective Caml implementation of the
continuation-passing-style output from Olivier Danvy's paper
Functional Unparsing.  It is available from:

   http://tkb.mpl.com/~tkb/software.html

The distribution is a gzipped tar file. It includes two modules:
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Max Skaller | 1 May 2002 01:57
Picon
Picon

Re: Modules and typing

Gregory Morrisett wrote:

>
>There's another option that you didn't mention which is the approach
>taken by Ada:  Have a notion of "private" types in interfaces, e.g.
>
>  type t
>  [private t = int]
>
>The client is type-checked with t treated abstractly, but the 
>compiler can then specialize the client knowing what the implementation
>of t is.  Of course, by leaking this information into the interface,
>you're effectively losing separate compilation in the sense that
>if the implementation of t changes, then its interface must also
>change and all clients must then be (potentially) re-compiled.  
>
Ocaml object system does this. Very confusing it is too,
seeing the private data in the interface .. but it is a good system,
because it is possible to abstract that data away by a further
abstraction. A large class of clients can work solely with the
abstraction .. not all because of the covariance problem ..
and those that can don't need recompilation when the representation
changes.

The biggest pain in this model is that one has to cut and paste
a lot during development... and also the lack of inter-recursion
between classes and type means you have to encode the abstraction
as a parameterised class type and then instantiate it within
the type recursion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Noel Welsh | 1 May 2002 10:08
Picon
Favicon

Re: Modules and typing


--- John Max Skaller <skaller <at> ozemail.com.au> wrote:
> Francois Pottier wrote
> 
> > + adopt specialized representations only,
> duplicating polymorphic functions
> >   if they have to be used at several types whose
> representations differ
> >
> >As far as I can tell, you are interested in
> exploring the last option.
> >
> Yes.

I believe MLTon does this, at the cost of no separate
compilation.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 1 comment |
headers
Yozo TODA | 1 May 2002 10:24
Picon

Re: OCaml IDEs for beginners?

> Are there any programming environments out there for OCaml that are
> especially well suited to beginning programmers?

how about ocamlbrowser?

-- yozo.
-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 3 comments |
headers
Stefano Zacchiroli | 1 May 2002 10:46
Picon

local modules in classes

Hi OCamlers,
  I'm wondering why I can't use a local definition of a module in a
class:

   # class foo = let module P = Printf in object method foo = a end;;
   Syntax error

Is there a soundness problem with the OCaml type system or is this
simply an unimplemented feature?

TIA,
Cheers.

--

-- 
Stefano Zacchiroli - undergraduate student of CS  <at>  Univ. Bologna, Italy
zack <at> cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 0 comments |
headers
Gerard Huet | 1 May 2002 12:26
Picon
Picon
Favicon

Re: OCaml IDEs for beginners?


>About this subject, I would like to make a public Request for Features, in
>order to gather many opinions and tips about that IDE . ( which will be at
>the same time for beginners AND for experienced people ).
>
>Nicolas Cannasse

Bonjour.
Ma première requête est que l'IDE soit basé sur la syntaxe abstraite d'Ocaml,
et que les outils liés à la syntaxe concrète (macros emacs et autres) soient
paramétrés par la grammaire camlp4, de manière à pouvoir se décliner aussi
bien pour la syntaxe révisée que pour la syntaxe ordinaire. Ceci n'est pas
une feature, c'est une décision importante d'architecture. Ainsi les débutants
pourront apprendre la bonne syntaxe, alors que les habitués pourront continuer
à éditer leurs programmes dans la syntaxe dont ils ont l'habitude
Gérard Huet

Hello
My first request is that the IDE ought to be based on Ocaml's abstract syntax,
and that the tools dealing with the concrete syntax (such as emacs macros) be
parameterized by the camlp4 grammar, so as to be adaptable to the revised
syntax as well as to the standard syntax. This is not a mere feature, it is
an important architectural design decision. This way beginners may learn the
revised syntax, while experienced users may keep the syntax they are familiar 
with.
Gérard Huet

-------------------
To unsubscribe, mail caml-list-request <at> inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin C. Pierce | 1 May 2002 13:43

Re: OCaml IDEs for beginners?

> > Are there any programming environments out there for OCaml that are
> > especially well suited to beginning programmers?
> 
> how about ocamlbrowser?

I'd wondered about this too.  Does anybody have actual experience with
using OCamlBrowser as an IDE for teaching?  (From playing around with it
for a few minutes, my sense is that it is "not quite there yet" for this
purpose, but perhaps it would not be that hard to get it there...)

     B

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 2 comments |
headers
Andreas Rossberg | 1 May 2002 15:19
Picon

Re: Re: Encoding "abstract" signatures

François,

Francois Pottier <francois.pottier <at> inria.fr> wrote:
>
> > How do you express
> >
> >     functor F (X : sig module type T end) (Y : X.T) = (Y : X.T)
> >
> > without parameterizing over the set of existentially quantified
variables
> > somehow? I had in mind something like (again assuming non-applicative
> > functors, because they are much simpler):
> >
> >     LAMBDA k. Lambda S:(k->*). Lambda ts:k. lambda Y:S(ts).
> >         pack Y as exists ts:k.S(ts)
>
> You make the functor F polymorphic in the number of type components
> defined by the signature S. As far as I understand, this is made
> necessary by the desire to hide these types in the functor's result
> (i.e. the pack operation).

This is just one reason. More generally, it's the need for a coherent
encoding in the higher-order setting we face. If we say that type

    functor(X : sig type t val x : t end) -> ...

maps to something like

    forall t. t -> ...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jérôme Marant | 1 May 2002 18:06
Picon
Favicon

Re: printf and scanf

Francois-Rene Rideau <fare <at> tunes.org> writes:

> Runtime processing of format string is more problematic,
> but who needs that, anyway? Instead of concatenating format strings,

  There are some cases where you may know the format string
  only at runtime; the most obvious example is internationalization
  through something like gettext.

  Cheers,

--

-- 
Jérôme Marant

http://marant.org

-------------------
To unsubscribe, mail caml-list-request <at> 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
Permalink | Reply | 0 comments |

Gmane