sml-implementers — Standard ML implementers

[Sml-implementers] sharing vs. definitional specs

[Matthias B. <bl...@re...>]

I am still not convinced about the need for an asymetric "where type".
Consider the following scenario (which, in fact, has happened to us
in similar form, and it was a very annoying experience).

Suppose we have the following signatures A, B, C, and D:

   signature A = sig type a end

   signature B = sig type b end

   signature C = sig
      structure A : A
      structure B : B where type b = A.a * A.a
   end

   signature D = sig type d
                     val f : d -> unit
                 end

Now, suppose further that we want to construct a signature E (perhaps
the formal argument of a functor) consisting of two substructures that
match C and D, respectively:

   signature E = sig
      structure C : C
      structure D : D
   end

Further, we want to be able to apply D.f to values of type C.B.b, so
we must specify that D.d and C.B.b are the same type.  All I want to
convey to the compiler is that D.d = C.B.b, but I can't do this --
neither using "sharing" nor using "where type" because C.B.b
is not flexible anymore!  So I have to say something like:

   signature E = sig
      structure C : C
      structure D : D where type d = C.A.a * C.A.a
   end

In other words, the language forces me to trace back what C.B.b was
defined to be -- even though this information is completely
irrelevant to what I am trying to express.  Moreover, it is
intuitively clear that the compiler could infer the above automatically
from the equation D.d = C.B.b.

I see not conceptual difficulty with making "where type" (or any
type abbreviation in signatures) symmetric.  The meaning should be this:
An attempt is made to "unify" the two types in question, with currently
"flexible" type names playing the roles of type variables.

  - "unifying" two flexible type names generates a traditional sharing
    constraint for them, i.e., it throws the two names into an equivalence class
  - "unifying" a rigid type name, i.e., one that already has a definitonal
    spec, applies recursively to the RHS of its spec
  - "unifying" a flexible type name with a type constructor application
    generates a definitional spec for the name (and its equivalence class)
  - "unifying" two type constructor applications with equal head constructor
    causes the respective arguments to be "unified" recursively
  - "unifying" two type constructor applications with unequal head constructor
    causes elaboration to fail with an error message

Why can't we have this?  It seems simple and intuitive and expressive.

Matthias

Re: [Sml-implementers] compilation management

[Andreas R. <ros...@ps...>]

Andrew Kennedy wrote:
>
> Different compilers have different means of indicating where the
> entry point to a standalone executable is, and this is a source of
> incompatibility when trying to compile SML'97 sources under different
> compilers. I can think of at least three:
>
> (a) Use-style, where "main" is essentially defined by side-effecting
> top-level definitions (e.g. val _ = run_my_program()).
>
> (b) C-style naming convention for the main function (e.g. fun main() =
> ...).
>
> (c) Compilation environment directive e.g. SML/NJ's exportFn command.

Choice (a) is preferable IMHO, since it is simplest to use when you
don't care about command arguments or returning error codes. The Std
Basis already allows you to access/return those when you need to, in a
more convenient way.

	- Andreas

-- 
Andreas Rossberg, ros...@ps...

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.

Re: [Sml-implementers] compilation management

[Matthias B. <bl...@re...>]

Andrew Kennedy wrote:
> 
> A point related to compilation management is that of "entry points".
> Different compilers have different means of indicating where the
> entry point to a standalone executable is, and this is a source of
> incompatibility when trying to compile SML'97 sources under different
> compilers. I can think of at least three:
> 
> (a) Use-style, where "main" is essentially defined by side-effecting
> top-level definitions (e.g. val _ = run_my_program()).
> 
> (b) C-style naming convention for the main function (e.g. fun main() =
> ...).
> 
> (c) Compilation environment directive e.g. SML/NJ's exportFn command.
> 
> It would be nice to agree on something here to save us all writing
> wrapper code every time.

For those who are not aware of this, here is what SML/NJ implements these
days.  Maybe we can take this as a blueprint of what we want to do...

We have a shell command "ml-build" which takes three arguments:

   ml-build <library> <functionname> <executable>

The <library> is a .cm-file, and <functionname> is the name of a function
exported from <library>.  Its type must be

       string * string list -> OS.Process.status

i.e., the type of "main". Finally, <executable> is the name of the stand-alone
program to be constructed.  In our case it currently names a heap image, but
in the future it will probably name a genuine executable.

The command ml-build will invoke the SML/NJ compiler (including CM), build the
library in question if it was not already up-to-date, and then produce an
executable with main entry point <functionname>. Internally, we use exportFn
to establish the entry point, but this is hidden from the programmer and might
even change in the near future.

Maybe we can agree on something similar to the above, i.e., something that does
not make specific claims about implementation details...

Matthias

Re: [Sml-implementers] extensions to SML

[Matthias B. <bl...@re...>]

Ken Friis Larsen wrote, replying to Bob Harper:
> 
> It is also clear (to me at least) that many of the participants in
> this discussion don't feel that they have as big a vote as you in
> these matters.  There might be different reasons for this felling: you
> are one of the authors of the Definition; or that we don't have
> time/skills/energy to participate in a revision of the Definition.

Please, no name-calling!   If Bob is willing to listen to SML implementers
and users when they ask for revisions, then this is a Good Thing precisely
because he can then cast his Big Vote with those concerns in mind.  It
is the nature of the beast that some voices end up being heard more widely
than others.  Asking Bob, and perhaps Robin or Mads or Dave to sit back
and watch is not realistic, IMO.

> > Second, many of the proposed revisions are entirely do-able within a
> > reasonable time frame.
> 
> That revisions are do-able does not necessitate revisions.

While this is true, the revisions are necessary anyway.  Nearly every major
implementation of SML has already departed in more or less significant ways
from the text of the definition.  If the definition does not accommodate change,
then it will simply become obsolete.  ML (the family) will then have many mutually
incompatible members which go by names such as SML/NJ, Ocaml, MoscowML, MLKit,
Poly/ML, MLj, MLWorks, and so on because no-one will care anymore about 
standard compliance.  I know that there are definite plans to go ahead and implement
some of the proposed things in SML/NJ. I can easily imagine that similar
sentiment exists in other "camps". Now is the chance to coordinate such
changes across all implementations (except one :-), effectively keeping the concept
of a _language_ that exists independently from any one particular implementation.
If the definition does not follow suit, then in not so long a future nobody
will care about it anymore.

> One of the main strengths of SML is that the language don't change all
> the time.
> 
> Our disagreement might boil down to what we mean by "a viable
> language"?  If you mean a viable *research* language then I might
> agree with you.

Actually, no.   There is no need for a "definition" in the first place if all
you care about is a research language.

> > 2. Standardization of a substantial set of libraries.
> 
> But we don't want to repeat the fiasco of the Standard Basis Library
> (for those involved, apologies for being so blunt).

What exactly is the "fiasco"?  (I like the SBL a lot, and I am not one of 
its designers.)

> I think that the process of designing libraries should be much more
> open, like for example SFRI:
>         http://srfi.schemers.org/
> This way the *users* of SML get a say as well.

Users can always write their own libraries and publish them.  If they are good,
then I am sure that the SML community as a whole will take notice and adopt them.
(I am very sceptical about the SFRI process in Scheme, btw.)

> To quote the Definition again, to which you are an author, you say
> (p. xiii):
> 
>    ... This is the first revised version, and we foresee no others.
> 
> This sentence gives me the felling that the other authors don't agree
> with you, when you say that "there is a crying need" for revision.

This was written in 1997 when there was still a strong expectation that SML
would be succeeded by ML2000.  We all know what happened to the latter, so
things have changed.

Matthias

RE: [Sml-implementers] compilation management

[Andrew K. <ak...@mi...>]

A point related to compilation management is that of "entry points".
Different compilers have different means of indicating where the
entry point to a standalone executable is, and this is a source of
incompatibility when trying to compile SML'97 sources under different
compilers. I can think of at least three:

(a) Use-style, where "main" is essentially defined by side-effecting
top-level definitions (e.g. val _ =3D run_my_program()).

(b) C-style naming convention for the main function (e.g. fun main() =3D
...).

(c) Compilation environment directive e.g. SML/NJ's exportFn command.

It would be nice to agree on something here to save us all writing
wrapper code every time.

- Andrew.=20

Re: [Sml-implementers] compilation management

[Matthias B. <bl...@re...>]

Dave Berry wrote:
> 
> At 17:29 20/09/2001, Daniel C. Wang wrote:
> >The case insensitivity is not just a problem with MacOS X. ...
> 
> I won't argue this point any more, since it's clear that sufficient people
> are sufficiently opposed to a fixed mapping.  I will just note that library
> authors would do well to bear case-insensitivity in mind while choosing
> names for their files.

Yes, this is a good recommendation.

> We could even go so far as to require that no files
> in a given library should be case-insensitive-equal.  Yes, it would be a
> mild restriction on some OS's, but it would help to improve portability.

This I wouldn't do -- not as a requirement that we burn into a language
spec.  The main reason for my saying this is that we should not have to care
about such OS- and filesys-specifics at all.  Otherwise there will be no end
to it:
   - no case-insensitive-equal names
   - no suffixes longer than k chars (k = 3 ?)
   - no filename longer than n chars
   - no filename arc longer than m chars
   - no dots in filenames (other than to indicate the suffix)
   - no whitespace in filenames
   - only ASCII in filenames
   - no special chars in filenames ("/", "\", "*", "?", ...)
   - no ...

It is a slippery slope, and we should not even begin to tread there.

It is _definitely_ a good idea for library authors to keep all of the above in mind.
But at the same time, it should be easy to fix problems that may occur on particular
systems without having to touch ML source code, i.e., by just renaming files and
updating the meta information (= .cm-files in CM jargon).

Matthias

Re: [Sml-implementers] extensions to SML

[Ken F. L. <kf...@it...>]

Hi Bob, 

Robert Harper <Rob...@cs...> writes:
> What is clear to me is that it is more than time to renew emphasis on
> revision and extension of Standard ML, for several reasons.  First, there is
> a crying need, as is clearly evidenced by this discussion.

Yesterday evening I took some time to carefully read all the messages
in this avalanche of emails.  And I've come to a different conclusion
than you.  Several people have raised the opinion that they would prefer
that *no* revisions was made to the Definition, and if revisions *had*
to be made they should be kept minimal.

It is also clear (to me at least) that many of the participants in
this discussion don't feel that they have as big a vote as you in
these matters.  There might be different reasons for this felling: you
are one of the authors of the Definition; or that we don't have
time/skills/energy to participate in a revision of the Definition.

> Second, many of the proposed revisions are entirely do-able within a
> reasonable time frame.

That revisions are do-able does not necessitate revisions.

> Third, it is essential for Standard ML to remain a viable language.

I don't think that the Definition need to changed for SML to remain a
viable.

One of the main strengths of SML is that the language don't change all
the time.  

Our disagreement might boil down to what we mean by "a viable
language"?  If you mean a viable *research* language then I might
agree with you.


> I propose, therefore, that we focus our efforts on (1), leaving aside
> discussion of more ambitious projects (which I, among many, wish to
> undertake) for another day.

Reading this sentence again I realize that we might be in perfect
agreement, but I'll rather speak up than having doubts.


> Reviewing the discussion, I can see a few major topics for immediate
> consideration.
[snip]

> 2. Standardization of a substantial set of libraries.

But we don't want to repeat the fiasco of the Standard Basis Library
(for those involved, apologies for being so blunt).

I think that the process of designing libraries should be much more
open, like for example SFRI:
        http://srfi.schemers.org/
This way the *users* of SML get a say as well.

 
> 4. Extensions and modifications to the language itself.  These include
> relatively trivial things like denigrating obsolete mechanisms (such as
> abstype), re-considering the semantics of structure sharing (which started
> this discussion), and adding support for new features (eg, updateable
> records, lazy evaluation, vector expressions, richer patterns, hierarchical
> extensible sums).  I think there are strong arguments for all of these
> changes.  We might also consider ways to improve the syntax while providing
> a path for porting old code.


Before we start to make changes to the language (minor or major) I
think we should first try to define *what* we want to achieve.  To
quote from the (revised) Definition (p. xii):

   ... But we have only made such amendments when one or more aspects
   of SML---the language itself, its usage, its implementation, its
   formal Definition---have thus become simpler, without complicating
   the other aspects.

Other goals for our discussion are of course also valid:

   * There should be *no* changes to the definition, only to the
     "environment" of the language (compilation management, libraries,
     ...)

   * Make SML more popular in education/industry/research

   * Make SML better for text processing

   * Make SML better for number crunching

   * Make SML the best language for web-programming

   * Attract Open Source developers

   * Make SML the language of choice for system programming

   * Simplify the syntax

   * Include Ken's favorite extension (first-class modules or withtype
     in signatures, I don't know which one is my favorite ;-)
 
   * Recast/rewrite the official Definition in a different
     mathematical framework.

And the list could go on.  Some of these goals can be met at the same
time, some goals are clearly to "specific", and some goals are in
conflict with each other.  All the more reason for discussion *what*
our goals should be.

To quote the Definition again, to which you are an author, you say
(p. xiii):
        
   ... This is the first revised version, and we foresee no others.

This sentence gives me the felling that the other authors don't agree
with you, when you say that "there is a crying need" for revision.


> Perhaps it is worthwhile to state a few principles that I hope can
> guide us.

> 1. Standard ML exists independently of its implementations.
[snip] 
> 2. Revisions must be guided as much by the experience of users and
>    implementors as by the demands of a clean formal definition.
[snip]
> 3. It is important to achieve a rough consensus, but complete
> agreement on all issues may be impossible to achieve.  We will need
> to have a mechanism for reaching a decision in the face of
> disagreement.


I agree with you on these principles but I don't agree with you that
there *have* to be any changes to the Definition (except for withtype
in signatures of course ;-)

So I think we should perhaps discuss what we when/if we disagree.


Cheers,

--Ken Friis Larsen

Re: [Sml-implementers] compilation management

[Peter S. <se...@di...>]

On Thu, 20 Sep 2001, Dave Berry wrote:

> At 17:29 20/09/2001, Daniel C. Wang wrote:
> >The case insensitivity is not just a problem with MacOS X. ...
> 
> I won't argue this point any more, since it's clear that sufficient people
> are sufficiently opposed to a fixed mapping.  I will just note that library
> authors would do well to bear case-insensitivity in mind while choosing
> names for their files.  We could even go so far as to require that no files
> in a given library should be case-insensitive-equal.  

I agree.  

Peter

Re: [Sml-implementers] nailing down structure sharing

[Derek D. <dr...@cs...>]

Dave Berry wrote:
> I don't want to comment on the exact rule that Martin proposed, but
> wouldn't it be preferable to use a Definition-style rule to define
> structure sharing if at all possible?

Either a Definition-style rule or an extension to the Harper-Stone
interpretation of SML would be great.  But I think the first step is to
determine what the right semantics is, then to figure out how to
formalize it.  The ease of backpatching the Definition with the new
definition of structure sharing is not a criterion for me.  It may be
hard to give a Definition-style rule anyway because the Definition
treats structure sharing as a derived form.  (And Harper-Stone doesn't
even mention it.)

Derek

Re: [Sml-implementers] compilation management

[Dave B. <da...@ta...>]

At 17:29 20/09/2001, Daniel C. Wang wrote:
>The case insensitivity is not just a problem with MacOS X. ...

I won't argue this point any more, since it's clear that sufficient people
are sufficiently opposed to a fixed mapping.  I will just note that library
authors would do well to bear case-insensitivity in mind while choosing
names for their files.  We could even go so far as to require that no files
in a given library should be case-insensitive-equal.  Yes, it would be a
mild restriction on some OS's, but it would help to improve portability.

Dave.

Re: [Sml-implementers] nailing down structure sharing

[Dave B. <da...@ta...>]

At 17:12 20/09/2001, Derek Dreyer wrote:
>4) Martin Elsman proposed a Definition-style rule for structure sharing
>that he said was based on the TILT proposal.  ...

I don't want to comment on the exact rule that Martin proposed, but
wouldn't it be preferable to use a Definition-style rule to define
structure sharing if at all possible?

Dave.

 

Re: [Sml-implementers] compilation management

[Dave B. <da...@ta...>]

Here's another question, which you may find more relevant.

What limitations do each existing system place on the contents of source
files?  E.g. CM used to have some limits in order to simplify dependency
analysis -- I think it banned the use of "open" at top level.   I can
imagine that other systems might require no redefinition at top-level, or
no core-level constructs.  If everyone can tell us what limitations their
system requires (if any), then we can allow for them in the new design.

Dave.

Re: [Sml-implementers] compilation management

[Daniel C. W. <dc...@ag...>]

At 04:55 PM 9/20/2001 -0400, John H. Reppy wrote:
>In message <4.1...@po...>, Dave Berry writes:
>>
>> At 08:54 20/09/2001, John H. Reppy wrote:
>> >I often want to [...] have multiple
>> >implementations of the same module in a directory (see conditional compilation
>> >below).  
>> 
>> That's an interesting point.
>> 
>> >Also, the language allows arbitrary-length structure names, whereas
>> >some operating systems impose tight restrictions on file-name lengths.
>> 
>> Do such OS's still exist?  The main one was MS/DOS, of course, but I don't
>> think many people still use that.  I don't know anything about PalmOS,
>> Epoch, etc; do they have tight limits?
>
>Even though MS/DOS is mostly gone, FAT file systems still exist.  Also,
>I think that the standard for CD Roms restricts file-name length and case
>(but I may be wrong).  Another problem is that HFS+ file systems in
>MacOS X are case insensitive, which introduces more limits on programs.
>
>Using a fixed mapping between module names and filenames is a limitation
>that we do not need

The case insensitivity is not just a problem with MacOS X. Under all versions
of Windows (95/98/NT/2k) although the file system remembers the case of files names. 
It treats file names of differing case to be identical. So Foo.txt and foo.txt 
are the same file. Try creating the same file with different cases on a 
windows machine.

I have had problems with this particular issue when generating code for Java 
which maps class name to file names at least in Sun's JDK. It is pain to have 
operating systems with broken semantics intrude on my programming environment.

Doing a little digging confirms John's claims that IS09660 CD roms
are limited to 8 . 3 file names and must be all upper case. i.e. DOS semantics.
 

RE: [Sml-implementers] nailing down structure sharing

[Robert H. <Rob...@cs...>]

Regarding (5), I *do not* propose dropping sharing specifications in either
form.  I *do* propose adding "where A=B" between structures, to mean a
series of "where type" clauses.  I personally find it convenient to have the
symmetric form in symmetric situations, but often use the asymmetric forms
in asymmetric situations.

Bob

-----Original Message-----
From: Derek Dreyer [mailto:dr...@cs...]
Sent: Thursday, September 20, 2001 5:13 PM
To: SML Implementers
Subject: [Sml-implementers] nailing down structure sharing


Back to the question which inadvertently brought on this email frenzy:
What is the right design for structure sharing?  We (at TILT) would
really like to nail this down, and we don't feel it should be too hard
to come to a consensus.

To recap the discussion:

1) David Matthews made a point about structure sharing being overly
restrictive because you can effectively only write a sharing constraint
between two structures with fully opaque signatures.  SML/NJ employs a
strategy whereby two structures can be shared if they have the same
signature *variable* but this is semantically rather dubious.  An
example of where this comes up is in the Twelf compiler, which compiles
under SML/NJ but is not Definition-compliant because it makes use of
sharing between structures with translucent signatures.

2) Stephen Weeks replied that he doesn't find completely avoiding type
definitions in signatures very restrictive.  I find this surprising,
since translucent signatures are one of the major advances of SML '97.

3) We posted the TILT proposal for loosening the definition of structure
sharing.  In short, what we propose is that structure sharing should
first add sharing constraints between all flexible (i.e. opaque) type
components contained in the signatures of both structures.  Then, the
remaining type components contained in both signatures should be checked
to ensure that they are equivalent.  At the very least, our proposal
(unlike the Definition) allows structure sharing between any structures
with the same signature.  See our proposal for more details at:

http://www.cs.cmu.edu/~dreyer/structure_sharing.txt

4) Martin Elsman proposed a Definition-style rule for structure sharing
that he said was based on the TILT proposal.  I'm still not sure what
its effect is, but it seems offhand quite different from ours.  In
particular, it appears to require all the structures being shared to
have all the same value components as well, unless I read it wrong.  I
see no reason to be so restrictive.  Structure sharing is supposed to be
a convenient way of summarizing a long list of type definitions, not a
hindrance.

5) There was also some discussion of "where structure" instead of
structure sharing.  The advantage of "fixing" structure sharing instead
of adding "where structure" is that it doesn't involve changing the
syntax of SML.  Personally, however, I (and I think also Bob Harper)
would prefer "where structure" if I had a choice.  The semantics of type
sharing is much harder to define and to explain than the semantics of
"where type", and likewise for structures.  Matthias Blume disagrees and
prefers symmetric equality constraints on types to asymmetric ones.

Thoughts?

Derek

_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers

[Sml-implementers] nailing down structure sharing

[Derek D. <dr...@cs...>]

Back to the question which inadvertently brought on this email frenzy:
What is the right design for structure sharing?  We (at TILT) would
really like to nail this down, and we don't feel it should be too hard
to come to a consensus.

To recap the discussion:

1) David Matthews made a point about structure sharing being overly
restrictive because you can effectively only write a sharing constraint
between two structures with fully opaque signatures.  SML/NJ employs a
strategy whereby two structures can be shared if they have the same
signature *variable* but this is semantically rather dubious.  An
example of where this comes up is in the Twelf compiler, which compiles
under SML/NJ but is not Definition-compliant because it makes use of
sharing between structures with translucent signatures.

2) Stephen Weeks replied that he doesn't find completely avoiding type
definitions in signatures very restrictive.  I find this surprising,
since translucent signatures are one of the major advances of SML '97.

3) We posted the TILT proposal for loosening the definition of structure
sharing.  In short, what we propose is that structure sharing should
first add sharing constraints between all flexible (i.e. opaque) type
components contained in the signatures of both structures.  Then, the
remaining type components contained in both signatures should be checked
to ensure that they are equivalent.  At the very least, our proposal
(unlike the Definition) allows structure sharing between any structures
with the same signature.  See our proposal for more details at:

http://www.cs.cmu.edu/~dreyer/structure_sharing.txt

4) Martin Elsman proposed a Definition-style rule for structure sharing
that he said was based on the TILT proposal.  I'm still not sure what
its effect is, but it seems offhand quite different from ours.  In
particular, it appears to require all the structures being shared to
have all the same value components as well, unless I read it wrong.  I
see no reason to be so restrictive.  Structure sharing is supposed to be
a convenient way of summarizing a long list of type definitions, not a
hindrance.

5) There was also some discussion of "where structure" instead of
structure sharing.  The advantage of "fixing" structure sharing instead
of adding "where structure" is that it doesn't involve changing the
syntax of SML.  Personally, however, I (and I think also Bob Harper)
would prefer "where structure" if I had a choice.  The semantics of type
sharing is much harder to define and to explain than the semantics of
"where type", and likewise for structures.  Matthias Blume disagrees and
prefers symmetric equality constraints on types to asymmetric ones.

Thoughts?

Derek

Re: [Sml-implementers] compilation management

[John H. R. <jh...@re...>]

In message <4.1...@po...>, Dave Berry writes:
>
> At 08:54 20/09/2001, John H. Reppy wrote:
> >I often want to [...] have multiple
> >implementations of the same module in a directory (see conditional compilation
> >below).  
> 
> That's an interesting point.
> 
> >Also, the language allows arbitrary-length structure names, whereas
> >some operating systems impose tight restrictions on file-name lengths.
> 
> Do such OS's still exist?  The main one was MS/DOS, of course, but I don't
> think many people still use that.  I don't know anything about PalmOS,
> Epoch, etc; do they have tight limits?

Even though MS/DOS is mostly gone, FAT file systems still exist.  Also,
I think that the standard for CD Roms restricts file-name length and case
(but I may be wrong).  Another problem is that HFS+ file systems in
MacOS X are case insensitive, which introduces more limits on programs.

Using a fixed mapping between module names and filenames is a limitation
that we do not need.

	- John

Re: [Sml-implementers] compilation management

[Dave B. <da...@ta...>]

At 08:54 20/09/2001, John H. Reppy wrote:
>I often want to [...] have multiple
>implementations of the same module in a directory (see conditional compilation
>below).  

That's an interesting point.

>Also, the language allows arbitrary-length structure names, whereas
>some operating systems impose tight restrictions on file-name lengths.

Do such OS's still exist?  The main one was MS/DOS, of course, but I don't
think many people still use that.  I don't know anything about PalmOS,
Epoch, etc; do they have tight limits?

Dave.

Re: [Sml-implementers] compilation management

[Matthias B. <bl...@re...>]

Dave Berry wrote:
> 
> (I see you've beaten me to some of the questions I ask in this message).
> 
> Some questions about compilation management.
> 
> 1.  How much do we want "backwards compatibility" with each existing
> implementation?  On the one hand, we want to minimise the work needed to
> adopt the new system.  On the other hand, everyone will have to make some
> changes, and there might be benefits from requiring more than just the
> minimum.

I think that the mechanism that we will hopefully agree on is going to be
low-level enough to accommodate everyone's needs.

> 2.  Shall the new system require a top level?  Preferably not, IMO.

That's a totally different question.  I prefer supporting an interactive
toplevel in form of an application library.

> 3.  Should we adopt a common suffix for file names?  E.g. ".sml" for
> structures and functors; ".sig" for signatures.  The advantage is
> uniformity in tools.  The disadvantage is more changes for some users.

I don't think that we should _require_ particular suffixes.
 
> 4.  Should we require one module per file and use the same name for the
> module and the file?   The advantage is that it's easy to find modules,
> easy to explain to new users, and a library file doesn't have to choose
> between listing modules and files.  The disadvantage is more changes for
> some users.

No, absolutely not.

> I'm strongly in favour of this. Apparently some people see this as a gross
> imposition. I don't even begin to comprehend why they feel this way, but I
> guess we have to accept their view.

Here are a few reasons:

-- I (and others) often write multiple "modules" in one file (e.g., signature and functor).
-- File systems are often limited in what names you can choose.  The limitations are not
   uniform from OS to OS (or even just filesystem to filesystem).
-- Not requiring a fixed mapping is more flexible during program development.
-- In a world without fixed mapping, a fixed mapping can always be adopted using
   convention when this is desired.  But the other way around this does not work.
-- The benefits from having a fixed mapping are, IMO, rather marginal.

> 5.  Should we make any file into a module?  I.e. if a file contains a set
> of top-level declarations,  this would be equivalent to defining a
> structure with the same name as the file.

Again, absolutely not!  (This is the same thing as above just with one or two fewer lines
in the source file.)

> OCaml gets a huge win from this simple mapping from files to modules; I'm
> sure this is one of the design decisions that makes it popular.

Hmm.  "Huge"?  How do you measure that?

> 6.  Should we support multiple configurations -- e.g. release mode and
> debug mode, where the two modes apply a certain functor to different arguments?

This can be taken care of by conditional compilation.

> 7.  Should we support conditional compilation?

Probably.  (CM does.)

> 8.  Should we standardise the semantics of "use", for those systems that
> provide a top level?  Peter Sestoft analysed the different implementations
> at the time of SML'97.

If we adopt the point of view that the interactive toplevel is an application library,
then this is clearly a problem of that library.  Thus, maybe we can defer this decision.

Matthias

Re: [Sml-implementers] extensions to SML: Foreign functioninterface

[Matthias B. <bl...@re...>]

Dave Berry wrote:
> 
> At 21:29 17/09/2001, David Matthews wrote:
> >Dave,
> >Have you looked at the foreign function interface that Nick Chapman did
> >for Poly/ML several year ago? (See
> >http://www.lfcs.ed.ac.uk/software/polyml/docs/CInterface.html ).  It's
> >been used for several projects but particularly the Windows interface
> >which has several hundred functions in it.  It works for dynamic
> >libraries in Unix or DLLs in Windows and doesn't require the SML
> >programmer to write anything but ML.
> 
> I haven't looked at it recently, although I think we looked at it when we
> were working on the MLWorks FLI.  I'm about to go on holiday, but I'll look
> at it when I get back.

I would, perhaps somewhat selfishly, like to point people to our new "NLFFI"
foreign function interface for C.  I will make documentation for it available
soon, for the time being here is a longer draft of the text of my BABEL'01 paper
that describes the ideas (for those who haven't seen it yet):

  http://cm.bell-labs.com/cm/cs/who/blume/nlffi.ps

The ideas should be readily translatable to most ML implementations (and even
to other languages with HM-type systems and ML-like abstraction facilities).

Matthias

RE: [Sml-implementers] compilation management

[Peter S. <se...@di...>]

> 8.  Should we standardise the semantics of "use", for those systems that
> provide a top level?  Peter Sestoft analysed the different implementations
> at the time of SML'97.

Maybe this is worth addressing, since the issue was originally raised
by a real user of SML (Larry Paulson, I think), who found the
differences annoying.

As far as I recall, in 1997 there was pretty good agreement between
implementations, after some changes had been made to MLWorks.  At a
later point SML/NJ drifted away slightly, but I'd have to look at the
details again.  

Peter
--
Department of Mathematics and Physics  *  http://www.dina.kvl.dk/~sestoft/
Royal Veterinary and Agricultural University          *  Tel +45 3528 2334
Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark  *  Fax +45 3528 2350 

Re: [Sml-implementers] compilation management

[John H. R. <jh...@re...>]

In message <4.1...@po...>, Dave Berry writes:
>
> (I see you've beaten me to some of the questions I ask in this message).
> 
> Some questions about compilation management.
> 
> 1.  How much do we want "backwards compatibility" with each existing
> implementation?  On the one hand, we want to minimise the work needed to
> adopt the new system.  On the other hand, everyone will have to make some
> changes, and there might be benefits from requiring more than just the
> minimum.  

The important thing is to make it easy for library/application authors
to target the interchange format.  The build mechanism needs to be
compatible with the SML implementations, but I don't think that we should
worry too much about compatibility with existing build mechanisms.

> 
> 2.  Shall the new system require a top level?  Preferably not, IMO.

I agree.

> 
> 3.  Should we adopt a common suffix for file names?  E.g. ".sml" for
> structures and functors; ".sig" for signatures.  The advantage is
> uniformity in tools.  The disadvantage is more changes for some users. 

No.  The design should not introduce unnecessary barriers to porting
existing libraries.

> 
> 4.  Should we require one module per file and use the same name for the
> module and the file?   The advantage is that it's easy to find modules,
> easy to explain to new users, and a library file doesn't have to choose
> between listing modules and files.  The disadvantage is more changes for
> some users.
> 
> I'm strongly in favour of this. Apparently some people see this as a gross
> imposition. I don't even begin to comprehend why they feel this way, but I
> guess we have to accept their view.

Because it adds an uneccesary restriction on my programming.  There are a
number of things that I do regularly, which are incompatible with
this requirement.  I often want to put a signature and implementation in
the same file, have multiple structure definitions in a file, or have multiple
implementations of the same module in a directory (see conditional compilation
below).  Also, the language allows arbitrary-length structure names, whereas
some operating systems impose tight restrictions on file-name lengths.

> 5.  Should we make any file into a module?  I.e. if a file contains a set
> of top-level declarations,  this would be equivalent to defining a
> structure with the same name as the file.  The advantages are that novices
> are using the module system as soon as they start using files, and the
> module system is both natural to use and easy to explain, and we don't have
> to worry about supporting "core-only" programs.  The disadvantage is that
> users have to add the structure header when adding an explicit signature
> constraint, or when writing a functor.  
> 
> OCaml gets a huge win from this simple mapping from files to modules; I'm
> sure this is one of the design decisions that makes it popular.  OCaml
> doesn't yet support functors or generic signatures as cleanly, but we can
> do better.

I don't see a strong need for this change.

> 
> 6.  Should we support multiple configurations -- e.g. release mode and
> debug mode, where the two modes apply a certain functor to different arguments?
> 
> 7.  Should we support conditional compilation?

We have found conditional compilation useful in CM, but mostly as a way to
support multiple versions of the compiler in a single sources.cm file.
I suspect that once a library is targeting multiple implementations of SML,
it will need some mechanism to customize the build process.  Such a mechanism
could address #6 too.

> 8.  Should we standardise the semantics of "use", for those systems that
> provide a top level?  Peter Sestoft analysed the different implementations
> at the time of SML'97.
> 
> 
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers

RE: [Sml-implementers] extensions to SML: Foreign function interface

[Dave B. <da...@ta...>]

At 21:29 17/09/2001, David Matthews wrote:
>Dave,
>Have you looked at the foreign function interface that Nick Chapman did
>for Poly/ML several year ago? (See
>http://www.lfcs.ed.ac.uk/software/polyml/docs/CInterface.html ).  It's
>been used for several projects but particularly the Windows interface
>which has several hundred functions in it.  It works for dynamic
>libraries in Unix or DLLs in Windows and doesn't require the SML
>programmer to write anything but ML.

I haven't looked at it recently, although I think we looked at it when we
were working on the MLWorks FLI.  I'm about to go on holiday, but I'll look
at it when I get back.

Dave.

RE: [Sml-implementers] FLI

[Dave B. <da...@ta...>]

At 13:27 18/09/2001, Robert Harper wrote:
>3. Standardization of a foreign function interface.  I have not thought very
>much about this issue, but I can certainly see difficulties with
>compatibility not only across implementations (the various compilers out
>there), but also across platforms (primarily, Unix vs Windows).  Fundamental
>issues such as the semantics of "int" will arise, since implementations
>differ, even on the same hardware and software platform, and since external
>code will impose its own requirements.  The need for an FFI is largely
>pragmatic --- we cannot re-invent the world ourselves in our own way.
>However, as someone pointed out, buying into foreign code will certainly
>limit portability across platforms and quite possibly across
>implementations.

I think it's quite the reverse.  At present, it is virtually impossible to
write a portable library that interfaces to C.  With a standard FLI, it
will be possible.  Of course it will remain possible for people to write
non-portable code, but it will also be possible to write portable code. 

Platform differences are always present when writing libraries.  If one
platform uses 64-bit ints and another uses 16-bit ints, you either have to
ignore it (if it isn't relevant), accept it, or work your way around it.
That doesn't stop many libraries being useful on a wide variety of
platforms.  Portability is always a matter of "how many platforms" rather
than "all or none".

In any case, portability isn't always what you want.  If I write an library
for accessing the registry, the Unix users out there won't care.  Access to
platform-specific libraries is just as important as writing portable libraries.

Dave.

RE: [Sml-implementers] compilation management

[Dave B. <da...@ta...>]

(I see you've beaten me to some of the questions I ask in this message).

Some questions about compilation management.

1.  How much do we want "backwards compatibility" with each existing
implementation?  On the one hand, we want to minimise the work needed to
adopt the new system.  On the other hand, everyone will have to make some
changes, and there might be benefits from requiring more than just the
minimum.  

2.  Shall the new system require a top level?  Preferably not, IMO.

3.  Should we adopt a common suffix for file names?  E.g. ".sml" for
structures and functors; ".sig" for signatures.  The advantage is
uniformity in tools.  The disadvantage is more changes for some users. 

4.  Should we require one module per file and use the same name for the
module and the file?   The advantage is that it's easy to find modules,
easy to explain to new users, and a library file doesn't have to choose
between listing modules and files.  The disadvantage is more changes for
some users.

I'm strongly in favour of this. Apparently some people see this as a gross
imposition. I don't even begin to comprehend why they feel this way, but I
guess we have to accept their view.

5.  Should we make any file into a module?  I.e. if a file contains a set
of top-level declarations,  this would be equivalent to defining a
structure with the same name as the file.  The advantages are that novices
are using the module system as soon as they start using files, and the
module system is both natural to use and easy to explain, and we don't have
to worry about supporting "core-only" programs.  The disadvantage is that
users have to add the structure header when adding an explicit signature
constraint, or when writing a functor.  

OCaml gets a huge win from this simple mapping from files to modules; I'm
sure this is one of the design decisions that makes it popular.  OCaml
doesn't yet support functors or generic signatures as cleanly, but we can
do better.

6.  Should we support multiple configurations -- e.g. release mode and
debug mode, where the two modes apply a certain functor to different arguments?

7.  Should we support conditional compilation?

8.  Should we standardise the semantics of "use", for those systems that
provide a top level?  Peter Sestoft analysed the different implementations
at the time of SML'97.

RE: [Sml-implementers] compilation management

[Daniel C. W. <dc...@ag...>]

At 05:27 PM 9/19/2001 -0400, you wrote:
>Just to be sure we're on the same page, let me say that I would not want to
>standardize on a TOOL, but rather a LANGUAGE for expressing separate
>compilation.  In particular, saying that CM could be made to generate one
>huge source file for those of us that don't implement CM is a non-starter.
>
>An anology: CM is like type inference; we want to specify the underlying
>explicitly typed syntax.

This is a good analogy, because it lets me emphasizes my point about having one consistent standard build-inference system. Programing without build inference is like programming in ML without type inference. End users of ML would not be happy if every system had different incompatible type inference engines. 

The build language is just a first step. There should be a standard build inference system too. (e.g. CM because its there and it works.... )