[MLton-devel] bug with longid?
Stephen Weeks
MLton@mlton.org
Tue, 11 Mar 2003 18:47:39 -0800
> Do you guys mean to not accept long identifiers with whitespace, ie,
>
> List . map
>
> ?
>
> The Definition seems ambiguous about this (note the definition of 'xseq'
> in 2.8 also does not show spaces), but SML/NJ allows it. I'm not sure if
> this was intended or not...
Yes, we mean to treat "List . map" as three lexical items. I believe
only SML/NJ of all the SML compilers accepts it. We had an email
discussion with the SML/NJ guys a couple of years ago in which they
agreed with us and said they would like to change SML/NJ. Here was my
argument that convinced them:
Section 2.5 says "each item of lexical analysis is a either a
reserved word, a numeric label, a special constant, or a long
identifier" and "Comments and formatting characters separate items
... and are otherwise ignored". Together, I take these to mean that
spaces separate "S . x" into three items of lexical analysis.
Anyways, as you can see, SML/NJ hasn't yet changed.
Here's the email exchange from a couple of years ago:
> From: "Stephen Weeks" <sweeks@intertrust.com>
> To: sml-bugs@research.bell-labs.com
> Date: Fri, 23 Feb 2001 14:24:51 -0800 (PST)
> Subject: spaces in long identifiers
>
> Number: *
> Title: spaces in long identifiers
> Keywords:
> Submitter: Stephen Weeks <sweeks@acm.org>
> Date: 02/23/01
> Version: 110.30
> System: x86-linux
> Severity:
> Problem:
>
> SML/NJ accepts spaces around the "." in long identifiers. It is not clear
> whether the standard allows this. MLton, the ML Kit and Moscow ML all reject
> it.
>
> Code:
>
> structure S = struct val x = 13 end;
> val x = S . x
>
> Transcript:
> Comments:
> Fix:
> Test: *
> Owner: *
> Status: *
>
> --------------------------------------------------------------------------------
>
> From: Dave MacQueen <dbm@research.bell-labs.com>
> To: "Stephn T. Weeks" <sweeks@intertrust.com>
> Date: Fri, 23 Feb 2001 18:00:14 -0500
> Subject: Re: spaces in long identifiers
>
> It is debatable whether this is a bug. As far as I can tell, the Defn
> does not specify whether spaces are allowed around the dots in long
> identifiers (Section 2.4, Identifiers). A restriction that is not
> implied or required by the definition might be considered a bug, but
> really we should decide on a common treatment. Do you have arguments
> in favor of the "no spaces allowed" policy, or is it just following
> the convention of other languages (which might be a good enough
> argument).
>
> Dave
>
> --------------------------------------------------------------------------------
>
> From: "Stephen Weeks" <sweeks@intertrust.com>
> To: sml-bugs@research.bell-labs.com
> Date: Fri, 23 Feb 2001 17:56:41 -0800 (PST)
> Subject: Re: spaces in long identifiers
>
> > It is debatable whether this is a bug. As far as I can tell, the Defn
> > does not specify whether spaces are allowed around the dots in long
> > identifiers (Section 2.4, Identifiers). A restriction that is not
> > implied or required by the definition might be considered a bug, but
> > really we should decide on a common tretment. Do you have arguments
> > in favor of the "no spaces allowed" policy, or is it just following
> > the convention of other languages (which might be a good enough
> > argument).
>
> I don't have much of an argument. Section 2.5 says "each item of lexical
> analysis is a either a reserved word, a numeric label, a special constant, or a
> long identifier" and "Comments and formatting characters separate items ... and
> are otherwise ignored". Together, I take these to mean that spaces separate
> "S . x" into three items of lexical analysis.
>
> --------------------------------------------------------------------------------
>
> From: "John H. Reppy" <jhr@research.bell-labs.com>
> To: "Stehen T. Weeks" <sweeks@intertrust.com>
> Date: Sat, 24 Feb 2001 15:38:37 -0500
> Subject: Re: spaces in long identifiers
>
> I would agree with Stephen. My reading of 2.4 and 2.5 is that white
> space characters (aka formatting characters) are allowed between lexical
> items, but the "." in a long identifier is clearly not an independent
> lexical item.
>
> - John
>
> --------------------------------------------------------------------------------
>
> From: Dave MacQueen <dbm@research.bell-labs.com>
> To: "Stephn T. Weeks" <sweeks@intertrust.com>
> Date: Mon, 26 Feb 2001 09:54:02 -0500
> Subject: Re: spaces in long identifiers
>
> > From: "Stephen Weeks" <sweeks@intertrust.com>
> > To: sml-bugs@research.bell-labs.com
> > Date: Fri, 23 Feb 2001 17:56:41 PST
> > Subject: Re: spaces in long identifiers
>
> >
> > > It is debatable whether this is a bug. As far as I can tell, the Defn
> > > does not specify whether spaces are allowed around the dots in long
> > > identifiers (Section 2.4, Identifiers). A restriction that is not
> > > implied or required by the definition might be considered a bug, but
> > > really we should decide on a common treatment. Do you have arguments
> > > in favor of the "no spaces allowed" policy, or is it just following
> > > the convention of other languages (which might be a good enough> > argument).
> >
> > I don't have much of an argument. Section 2.5 says "each item of lexical
> > analysis is a either a reserved word, a numeric label, a special constant, or
> > a
> > long identifier" and "Comments and formatting characters separate items ... a
> > nd
> > are otherwise ignored". Together, I take these to mean that spaces separate
> > "S . x" into three items of lexical analysis.
>
> I guess that is a fairly reasonable interpretation. I think that it
> would be good to make SML/NJ consistent with MLton and Moscow ML on
> this point.
>
> Dave
>
> --------------------------------------------------------------------------------
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel