sml-implementers — Standard ML implementers

[Sml-implementers] posix regression tests

[Martin E. <ma...@di...>]

Hi there,

I'm looking for regression test cases for the Posix Basis Library
structure? Neither the SML/NJ distribution nor the MLton distribution
include test cases for the Posix interface.

Cheers,

Martin

Re: [Sml-implementers] Portable library descriptions, a proposal

[Stephen W. <sw...@in...>]

> This would probably be fine, but given that I found the "only
> modular bindings" restriction to be virtually incontroversial among
> users of CM (*), I do not think that being less restrictive is such
> a big deal.

I do not like the restriction.  It creates a distinction between
toplevel values/types and modules exported by the basis library that
causes me problems.  When I use SML, I want type int to be 32 bit
integers, not 31 bit integers.  So, when I use SML/NJ, I have a CM
library containing stub code that makes structure Int = Int32 and
wraps most of the basis library so that it deals with 32 bit integers,
not 31 bit.  The trouble is, when I import this library into other
libraries, the toplevel type int is still 31 bit integers, not 32 bit.
So, I find myself writing "type int = Int.int" at the top of all of my
files.  Certainly not a showstopper, but definitely annoying.

Re: [Sml-implementers] Portable library descriptions, a proposal

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

Hi Ken,

Ken Friis Larsen wrote:

>   * In general I miss some arguments for the choices made.


I know.  But it would have made the already fairly lengthy writeup
even longer.

>   * Do you think it is impossible to make a human readable/writable
>     format (comment to footnote one on page one).  


No, I don't think it is impossible.  In fact, I implemented one: CM. :)

More seriously:

   - The goal that I set for myself was explicitly _not_ to produce a
     one-size-fits-all UI to everybody's separate compilation system.
   - It is not entirely impossible (just inconvenient) to read and write
     these descriptions if one really, really badly wants to.


>   * The datatype for abstract syntax is ugly, fx why is namespace not
>     an enumeration?


Well, I actually had some reason for this, but after carefully re-thinking
this issue, I now agree with you.  I new version of the proposal is now
online -- with the respective changes.

(Fixing the namespace type to an enumeration would make it difficult if
not impossible to write the "PGOps" module in such a way that it is oblivious
to which namespaces are being used.  Given that SML/NJ does extend the set
of namespaces, I thought that making the set easily extensible would be a good
idea.  However, I now realize that such extensibility is an illusion anyway:
I cannot export a library that uses "funsig" and expect other implementations
to be able to compile it.  Thus, SML/NJ (or rather: CM) should -- and now will --
reject any attempt of generating a "portable" library that uses "funsig".
Thus, the new policy is _non_-extensibilty:  implementations that themselves support
certain extensions to SML should not try to export these extensions into the
library description format that is shared by all implementations.)

>   * Why are the only allowed namespaces STR, SIG, and FCT?  Partly
>     addressed in section 8.


Because some systems (CM in particular) do not support other (non-modular)
exports.  The reason for this is that it greatly reduces the amount of data
that must be processed during dependency analysis.
In any case, I have very good experiences with this rule ("only modular
exports") which CM took from earlier work done at CMU.  I hope that it is not
too controversial.

One alternative approach would be to allow all namespaces ("variable/constructor",
"type", "fixity", "structure", "signature", "functor") and issue a strong informal
warning not to write libraries that export non-modular things.  Implementations
such as CM would then be forced to reject those libraries that don't heed the
warning.
This would probably be fine, but given that I found the "only modular bindings"
restriction to be virtually incontroversial among users of CM (*), I do not think
that being less restrictive is such a big deal.

(*)  The only person I know of who sometimes grumbled about the restriction is I:
      When I taught CM to treat the Basis Library as an ordinary CM library I
      sometimes wished that it would be able to handle types and variable bindings.
      When at one point I made a push for relaxing the restriction within CM at the
      expense of a more complicated dependency analysis, there were people who
      actively persuaded me _not_ to bother.

> Should we try to structure the way feedback is given, or should we
> just do it in an add-hoc fashion?  Also how do we (sml-implementers)
> determine that a proposal is agreed upon?


I don't know. As far as I am concerned, informal feedback is fine.  I have
no idea on what would constitute an official approval by the implementers.

-- 
-Matthias

Re: [Sml-implementers] Portable library descriptions, a proposal

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

Hi Matthias,

> I finished a draft proposal for portable SML library descriptions.

Thanks a lot for making such a detailed and readable proposal.  

I've only had time to read it once, thus I only have a few general
questions/comments (sprinkle IMHO as needed below):

  * In general I miss some arguments for the choices made.

  * Do you think it is impossible to make a human readable/writable
    format (comment to footnote one on page one).  

  * The datatype for abstract syntax is ugly, fx why is namespace not
    an enumeration?

  * Why are the only allowed namespaces STR, SIG, and FCT?  Partly
    addressed in section 8.

> Feedback is welcome.

Should we try to structure the way feedback is given, or should we
just do it in an add-hoc fashion?  Also how do we (sml-implementers)
determine that a proposal is agreed upon?


--Ken

[Sml-implementers] Portable library descriptions, a proposal

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

I finished a draft proposal for portable SML library descriptions.
You find the text in PDF format here:

   http://cm.bell-labs.com/cm/cs/who/blume/pgraph/proposal.pdf

Feedback is welcome.

-- 
-Matthias

Re: [Sml-implementers] flexible records

[Stephen W. <sw...@in...>]

> > In MLton, updates to the spine are seen by all the flexrecords that
> > share the spine.  Thus, there is no need to have a list of
> > back-pointers.
> 
> But it only works that easily if you have a representation of type
> schemes that keeps quantifiers implicit. For various reasons, this is
> not the case in the Alice compiler, for example.

In MLton, during type inference, the only implicitly quantified type
variables in type schemes are those corresponding to unknown fields in
flexrecords.  After type inference, MLton translates to an explicitly
typed IL in which all type variables are explicitly quantified.

> > I personally would like at least strdec, and even better topdec.  I
> > think restricting the scope to be valdec is too painful.
> 
> I agree (from a user's POV, that is ;-) ). Note however that the
> Definition in fact restricts overloading resolution to strdec.
> Unfortunately, choosing strdec also has the disadvantage of being pretty
> ambiguous due to the ambiguous grammar. So valdec still seems to be the
> only choice that is (1) unambiguous and (2) can be made consistent with
> overloading without violating explicit rules (besides being much easier
> to implement).

I guess then that I'd vote for strdec (for both) and fixing the
ambiguity.

Re: [Sml-implementers] flexible records

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

Stephen Weeks wrote:
> 
> Andreas Rossberg:
> > That is an interesting approach. Some things came to my mind, though.
> > First, you have to consider that, in general, there can be arbitrarily
> > many type schemes that you have to back-patch after discovering a new
> > field. For example:
> >
> >       val f = #foo
> >       val g = fn h => h o f
> >       val h = fn x => f x
> >       val _ = f {foo=0, bar=1}
> >
> > So a full solution requires an extendable list of back-pointers with
> > every flexible record type.
> 
> In MLton, updates to the spine are seen by all the flexrecords that
> share the spine.  Thus, there is no need to have a list of
> back-pointers.

But it only works that easily if you have a representation of type
schemes that keeps quantifiers implicit. For various reasons, this is
not the case in the Alice compiler, for example.

> Andreas Rossberg:
> > But the most important question IMHO is whether there is a simple rule
> > describing what programs can be type-checked. If there is no simple rule
> > then the behaviour of the type checker is likely to be unpredictable for
> > the user, which would be rather unfortunate. But I am now pretty
> > convinced that your scheme allows a general and simple rule like "sets
> > of labels must be determined within smallest enclosing strdec".
> 
> I think that the "general and simple rule" is that of the Definition.

Well, the Definition does not restrict the context, so defining it to
only extend to some particular phrase is not exactly the rule of the
Definition. But that's nitpicking.

> Do you have examples that you think will not be properly inferred?

No, if even signature matching is no problem then I am ready to believe
that everything will work for any choice of context. Still I am feeling
a bit uneasy since this does not seem trivial to prove and may be much
harder to implemenent in compilers using different type representations.

> The program context could be specified to be one of many things, and
> as David Matthews says, it probably makes sense for it to be the same
> as overloading.

> I personally would like at least strdec, and even better topdec.  I
> think restricting the scope to be valdec is too painful.

I agree (from a user's POV, that is ;-) ). Note however that the
Definition in fact restricts overloading resolution to strdec.
Unfortunately, choosing strdec also has the disadvantage of being pretty
ambiguous due to the ambiguous grammar. So valdec still seems to be the
only choice that is (1) unambiguous and (2) can be made consistent with
overloading without violating explicit rules (besides being much easier
to implement).

In the light of language evolution I would rather prefer to get rid of
the pain by introducing some simple form of row polymorphism.

RE: [Sml-implementers] flexible records

[Stephen W. <sw...@in...>]

David Matthews:
> I was intrigued by these examples and it set me thinking about whether
> it was possible to get these to work.  After a bit of thought I managed
> to come up with a solution and try it out in Poly/ML.  
...

I also thought about how to make it work in MLton, and came up with a
solution similar to yours.  I added an extra field to each flexrecord
to hold a "spine", which keeps track of the fields that are in the
record and whether or not more fields can be added.  The spine is
shared among all flexrecords that must have the same domain, either
due to instantiation, generalization, or unification.  Spines are easy
to unify when unifying a two flexrecords or a flexrecord and a
rigid record.  In a post-pass after unification, additional type
variables are added for fields in the spine of a generic flexrecords
that weren't originally generalized.

The upshot is that this took about 300 lines of code to implement in
MLton, and works on all the examples that have so far appeared on this
list.  The only case I know of where it fails is due to an unrelated
problem in MLton (types in signatures are ignored), which causes the
following program to fail with an unresolved flexrecord.

structure S:
   sig
      val f: {foo: int} -> int
   end =
   struct
      val f = #foo
   end

Other than examples like this, I believe that what I implemented
meets the requirements of the Definition.

David Matthews:
> On the other hand, I've come across a number of cases where I've
> wanted a function to operate on only one or two fields of a labelled
> record.  I've had to add an explicit type constraint or list all the
> fields just so that the record type is rigid within the function,
> even though the surrounding context would fully specify it.

I am often bitten by this as well, and would love to see all SML
compilers support this more powerful flexrecord inference.

Andreas Rossberg:
> That is an interesting approach. Some things came to my mind, though.
> First, you have to consider that, in general, there can be arbitrarily
> many type schemes that you have to back-patch after discovering a new
> field. For example:
> 
> 	val f = #foo
> 	val g = fn h => h o f
> 	val h = fn x => f x
> 	val _ = f {foo=0, bar=1}
> 
> So a full solution requires an extendable list of back-pointers with
> every flexible record type.

In MLton, updates to the spine are seen by all the flexrecords that
share the spine.  Thus, there is no need to have a list of
back-pointers.

Andreas Rossberg:
> But the most important question IMHO is whether there is a simple rule
> describing what programs can be type-checked. If there is no simple rule
> then the behaviour of the type checker is likely to be unpredictable for
> the user, which would be rather unfortunate. But I am now pretty
> convinced that your scheme allows a general and simple rule like "sets
> of labels must be determined within smallest enclosing strdec".

I think that the "general and simple rule" is that of the Definition.
Do you have examples that you think will not be properly inferred?  Of
course, the program context in the following Definition fragment must
be spelled out.

    For each occurrence of a record pattern containing a record
    wildcard, the program context must uniquely determine the domain
    of its row type. 

The program context could be specified to be one of many things, and
as David Matthews says, it probably makes sense for it to be the same
as overloading.

David Matthews:
> I agree.  In Poly/ML at any rate it simplifies the description of what
> is accepted.  The rule is the same for overloading, free type-variables
> and, now, flexible records: they must be specified within the topdec.
...
> While other implementations may put slightly different restrictions on
> the scope I expect it would be the same as their rules for overloading.

I personally would like at least strdec, and even better topdec.  I
think restricting the scope to be valdec is too painful.

Andreas Rossberg:
> A larger scope may again be problematic because we then had to cope
> with interactions between flexible records and signature matching.

I don't see why this causes problems.  Signature matching can impose
constraints on the domain of a flexrecord just as unification can.

RE: [Sml-implementers] flexible records

[David M. <Dav...@pr...>]

On Wednesday, October 17, 2001 6:20 PM, Andreas Rossberg
[SMTP:ros...@ps...] wrote:

> That is an interesting approach. Some things came to my mind, though.
> First, you have to consider that, in general, there can be arbitrarily
> many type schemes that you have to back-patch after discovering a new
> field. 
> So a full solution requires an extendable list of back-pointers with
> every flexible record type. Lists must be concatenated when unifying
two
> such types.
> 
> Another effect one has to take care of is that there can be
monomorphic
> type schemes where you must not add quantifiers because of the value
> restriction:

I didn't give much in the way of implementation details in my previous
message but simply a quick explanation.  There are a number of details
that have to be considered.

The actual implementation of the back-pointers is as a list of
type-variables.  As well as acting as references which can be updated
when fields are added to the record or frozen (made rigid) the
type-variables also carry information such as the equality attribute.
That is important in examples such as:

local
	fun f (x as {a, ...}) = (x=x; a)
	fun g {a, ...} = a
	fun h x = (g x; f x)
	val _ = h{a=1, b=2}
in
	val f = f and g = g and h = h
end;

where fields added to f and h have to be equality types but not those
added to g:

val f = fn : {a: ''a, b: ''b} -> ''a
val g = fn : {a: 'a, b: 'b} -> 'a
val h = fn : {a: ''a, b: ''b} -> ''a

Whenever an instance of flexible record type is found there is a need to
check back to the generic to see if any fields have been added since the
instance was created.  Here again new type variables have to added with
attributes depending on both the generic and the instance.

local
	val f = #foo
	val g = valOf o f
	val _ = f {foo=0, bar=1}
in
	val g = g
end;

In this example the type variable added to g is not bound within g and
so there is a message about free type variables.

Warning:
The type of (g) contains a free type variable.
Setting it to a unique monotype.

val g = fn : {bar: _b, foo: _a option} -> _a

> But the most important question IMHO is whether there is a simple rule
> describing what programs can be type-checked. If there is no simple
rule
> then the behaviour of the type checker is likely to be unpredictable
for
> the user, which would be rather unfortunate. 

I agree.  In Poly/ML at any rate it simplifies the description of what
is accepted.  The rule is the same for overloading, free type-variables
and, now, flexible records: they must be specified within the topdec.
For example:
> structure S = struct val f = #foo end val _ = S.f{foo=1, goo=2};
structure S : sig val f : {foo: 'a, goo: 'b} -> 'a end

> structure S : sig val f : {a: 'a, b: 'b} -> 'a end = struct val f = #a
end;
structure S : sig val f : {a: 'a, b: 'b} -> 'a end

While other implementations may put slightly different restrictions on
the scope I expect it would be the same as their rules for overloading.

David.

Re: [Sml-implementers] flexible records

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

David Matthews wrote:
> 
> Poly/ML uses references for type variables (as I guess many
> implementation do) and creating an instance from a generic type involves
> copying the type generating new references for each type variable.  This
> normally loses the connection between an instance and the original
> generic so that unification of an instance does not affect the generic.
> This solution requires a pointer back from each instance to the
> corresponding generic.

That is an interesting approach. Some things came to my mind, though.
First, you have to consider that, in general, there can be arbitrarily
many type schemes that you have to back-patch after discovering a new
field. For example:

	val f = #foo
	val g = fn h => h o f
	val h = fn x => f x
	val _ = f {foo=0, bar=1}

So a full solution requires an extendable list of back-pointers with
every flexible record type. Lists must be concatenated when unifying two
such types.

Another effect one has to take care of is that there can be monomorphic
type schemes where you must not add quantifiers because of the value
restriction:

	val f = #foo
	val g = valOf o f
	val _ = f {foo=0, bar=1}

Here, back-patching the type scheme of g actually requires
reverse-introduction of a free type variable. This may or may not be
problematic in general, I am not completely sure. At least the
back-pointers have to be decorated with some flag.

But the most important question IMHO is whether there is a simple rule
describing what programs can be type-checked. If there is no simple rule
then the behaviour of the type checker is likely to be unpredictable for
the user, which would be rather unfortunate. But I am now pretty
convinced that your scheme allows a general and simple rule like "sets
of labels must be determined within smallest enclosing strdec". (A
larger scope may again be problematic because we then had to cope with
interactions between flexible records and signature matching.)

	- Andreas

RE: [Sml-implementers] flexible records

[David M. <Dav...@pr...>]

I was intrigued by these examples and it set me thinking about whether
it was possible to get these to work.  After a bit of thought I managed
to come up with a solution and try it out in Poly/ML.  The critical part
of the solution is to realise that unifying an instance of a generic
flexible record type involves not only the instance itself but also the
generic.  For example in,
val g = #foo
val _ = g {foo = 13, goo = 1.0}
g has type {foo:'a, ...} -> 'a after the declaration.  Unification of
the instance in the second line replaces the 'a by int but in addition
it has the effect of adding an extra field (whose type is a new bound
variable) to the generic version of g and making it rigid.  After the
unification g now has type {foo:'a, goo:'b} -> 'a.

Poly/ML uses references for type variables (as I guess many
implementation do) and creating an instance from a generic type involves
copying the type generating new references for each type variable.  This
normally loses the connection between an instance and the original
generic so that unification of an instance does not affect the generic.
This solution requires a pointer back from each instance to the
corresponding generic. 

This works on all the examples as well as more complicated ones.  I have
not, though, decided whether to retain this code in the released version
of the compiler.  Most other compilers seem to require records to be
fully specified at the point where they would be generalised so it might
not be helpful to users to have a more generous scheme if they wanted to
be able to write portable code.  On the other hand, I've come across a
number of cases where I've wanted a function to operate on only one or
two fields of a labelled record.  I've had to add an explicit type
constraint or list all the fields just so that the record type is rigid
within the function, even though the surrounding context would fully
specify it.

It's worth noting that this is very similar to the handling of
overloading.  There again the use of an instance affects the generic.
The difference is that because we only have overloading on monotypes
there's no need to generalise.  If we allowed overloading on polytypes,
for instance if + could be overloaded as concatenation of lists, we'd
have to use a scheme along these lines.

David.

On Thursday, October 11, 2001 4:39 PM, Stephen Weeks
[SMTP:sw...@in...] wrote:
> 
> Inspired by Andreas' tests, I was trying to understand type inference
with
> flexible records.  I created a few more flexrecord examples (below),
and
> tried
> them out on the SML compilers that I have around.  The results are in
the
> table
> below.  I would be interested to hear if and an explanation of why the
> Definition requires any of these examples to succeed.
> 
> 		SML/NJ	MosML	MLton	MLKit	Poly/ML	MLWorks	Alice
> 		110.0.7	2.00	011006	4.0.0	4.1.1	2.0	Oper2
> 
> flexrecord	+	+	+	+	+	-	+
> flexrecord2	-	+	-	+	-
> flexrecord3	-	+	-	+	-
> flexrecord4	-	-	-	-	-
> 
> (* flexrecord2 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13}
>       val _ = g {foo = "yes"}
>    in
>       ()
>    end
> (* flexrecord2 *)
> 
> (* flexrecord3 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13, goo = 1.0}
>       val _ = g {foo = "yes", goo = 1.0}
>    in
>       ()
>    end
> (* flexrecord3 *)
> 
> (* flexrecord4 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13, goo = 1.0}
>       val _ = g {foo = "yes", goo = false}
>    in
>       ()
>    end
> (* flexrecord4 *)
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers

[Sml-implementers] Don't read, if you have plenty of $$$ already.

[<ml...@ho...>]

*******************************************************
DISCLAIMER: This is a one-time e-mail.  We are sorry if
we have inconvenienced you, and if you wish to be rem-
oved from our list please reply to this message with
the word 'REMOVE' in the subject line.  Thank you.
*******************************************************


THIS IS THE BEST MONEY MAKER OF ALL!! NO SELLING,
FOLLOW-UPS OR INTENSIVE LABOR!! NO RISK AND EASY AS
PIE!! READ CAREFULLY!!


$$$"TRUE STORY" SEEN ON ABC's 20-20 "BOY 15 MAKES 71
THOUSAND IN 5 WKS!!! YOU CAN TO!!"

AS SEEN ON NATIONAL TV: THIS IS THE ONE!

Parents of 15-year-old find $71,000 cash hidden in his
closet.

Does this headline look familiar? Of course it does.
You most likely have just seen this story recently
featured on a major nightly news program (USA).


His mother was cleaning and putting laundry away when
she came across a large brown paper bag that was
suspiciously buried beneath some clothes and a
skateboard in the back of her 15-year-old sons
closet. Nothing could have prepared her for the shock
she got when she opened the bag and found it was full
of cash. Five-dollar bills, twenties, fifties and
hundreds - all neatly rubber-banded in labeled piles.


"My first thought was that he had robbed a bank", says
the 41-year-old woman, "There was over $71,000 dollars
in that bag -- that's more than my husband earns in a
year".

The woman immediately called her husband at the
car-dealership where he worked to tell him what she
had discovered. He came home right away and they drove
together to the boys school and picked him up. Little
did they suspect that where the money came from was
more shocking than actually finding it in the closet.

As it turns out, the boy had been sending out, via
E-mail, a type of "Report" to E-mail addresses that he
obtained off of the Internet. Everyday after school
for the past 2 months, he had been doing this right on
his computer in his bedroom.

"I just got the E-mail one day and I figured what the
heck, I put my name on it like the instructions said
and I started sending it out", says the clever
15-year-old.

The E-mail letter listed 5 addresses and contained
instructions to send one $5 dollar bill to each person
on the list, then delete the address at the top and
move the others addresses down , and finally to add
your name to the top of the list.

The letter goes on to state that you would receive
several thousand dollars in five-dollar bills within 2
weeks if you sent out the letter with your name at the
top of the 5-address list. "I get junk E-mail all the
time, and really did not think it was going to work",
the boy continues.

Within the first few days of sending out the E-mail,
the Post Office Box that his parents had gotten him
for his video-game magazine subscriptions began to
fill up with not magazines, but envelopes containing
$5 bills.

"About a week later I rode [my bike] down to the post
office and my box had 1 magazine and about 300
envelops stuffed in it. There was also a yellow slip
that said I had to go up to the [post office] counter.
I thought I was in trouble or something (laughs)". He
goes on, "I went up to the counter and they had a
whole box of more mail for me.I had to ride back home
and empty out my backpack because I could not carry it
all".

Over the next few weeks, the boy continued sending out
the E-mail."The money just kept coming in and I just
kept sorting it and stashing it in the closet, barely
had time for my homework". He had also been riding his
bike to several of the banks in his area and
exchanging the $5 bills for twenties, fifties and
hundreds.

"I didn't want the banks to get suspicious so I kept
riding to different banks with like five thousand at a
time in my backpack. I would usually tell the lady at
the bank counter that my dad had sent me in [to
exchange the money] and he was outside waiting for
me. One time the lady gave me a really strange look
and
told me that she would not be able to do it for me and
my dad would have to come in and do it, but I just
rode to the next bank down the street (laughs)."

Surprisingly, the boy did not have any reason to be
afraid. The reporting news team examined and
investigated the so-called "chain-letter" the boy was
sending out and found that it was not a chain-letter
at all. In fact, it was completely legal according to
US Postal and Lottery Laws, Title 18, Section 1302 and
1341, or Title 18, Section 3005 in the US code, also
in the code of federal regulations, Volume 16,
Sections 255 and 436, which state a product or service
must be exchanged for money received.

Every five-dollar bill that he received contained a
little note that read, "Please send me report number
XYX".This simple note made the letter legal because he
was exchanging a service (A Report on how-to) for a
five-dollar fee.

Here is the letter that the 15-year-old was sending
out by E-mail, you can do the exact same thing he was
doing, simply by following the instructions in this
letter.


Dear Friends & Future Millionaires:

AS SEEN ON NATIONAL TV:


Making over half million dollars every 4 to 5 months
from your home for an investment of only $25 U.S.
Dollars expense one time.
THANKS TO THE COMPUTER AGE AND THE INTERNET !

=======================================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!

Before you say ''Bull'', please read the following.
This is the letter you have been hearing about on the
news lately. Due to the popularity of this letter on
the Internet, a national weekly news program recently
devoted an entire show to the investigation of this
program described below, to see if it really can make
people money. The show also investigated whether or
not the program was legal.

Their findings proved once and for all that there are
''absolutely NO Laws prohibiting the participation in
the program'' and if people can follow the simple
instructions, they are bound to make some mega bucks
with only $25 out of pocket cost. DUE TO THE RECENT
INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS
ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER.

This is what one had to say: ''Thanks to this
profitable opportunity. I was approached many times
before but each time I passed on it. I am
so glad I finally joined just to see what one could
expect in return for the minimal effort and money
required. To my astonishment, I received total
$610,470.00 in 21 weeks, with money still coming in.''
Pam Headland, Fort Lee, New Jersey.

=======================================================

Here is another testimonial: ''This program has been
around for a long time but I never believed in it. But
one day when I received this again in the mail I
decided to gamble my $25 on it. I followed the simple
instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00
but the next 2 months after that I made a total of
$290,000.00. So far, in the past 8 months by
re-entering the program, I have made over $710,000.00
and I am playing it again. The key to success in this
program is to follow the simple steps and NOT change
anything.'' More testimonials later but first,

=======================================================

PRINT THIS NOW FOR YOUR FUTURE REFERENCE
=======================================================

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

If you would like to make at least $500,000 every 4 to
5 months easily and comfortably, please read the
following...THEN READ IT AGAIN and AGAIN!!!

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR
FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED!
INSTRUCTIONS:

Order all 5 reports shown on the list below For each
report, send $5 CASH,
THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and
YOUR E-MAIL ADDRESS to the person whose name appears
ON THAT LIST next to the report.

MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP
LEFT CORNER in case of any mail problems.

When you place your order, make sure you order each of
the 5 reports. You will need all 5 reports so that you
can save them on your computer and resell them. YOUR
TOTAL COST $5 X 5=$25.00. Within a few days you will
receive, via e-mail, each of the 5 reports from
these 5 different individuals. Save them on your
computer so they will be accessible for you to send to
the 1,000's of people who will order them from you.
Also make a floppy of these reports and keep it on
your desk in case something happens to your computer.
IMPORTANT - DO NOT alter the names of the people who
are listed next to each report, or their sequence on
the list, in any way other than what isinstructed
below in step '' 1 through 6 '' or you will loose out
on the majority of your profits. Once you understand
the way this works, you will also see how it does not
work if you change it. Remember, this method has been
tested, and if you alter, it will NOT work !!! People
have tried to put their friends/relatives names on all
five thinking they could get all the money.

But it does not work this way. Believe us, we all have
tried to be greedy and then nothing happened. So Do
Not try to change anything other than what
is instructed. Because if you do, it will not work for
you.

Remember, honesty reaps the reward!!!

1.... After you have ordered all 5 reports, take this
advertisement and REMOVE the name & address of the
person in REPORT # 5.

This person has made it through the cycle and is no
doubt counting their fortune.

2.... Move the name & address in REPORT # 4 down TO
REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO
REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO
REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO
REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1
Position.

PLEASE MAKE SURE you copy every name & address
ACCURATELY!
=======================================================


Take this entire letter, with the modified list of
names, and save it on your computer. DO NOT MAKE ANY
OTHER CHANGES. Save this on a disk as well just in
case you loose any data.
To assist you with marketing your business on the
internet, the 5 reports you purchase will provide you
with invaluable marketing information which
includes how to send bulk e-mails legally, where to
find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:
METHOD #1: BY SENDING BULK E-MAIL LEGALLY

=======================================================



Let's say that you decide to start small, just to see
how it goes, and we will assume You and those involved
send out only 5,000 e-mails each. Let's also
assume that the mailing receive only a 0.2% response
(the response could be much better but lets just say
it is only 0.2%. Also many people will send
out hundreds of thousands e-mails instead of only
5,000 each).

Continuing with this example, you send out only 5,000
e-mails. With a 0.2% response, that is only 10 orders
for report # 1. Those 10 people responded
by sending out 5,000 e-mail each for a total of
50,000. Out of those 50,000 e-mails only 0.2%
responded with orders. That's=100 people responded and
ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails.
The 0.2% response to that is 1000 orders for Report #
3. Those 1000 people send out 5,000 e-mails each for a
total of 5 million e-mails sent out. The 0.2% response
to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a
total of 50,000(50 million) e-mails. The 0.2% response
to that is 100,000 orders for Report
# 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00
(half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000
Grand Total=$555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY !
=======================================================



REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO.
Dare to think for a moment what would happen if
everyone or half or even one 4th of those people
mailed 100,000 e-mails each or more? There are
over 150 million people on the Internet worldwide and
counting. Believe me, many people will do just that,
and more!
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
=======================================================

Advertising on the net is very inexpensive and there
are hundreds of FREE places to advertise. Placing a
lot of free ads on the Internet will
easily get a larger response. We strongly suggest you
start with Method # 1 and METHOD # 2 as you go along.
For every $5 you receive, all you
must do is e-mail them the Report they ordered. That's
it. Always provide same day service on all orders.

This will guarantee that the e-mail they send out,
with your name and address on it, will be prompt
because they can not advertise until they receive the
report.

AVAILABLE REPORTS
==============================================
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.
Notes: Always send $5 cash (U.S. CURRENCY) for each
Report. Checks NOT accepted. Make sure the cash is
concealed by wrapping it in at least 2
sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are
ordering, YOUR E-MAIL ADDRESS and your name
and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW!!! :
=======================================================

_______________________________________________________
REPORT #1 "The Insider's Guide to Advertising for Free
on the Internet"

ORDER REPORT #1 FROM:

Tommy Pope
5780 Milgen Road # 708
Columbus, GA 31907
USA

_______________________________________________________
REPORT #2 "The Insider's Guide to Sending Bulk E-mail
on the Internet"

ORDER REPORT #2 FROM:

Scott Katip
3110 5th Ave.
Beaver Falls, PA 15010
USA

_______________________________________________________
REPORT #3 "The Secrets to Multilevel Marketing on the
Internet"

ORDER REPORT #3 FROM:

Chris Rhodes
7915 Kleingreen
Spring, TX 77379
USA

_______________________________________________________
REPORT #4 "How to become a Millionaire utilizing the
Power of Multilevel Marketing and the Internet"

ORDER REPORT #4 FROM:

Don Lott
1009 East Mailback Way
Crestwood, KY 40014
USA

_____________________________________________________
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"

ORDER REPORT #5 FROM:
Zach Simmons
2135 Springwood
Carrollton, TX 75006
USA

______________________________________________________
Please remember that your $5 bills are going all
around the world and delivery of reports could take
from 3 days up to 2wks.
_______________________________________________________





YOUR SUCCESS GUIDELINES



Follow these guidelines to guarantee your success:
If you do not receive at least 10 orders for Report #1
within 2 weeks, continue sending e-mails until you do.
After you have received 10 orders, 2 to 3 weeks after
that you should receive 100 orders or more for REPORT
# 2. If you did not, continue advertising or sending
e-mails until you do. Once you have received 100 or
more orders for Report # 2, YOU CAN RELAX,
because the system is already working for you, and the
cash will continue to roll in!

THIS IS IMPORTANT TO REMEMBER:

Every time your name is moved down on the list, you
are placed in front of a Different report. You can
KEEP TRACK of your PROGRESS by watching which report
people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START
THE WHOLE PROCESS AGAIN.

There is NO LIMIT to the income you can generate from
this business !!!
=======================================================



FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:
You have just received information that can give you
financial freedom for the rest of your life, with NO
RISK and JUST A LITTLE BIT OF EFFORT. You can make
more money in the next few weeks and months than you
have ever imagined. Follow the program EXACTLY AS
INSTRUCTED. Do Not change it in any way. It works
exceedingly well as it is now. Remember to e-mail a
copy of this exciting report after you have put
your name and address in Report #1 and moved others to
#2 ...........# 5 as instructed above. One of the
people you send this to may send out
100,000 or more e-mails and your name will be on every
one of them. Remember though, the more you send out
the more potential customers you will reach. So my
friend, I have given you the ideas, information,
materials and opportunity to become financially
independent. IT IS UP TO YOU NOW !

MORE TESTIMONIALS:

"My name is Mitchell. My wife, Jody and I live in
Chicago. I am an accountant with a major U.S.
Corporation and I make pretty good money.
When I received this program I grumbled to Jody about
receiving ''junk mail''. I made fun of the whole
thing,spouting my knowledge of the
population and percentages involved. I ''knew'' it
wouldn't work. Jody totally ignored my supposed
intelligence and few days later she jumped in with
both feet. I made merciless fun of her, and was ready
to lay the old ''I told you so'' on her when the thing
didn't work. Well, the laugh was on me! Within 3 weeks
she had received 50 responses. Within the next 45 days
she had received total $ 147,200.00 ........... all
cash! I was shocked. I have joined Jody in her
''hobby''.Mitchell Wolf M.D., Chicago, Illinois
=======================================================



''Not being the gambling type, it took me several
weeks to make up my mind to participate in this plan.
But conservative that I am, I decided that
the initial investment was so little that there was
just no way that I wouldn't get enough orders to at
least get my money back''. '' I was
surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first
12 weeks. The nice thing about
this deal is that it does not matter where people
live. There simply isn't a
better investment with a faster return and so big."
Dan Sondstrom, Alberta, Canada
=======================================================



''I had received this program before. I deleted it,
but later I wondered if I should have given it a try.
Of course, I had no idea who to contact to
get another copy, so I had to wait until I was
e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not
delete this one! I made more than $490,000 on my first
try and all the money came within 22 weeks."
Susan De Suza, New York, N.Y.
=======================================================


''It really is a great opportunity to make relatively
easy money with little cost to you. I followed the
simple instructions carefully and
within 10 days the money started to come in. My first
month I made $20,560.00 and by the end of third month
my total cash count was
$362,840.00. Life is beautiful, Thanks to internet.".
Fred Dellaca, Westport, New Zealand
=======================================================




ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR'
ROAD TO FINANCIAL FREEDOM!

=======================================================
If you have any questions on the legality of this
program, contact the Office of Associate Director for
Marketing Practices, Federal Trade Commission, Bureau
of Consumer Protection, Washington, D.C.



----------------------------------------

God Bless and Be Happy :)
 
 
 
 
 

Re: [Sml-implementers] Subject: Standard ML

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

Dave Berry wrote:
> 
> At 18:51 08/10/2001, Andreas Rossberg wrote:
> > IMHO abstype in
> >its current form is simply broken. That is another reason why I would
> >like to see it removed from the language -- or turned into a derived
> >form:
> >
> >       abstype t = conbind with dec end --->
> >               local datatype t = conbind in type t = t dec end
> >
> >AFAICS, the only difference with the current definition would be that
> >equality of t is transparent - but that is exactly what is required to
> >avoid the current problems of non-principality and type structures not
> >respecting equality. And it is a conservative change, not breaking any
> >legal program (I think).
> 
> It doesn't break any legal program, but it could break a library,

Not in the sense that client code could violate invariants of the
library, e.g. by enabling it to construct bogus values or turn library
state inconsistent. It just gives clients one additional operation that
does not have a useful meaning. So the effect is rather harmless, IMHO.
The only danger is that newly written client code might accidently use
polymorphic equality on the lib type, but you should double check all
uses of equality anyway. Moreover, I believe there are very few libs
around that still use abstype, and newly written code based on such libs
will be even rarer.

> and also render books obsolete.

True, but when we speak about evolving the language this has to be taken
care of anyway.

	- Andreas

Re: [Sml-implementers] flexible records

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

Stephen Weeks wrote:
> 
> I would be interested to hear if and an explanation of why the
> Definition requires any of these examples to succeed.

My reading is that the Definition requires all of these examples to
elaborate: in all cases the "program context uniquely determines the
labels of the fields to be matched". The amount of "program context" is
not restricted in the text.

But that is clearly a "bug" IMHO. Even for local declarations you will
have a very hard time implementing it without going almost all the way
to full polymorphic record typing. When you generalise, you have to know
the set of labels to determine what free type variables there are. I
suppose what Mosml and the Kit do is just to assume none, i.e. the
flexible part has to be monomorphic. This way they can type 2 and 3, but
not 4, which seems rather ad-hoc.

Thus the only clean rule I can think of that avoids polymorphic record
typing is restricting the "program context" to the innermost enclosing
value declaration, consistently invalidating all 3 examples.

BTW, Alice can type 2, but not 3 and 4 - it assumes that the flexible
part is empty. Cannot check MLWorks right now.

> (* flexrecord2 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13}
>       val _ = g {foo = "yes"}
>    in
>       ()
>    end
> (* flexrecord2 *)
> 
> (* flexrecord3 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13, goo = 1.0}
>       val _ = g {foo = "yes", goo = 1.0}
>    in
>       ()
>    end
> (* flexrecord3 *)
> 
> (* flexrecord4 *)
> val _ =
>    let
>       val g = #foo
>       val _ = g {foo = 13, goo = 1.0}
>       val _ = g {foo = "yes", goo = false}
>    in
>       ()
>    end
> (* flexrecord4 *)

[Sml-implementers] flexible records

[Stephen W. <sw...@in...>]

Inspired by Andreas' tests, I was trying to understand type inference with
flexible records.  I created a few more flexrecord examples (below), and tried
them out on the SML compilers that I have around.  The results are in the table
below.  I would be interested to hear if and an explanation of why the
Definition requires any of these examples to succeed.

		SML/NJ	MosML	MLton	MLKit	Poly/ML	MLWorks	Alice
		110.0.7	2.00	011006	4.0.0	4.1.1	2.0	Oper2

flexrecord	+	+	+	+	+	-	+
flexrecord2	-	+	-	+	-
flexrecord3	-	+	-	+	-
flexrecord4	-	-	-	-	-

(* flexrecord2 *)
val _ =
   let
      val g = #foo
      val _ = g {foo = 13}
      val _ = g {foo = "yes"}
   in
      ()
   end
(* flexrecord2 *)

(* flexrecord3 *)
val _ =
   let
      val g = #foo
      val _ = g {foo = 13, goo = 1.0}
      val _ = g {foo = "yes", goo = 1.0}
   in
      ()
   end
(* flexrecord3 *)

(* flexrecord4 *)
val _ =
   let
      val g = #foo
      val _ = g {foo = 13, goo = 1.0}
      val _ = g {foo = "yes", goo = false}
   in
      ()
   end
(* flexrecord4 *)

Re: [Sml-implementers] Subject: Standard ML

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

> > But, I don't understand why valrec.sml test case should raise Bind:
> > 
> >     val rec LESS = fn x => x    (* will raise Bind *)
> >     and NONE as SOME = fn x => x
> >     val SOME = 1;  
> 
> Rule (26) has no impact on the dynamic semantics [...]

Of course, I see.  So the point is that rule (126) in the dynamic
semantics neglects to change the identifier status, but the behaviour
of the implementations is sensible.

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] Subject: Standard ML

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

At 18:51 08/10/2001, Andreas Rossberg wrote:
> IMHO abstype in
>its current form is simply broken. That is another reason why I would
>like to see it removed from the language -- or turned into a derived
>form:
>
>	abstype t = conbind with dec end --->
>		local datatype t = conbind in type t = t dec end
>
>AFAICS, the only difference with the current definition would be that
>equality of t is transparent - but that is exactly what is required to
>avoid the current problems of non-principality and type structures not
>respecting equality. And it is a conservative change, not breaking any
>legal program (I think).

It doesn't break any legal program, but it could break a library, and also
render books obsolete.  One use (arguably the only remaining use) of
abstype in the full language is precisely to remove the equality attribute
of a type.  If a library author has made use of this property, then removal
of the property would make that implementation unsound (even though it
would still compile).

IMO it would be preferable to settle on the existing behaviour of most
compilers.  Ideally we should replace the rule in the Definition with one
that doesn't have this flaw, but if that isn't possible then we should just
document this as a problem in the Definition and explain how compilers
should behave in practice.

I don't know if a formal specification is practical.  One approach might be
to reintroduce the notion of principal environments purely for the body of
abstypes.  But that might be too restrictive (and it could possibly break
existing code). 

Dave.

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

> But, I don't understand why valrec.sml test case should raise Bind:
> 
>     val rec LESS = fn x => x    (* will raise Bind *)
>     and NONE as SOME = fn x => x
>     val SOME = 1;  

Rule (26) has no impact on the dynamic semantics, as defined by rules
(124, 125, 126), which will match the LESS pattern just as in

	val LESS = fn x => x

In both cases,

	E, v |- LESS => FAIL

and hence by rule 125,

	E |- LESS = fn x => x => [Bind]

and hence, by the implicit extension of rule 126 to exception packets,

	E |- rec LESS .... => [Bind]

Re: [Sml-implementers] Subject: Standard ML

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

Andreas,

> OK, here you go. Don't be shocked: the list is quite exhaustive and
> contains a lot of pedantic stuff. There are very few "major" issues.

Thanks for the list.  I believe the scarcity of major issues testifies
to the amount of work and care that has gone into the Definition, and
also reflects much feedback from thoughtful users and implementors.

It would probably take five years to obtain similar quality in a
new-style definition for a new language, and another five-ten years
before implementations agree on the interpretation of the fine
points. 

Reason enough not to destroy what we have.

> During compiling this I also made a bunch of contrived test files to
> see how implementations cope with some of the more obscure details 

This is a very useful idea, and the results comforting ...

But, I don't understand why valrec.sml test case should raise Bind:

    val rec LESS = fn x => x    (* will raise Bind *)
    and NONE as SOME = fn x => x
    val SOME = 1;  

According to rule (26), and as stressed in the comment to that rule,
the identifier status may change in the recursive binding, so LESS,
NONE and SOME are value variables, and the example is no different
from this:

    val rec a = fn x => x    (* will raise Bind *)
    and b as c = fn x => x
    val c = 1;  

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

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

Dave Berry wrote:
> 
> At 10:10 21/09/2001, Matthias Blume wrote:
> >> We could even go so far as to require that no files
> >> in a given library should be case-insensitive-equal. ...
> >
> >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.
> 
> One thing to consider is whether to provide any support for directories in
> the file paths.  If so, then either we need a convention for directory
> syntax, or people may have to rewrite their project files when they move
> between OSs.  (Although I believe Windows now recognises Unix-style
> directory syntax -- i.e forward slash).  If we do adopt such a convention,
> then we are already part way to limiting the names that can appear.

All this these suggestions and more are fine, but I still think that we should
not burn them into any "standard" (even though we are no longer permitted to
use the word "standard" :-).

My suggestion would be the following 3-point plan:

1. Define a library specification format where file names are coded as generic
   strings, accommodating any possible OS- and implementation-specific name.

   I am actually working on the above.  Please, have patience for a few more days
   until I am ready to unveil my creation. :)

2. Specify a portable pathname syntax, perhaps only for relative pathnames (but
   including the possibility of subdirectories and perhaps even "parent" arcs etc.)
   A library description as I am currently designing it will abstract over a "context"
   relative to which such pathnames are to be interpreted.

   My personal preference for "portable" syntax is Unix-style.

3. Provide an escape hatch from portable pathname syntax to "native" syntax for those
   who don't care about portability for one reason or another.

So the point is that the specification language itself will be neutral to pathname
conventions, but there will be strict guidelines that anyone should follow who
wishes to create portable libraries.

> Possibly the most annoying effect of this limitation would be on people who
> want to write filenames in an non-English language.  But they already have
> to write all their identifiers in ASCII.

Two answers to this:

A. The "portable" syntax from above (point 2.) could and perhaps should allow for
   UTF-8 characters.  (The software that will be processing these names does not
   care about the Unicode-semantics of individual characters with the exception
   of the arc separator '/' and possibly parent- and current arcs (".." and ".").)

B. I wish we could write identifiers using UTF-8 as well. :-)

-- 
-Matthias

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

> It's not easy, I'm afraid. Consider the following abstype declaration:
> 
> 	abstype t = T with
> 	    val t = T
> 	    val eq = op=
> 	end
> 
> Depending on the context, type inference has to choose between two type
> schemes it can sensibly assign to eq:
> 
> 	sigma1 = ''a * ''a -> bool
> 	sigma2 = t * t -> bool
...

Thanks for all the examples.  They didn't quite convince me that it
would be too hard to implement, since it seems like similar tricks
that one uses to implement overloading would work in them (namely,
delaying a decision about the type of an instantiation until all the
uses are known).  However, the following example does convince me
that this is hard to implement.

(* Elaborates with sigma1 *)
abstype t = T with
   val t = T
   val eq = op=
end
fun f (x, y) = eq (x, y)
val _ = f (1, 2)

(* Reject *)
abstype t = T with
   val t = T
   val eq = op=
end
fun f (x, y) = eq (x, y)
val _ = f (1, 2)
val _ = eq (t, t)

These two examples show that one actually has to make decisions about
generalization before all of the uses are known.  This is worse than
overloading, which only instantiates to monotypes, not type variables.

> So I believe it is very hard to get the semantics of abstype right in a
> compiler - probably even harder than parsing fun-case. IMHO abstype in
> its current form is simply broken. That is another reason why I would
> like to see it removed from the language -- or turned into a derived
> form:
> 
> 	abstype t = conbind with dec end --->
> 		local datatype t = conbind in type t = t dec end
> 
> AFAICS, the only difference with the current definition would be that
> equality of t is transparent - but that is exactly what is required to
> avoid the current problems of non-principality and type structures not
> respecting equality. And it is a conservative change, not breaking any
> legal program (I think).

I agree, and like your solution.

Re: [Sml-implementers] Subject: Standard ML

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

Stephen Weeks wrote:
> 
> > Note 
> > btw. that the reason why "abstype" is actually working in Alice is only
> > due to the fact that the compiler does not distinguish equality types. I
> > guess the same is true for MLton?
> 
> Right (among the hundred or so things that MLton ignores).  I will
> probably go for the overloading solution if/when I ever get around to
> writing a proper front-end.  It doesn't seem too hard.

It's not easy, I'm afraid. Consider the following abstype declaration:

	abstype t = T with
	    val t = T
	    val eq = op=
	end

Depending on the context, type inference has to choose between two type
schemes it can sensibly assign to eq:

	sigma1 = ''a * ''a -> bool
	sigma2 = t * t -> bool

But both exclude each other. Every program that requires both must be
rejected. Here are some examples covering most interesting cases:

(* (1a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(2,3);

(* (1b) Elaborates with sigma2 *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(t,t);

(* (1c) Reject: elaborates with neither *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(2,3) andalso eq(t,t);

(* (2a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t)
end;
eq(2,3);

(* (2b) Elaborates with sigma2 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t)
end;
eq(t,t);

(* (2c) Reject *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(2,3)
end;
eq(t,t);

(* (3a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t) andalso eq(2,3)
end;
eq(2,3);

(* (3b) Reject *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t) andalso eq(2,3)
end;
eq(t,t);

In most of these examples, when trying standard type inference, we had
to instantiate eq's type scheme before knowing which it is. In
particular, later declarations may invalidate possible typings for the
abstype body (e.g. 2a vs 2b, or 3a vs 3b). Not really obvious how this
could be implemented. And it is reminiscent of the free tyvar problem,
only worse.

So I believe it is very hard to get the semantics of abstype right in a
compiler - probably even harder than parsing fun-case. IMHO abstype in
its current form is simply broken. That is another reason why I would
like to see it removed from the language -- or turned into a derived
form:

	abstype t = conbind with dec end --->
		local datatype t = conbind in type t = t dec end

AFAICS, the only difference with the current definition would be that
equality of t is transparent - but that is exactly what is required to
avoid the current problems of non-principality and type structures not
respecting equality. And it is a conservative change, not breaking any
legal program (I think).

	- Andreas

Re: [Sml-implementers] compilation management

[Doug C. <e...@fl...>]

At 10:14 PM +0100 10/6/01, Dave Berry wrote:
>[...] As a concrete proposal,
>suppose that files had to use the following character set:
>[a-zA-Z0-9_+.-], they had to be case-insensitive, and directories were
>indicated with forward slashes.  This would be portable across all versions
>of Windows (including CE, and including both FAT and NTFS), all versions of
>Unix/Linux, and (I think) MacOS.  Projects might not port to OS's that
>limit the length of file names beyond the user's choice of names, or OS's
>that have other limitations; in these cases users would have to rewrite the
>file names.  So this achieves a level of portability that is pragmatically
>useful, and is never worse than the alternative.

This would work well with MacOS. Pathname and arc length limitations 
are an area where guidance to the user should be provided, and 
perhaps warnings issued by the compilation manager, to foster 
portability. For example, MacOS (version <= 9) limits path lengths to 
255 (or 511) characters, and arcs to 32 characters. Other file system 
may not like '.' used arbitrarily in file names. MacOS doesn't care.

At 2:42 PM +0200 10/8/01, Andreas Rossberg wrote:
>Why not adopt an existing standard and use (a subset of) URI path
>syntax? It is well-known, more or less system independent, and
>expressive enough - and pleasently close to Unix syntax. Every OS
>already has conventions to map it down to native paths.

It is nice that URI provides a means for specifying both relative and 
absolute paths, including syntax for climbing a relative path 
hierarchy. The difficulty, of course, is defining a reasonable 
subset, since many kinds of non-portable path and file names can be 
written with URI.

Dave Berry's character set and case-insensitivity, augmented with 
URI's relative path traversal, is about right. Add arc length 
limitations, and we'd have a very portable syntax.

e

Re: [Sml-implementers] Subject: Standard ML

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

Dave Berry wrote:
> 
> Regarding section 4.10, and the exhaustiveness checking of exception
> constructors within functors, I believe that MLWorks does check this when
> the functor is applied.  I don't have an implementation at hand to check
> this, but perhaps you could add this to your test programs?

MLWorks indeed does that. I added a test case "redundant". Still, this
is not something the Definition should enforce, IMHO. It requires a form
of abstract interpretation that seems a bit unreasonable weighed with
the benefits, in particular in the presence of separate compilation. No
other system implements it.

	- Andreas

Re: [Sml-implementers] compilation management

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

Dave Berry wrote:
> 
> One thing to consider is whether to provide any support for directories in
> the file paths.  If so, then either we need a convention for directory
> syntax, or people may have to rewrite their project files when they move
> between OSs.  (Although I believe Windows now recognises Unix-style
> directory syntax -- i.e forward slash).  If we do adopt such a convention,
> then we are already part way to limiting the names that can appear.

Why not adopt an existing standard and use (a subset of) URI path
syntax? It is well-known, more or less system independent, and
expressive enough - and pleasently close to Unix syntax. Every OS
already has conventions to map it down to native paths.

	- Andreas