Help needed on SML compiler

nick@lfcs.edinburgh.ac.uk (Nick Rothwell)
Thu, 28 Mar 91 12:06:06 GMT

          From comp.compilers

Related articles
Help needed on SML compiler surendar@enuxha.eas.asu.edu (1991-03-25)
Help needed on SML compiler nick@lfcs.edinburgh.ac.uk (1991-03-28)
| List of all articles for this month |

Newsgroups: comp.compilers
From: nick@lfcs.edinburgh.ac.uk (Nick Rothwell)
Keywords: ML, functional
Organization: Compilers Central
References: <9103260248.AA22854@enuxha.eas.asu.edu>
Date: Thu, 28 Mar 91 12:06:06 GMT

> Now, I am very familiar with UNIX and 'C' and I couldn't think of
>any way to generate code for this SML construct .


Familiarity with UNIX and C is probably a drawback in this regard. You're
thinking of how C compilers work, which doesn't help.


>If I were to create a
>global variable 'a' and assign it to 'b' and when I try to redefine 'a' to
>a function, how do I do that? How can I generate code for langauges were
>both function definition and usage is mixed up?


Sorry, I don't understand this paragraph at all.


SML isn't difficult to compile. It's statically scoped, which means you
have to create static function closures at runtime (which avoids your
problems about "redefining" things). SML's formal semantic definition
document (published by MIT press) describes how the environments are
handled (including redefinition of identifiers).


>* Generate a shadow function file which will have code for the functions
and
> generate code for assignments in one file and let the link editor
resolve
> references.


Er, ah, um, you mean you want to compile ML functions into C object files
with the entry point names the same as the ML functions? No problem with
the environment management as far as I can see - you just export the
environment of functions which results from elaborating (typechecking, in
effect) the declarations. But, since ML's data objects are totally
different from C's (it has first class functions, assumes garbage
collection, and so on), there's no trivial way of doing this. Equating the
ML and C name spaces is likely to lead to confusion.


>I'd suggest that the variables really be structures
>with type tags and pointers that are dereferenced at run time.


Presumably you're thinking of accessing the ML data objects from C here. In
which case, yes, this is the way to do it (and in SML/NJ, the runtime
system and garbage collector is written in C anyway...).


                Nick.
--
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.