SML->OCaml

SML->OCaml

[Konstantine Arkoudas]

I'm thinking about re-implementing a fairly large SML-NJ project
(> 20K lines) in OCaml. Is anybody aware of any tools capable 
of automatically translating SML code into OCaml, at least 
partially? Any info would be appreciated. Thanks.

-- K. A. 

Re: [Caml-list] SML->OCaml

[Martin Jambon]

On Sun, 6 Mar 2005, Konstantine Arkoudas wrote:

> I'm thinking about re-implementing a fairly large SML-NJ project
> (> 20K lines) in OCaml. Is anybody aware of any tools capable
> of automatically translating SML code into OCaml, at least
> partially? Any info would be appreciated. Thanks.

It exists but it is in the "unmaintained" section of camlp4:
  http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/camlp4/unmaintained/sml/


Martin

--
Martin Jambon, PhD
Researcher in Structural Bioinformatics since the 20th Century
The Burnham Institute http://www.burnham.org
San Diego, California

RE: [Caml-list] SML->OCaml

[Harrison, John R]

Does this version do anything about SML programs that violate OCaml's
"uppercase identifier" convention? I recently tried something similar,
and while it did a competent job of parsing most of the syntax of SML,
it just reported errors for SML value bindings starting with an
uppercase letter. It would be nice if it just mapped such names to
"lowercase_XXX" or something so that the result could at least be
compiled. Or is that too "context sensitive" to be easy?

John.

-----Original Message-----
From: caml-list-admin@yquem.inria.fr
[mailto:caml-list-admin@yquem.inria.fr] On Behalf Of Martin Jambon
Sent: Sunday, March 06, 2005 2:16 PM
To: Konstantine Arkoudas
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] SML->OCaml

On Sun, 6 Mar 2005, Konstantine Arkoudas wrote:

> I'm thinking about re-implementing a fairly large SML-NJ project
> (> 20K lines) in OCaml. Is anybody aware of any tools capable
> of automatically translating SML code into OCaml, at least
> partially? Any info would be appreciated. Thanks.

It exists but it is in the "unmaintained" section of camlp4:
  http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/camlp4/unmaintained/sml/


Martin

--
Martin Jambon, PhD
Researcher in Structural Bioinformatics since the 20th Century
The Burnham Institute http://www.burnham.org
San Diego, California


_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] SML->OCaml

[Martin Jambon]

On Sun, 6 Mar 2005, Harrison, John R wrote:

> Does this version do anything about SML programs that violate OCaml's
> "uppercase identifier" convention? I recently tried something similar,
> and while it did a competent job of parsing most of the syntax of SML,
> it just reported errors for SML value bindings starting with an
> uppercase letter. It would be nice if it just mapped such names to
> "lowercase_XXX" or something so that the result could at least be
> compiled. Or is that too "context sensitive" to be easy?

[I don't know SML and I am not an expert in Camlp4. And I haven't tried
the SML-to-OCaml converter]

The converter needs a way to tell whether a given identifier is a type
constructor (such as None or Some) or not. Thus the converter needs to
remember the accessible type definitions (either from the standard
library of SML or from other modules). That is possible, by creating some
auxilliary files that contain this information (maybe .cmi files could be
parsed but anyway the type definitions have to be analysed during the
preprocessing of a file). It doesn't seem to be implemented
in pa_sml.ml but a few hundred lines of additional code could do it (or
maybe less).

There would also be a problem with record fields if several record types
use identical names for their fields (using objects is probably not a
good idea for simple records).

Maybe you could also (1) compile you SML files and (2) use the information
contained in the SML equivalent of .cmi files in combination with Camlp4.


Martin

--
Martin Jambon, PhD
Researcher in Structural Bioinformatics since the 20th Century
The Burnham Institute http://www.burnham.org
San Diego, California

Re: [Caml-list] SML->OCaml

[Andreas Rossberg]

Martin Jambon <martin_jambon@emailuser.net> wrote:
>
> > Does this version do anything about SML programs that violate OCaml's
> > "uppercase identifier" convention? I recently tried something similar,
> > and while it did a competent job of parsing most of the syntax of SML,
> > it just reported errors for SML value bindings starting with an
> > uppercase letter. It would be nice if it just mapped such names to
> > "lowercase_XXX" or something so that the result could at least be
> > compiled. Or is that too "context sensitive" to be easy?
>
> [I don't know SML and I am not an expert in Camlp4. And I haven't tried
> the SML-to-OCaml converter]
>
> The converter needs a way to tell whether a given identifier is a type
> constructor (such as None or Some) or not. Thus the converter needs to
> remember the accessible type definitions (either from the standard
> library of SML or from other modules). That is possible, by creating some
> auxilliary files that contain this information (maybe .cmi files could be
> parsed but anyway the type definitions have to be analysed during the
> preprocessing of a file). It doesn't seem to be implemented
> in pa_sml.ml but a few hundred lines of additional code could do it (or
> maybe less).

In fact, it would be much more complicated. First, identifier status is
scoped. Constructors are frequently defined locally. In particular, this may
happen implicitly through the use of "open". To derive the required
information you hence needed to perform a complete binding analysis,
including modules and signatures.

Then, SML actually allows constructor status to be withdrawn from an
identifier. For example, the following program is valid:

  signature S = sig type t val x : t end
  structure A : S = struct datatype t = x end

There are few programs that make use of this possibility, but I expect them
to coincide with those that violate the usual case conventions in the first
place. An SML-to-OCaml translator had to go to quite some length to
translate such programs.

In summary, to deal with constructor status correctly (not to mention stuff
like datatype replication, local, records, user-defined fixity, etc.) you
basically need half an SML frontend. It seems out of scope for a Camlp4 hack
to be more than a simple approximation.

Cheers,

  - Andreas

RE: [Caml-list] SML->OCaml

[Harrison, John R]

Andreas Rossberg writes:

| In fact, it would be much more complicated. First, identifier
| status is scoped. Constructors are frequently defined locally. In
| particular, this may happen implicitly through the use of "open".
| To derive the required information you hence needed to perform a
| complete binding analysis, including modules and signatures.
| [...]

Thanks, that's a good explanation. Ocaml's case convention almost
starts to look like a good idea when you see the alternatives...

| In summary, to deal with constructor status correctly (not to mention
| stuff like datatype replication, local, records, user-defined fixity,
| etc.) you basically need half an SML frontend. It seems out of scope
| for a Camlp4 hack to be more than a simple approximation.

Can you recommend any SML frontend that I could, more or less
trivially, use to systematically munge uppercase identifier names and
spit out the program again?

John.

Re: [Caml-list] SML->OCaml

[Andreas Rossberg]

Harrison, John R <johnh@ichips.intel.com> wrote:
>
> Ocaml's case convention almost
> starts to look like a good idea when you see the alternatives...

Indeed, it is a very good idea.

> Can you recommend any SML frontend that I could, more or less
> trivially, use to systematically munge uppercase identifier names and
> spit out the program again?

Nothing I'd dare to call trivial. If you don't mind the plug, I wrote a
model interpreter for SML (http://www.ps.uni-sb.de/hamlet) that has been
tuned for readability and modularity and ripping off binding analysis should
be easier than with any other compiler. It still won't be one hour's task to
make such a tool from it, particularly if you want to maintain the layout of
the original program. But I don't know anything simpler either.

  - Andreas

Re: [Caml-list] SML->OCaml

[Norman Scaife]

Hi,

    >> Can you recommend any SML frontend that I could, more or less trivially,
    >> use to systematically munge uppercase identifier names and spit out the
    >> program again?

    Andreas> Nothing I'd dare to call trivial. If you don't mind the plug, I
    Andreas> wrote a model interpreter for SML (http://www.ps.uni-sb.de/hamlet)
    Andreas> that has been tuned for readability and modularity and ripping off
    Andreas> binding analysis should be easier than with any other compiler. It
    Andreas> still won't be one hour's task to make such a tool from it,
    Andreas> particularly if you want to maintain the layout of the original
    Andreas> program. But I don't know anything simpler either.

I'm not sure if this is of any help but about 9 (sic) years ago I
wrote a translator for SML to OCaml based on the MK Kit (Version
2). It was intended to provide smaller binaries for SML programs on
(then limited-memory) parallel machines. It is not source-to-source,
in fact it generates Core SML in OCaml form with some minor cosmetic
transformations on the output (eg. ((op ::) (1,((op ::) (2,nil)))) ==>
[1,2]). I've sort of thought about converting it into Hamlet (which I
believe was originally based on the ML Kit) but that's too
daunting. However, If anybody wants to tackle the problem I could send
the AST traversal code (about 2000 lines SML for decs, 700 lines for
topdecs). This is old code, however, and is not too clever with some
aspects of the translation, for instance records are not properly
converted. Alternatively, I can generate a binary for just the
translator (it's part of a transformational compiler) but this adds a
whole load of extra "junk" to the output, for instance it bootstraps
the SML prelude on the OCaml side. It also needs a whole load of
support files such as the type signatures of SML Basis functions.

Regards,
Norman Scaife.