Re: H98 Report: expression syntax glitch
On Tue, Feb 26, 2002 at 08:23:03AM -0800, Simon Peyton-Jones wrote:
> I didn't phrase it right. I meant that a let/lambda/if always
> extends to the next relevant (not part of a smaller expression)
> punctuation symbol; and if that phrase parses as an exp
> that's fine, otherwise it's a parse error. So I should not really
> speak in terms of 'ambiguity'.
>
> Perhaps we can simply say that
> let .. in exp
> is legal only if the phrase is followed by one of the punctuation
> symbols. That's nice, because we don't need to talk of
> "not part of a smaller expression".
OK, so you have a context-free grammar qualified by a rule forbidding
some of the derivations of that grammar.
Another solution would be to subdivide exp^10 using a superscript I've
called A or B from lack of imagination:
exp10A -> \ apat[1] ... apat[n] -> exp (lambda abstraction, n>=1)
| let decls in exp (let expression)
| if exp then exp else exp (conditional)
exp10B -> case exp of { alts } (case expression)
| do { stmts } (do expression)
| fexp
Only the latter sort can be followed by infix operators or type signatures.
We could extend the distinction to the exp^i (here x ranges over {A,B}):
exp -> exp0B :: [context =>] type(expression type signature)
| exp0
expi -> expiA
| expiB
expix -> expi+1B [qop(n,i) expi+1x]
| lexpix
| rexpix
lexpix -> (lexpiB | expi+1B) qop(l,i) expi+1x
lexp6x -> - exp7x
rexpix -> expi+1B qop(r,i) (rexpix | expi+1x)
and the rules for sections would be
aexp -> ...
| ( expi+1B qop(a,i) ) (left section)
| ( qop(a,i) expi+1 ) (right section)
It's complicated, but it does at least specify precisely the language
and parses we want in a single context-free description.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Get paid cash every time you receive email!
Earn a dime every time you receive email! Sign up FREE at: Here ¡¡===¸ÃÓʼþʹÓà ¿ÆÌØÓʼþȺ·¢Èí¼þ ·¢ËÍ,ÓʼþÄÚÈÝÓë¿ÆÌØÈí¼þÎ޹ؿÆÌØÈí¼þ http://www.caretop.com=== ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: H98 Report: expression syntax glitch
I'm inclined to stay with the formulation as a side condition,
assuming you all think it's correct.
Filling it out as a complete context free grammar as you suggest
looks complex. That makes it easy to introduce new errors. And
in fact the meta-rule can be implemented by simply telling the
parser to resolve shift/reduce errors by shifting. So the extra
complexity in the grammar is not mirrored in the implementation.
So I propose to say that 'let', 'lambda' and 'if' productions have
a side condition that (say)
let .. in exp
is syntactially valid only if the phrase is followed by one of the
punctuation symbols
) ] } | ; , .. where of then else
Any objectors? Myself I think this is way better than "leftwards
precedence" and "rightwards precedence", which I never did
understand
Simon
| -Original Message-
| From: Ross Paterson [mailto:[EMAIL PROTECTED]]
| Sent: 27 February 2002 10:43
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: Re: H98 Report: expression syntax glitch
|
|
| On Tue, Feb 26, 2002 at 08:23:03AM -0800, Simon Peyton-Jones wrote:
| > I didn't phrase it right. I meant that a let/lambda/if always
| > extends to the next relevant (not part of a smaller expression)
| > punctuation symbol; and if that phrase parses as an exp
| that's fine,
| > otherwise it's a parse error. So I should not really speak
| in terms
| > of 'ambiguity'.
| >
| > Perhaps we can simply say that
| > let .. in exp
| > is legal only if the phrase is followed by one of the punctuation
| > symbols. That's nice, because we don't need to talk of
| "not part of a
| > smaller expression".
|
| OK, so you have a context-free grammar qualified by a rule
| forbidding some of the derivations of that grammar.
|
| Another solution would be to subdivide exp^10 using a
| superscript I've called A or B from lack of imagination:
|
|exp10A -> \ apat[1] ... apat[n] -> exp (lambda
| abstraction, n>=1)
|| let decls in exp (let expression)
|| if exp then exp else exp (conditional)
|exp10B -> case exp of { alts } (case expression)
|| do { stmts } (do expression)
|| fexp
|
| Only the latter sort can be followed by infix operators or
| type signatures. We could extend the distinction to the exp^i
| (here x ranges over {A,B}):
|
|exp -> exp0B :: [context =>] type (expression
| type signature)
| | exp0
|expi -> expiA
| | expiB
|expix -> expi+1B [qop(n,i) expi+1x]
| | lexpix
| | rexpix
|lexpix -> (lexpiB | expi+1B) qop(l,i) expi+1x
|lexp6x -> - exp7x
|rexpix -> expi+1B qop(r,i) (rexpix | expi+1x)
|
| and the rules for sections would be
|
|aexp -> ...
| | ( expi+1B qop(a,i) ) (left section)
| | ( qop(a,i) expi+1 )(right section)
|
| It's complicated, but it does at least specify precisely the
| language and parses we want in a single context-free description.
|
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: java program
On Tue, 26 Feb 2002, Peter White wrote: > Since you did not mention the name of your professor, I have forwarded your > query to both the undergraduate and graduate secretaries at the University > of Manchester. I am sure they will be able to deal more effectively with > your homework and your complaints than I can. I am sorry to hear that you > find yourself embarrassed. You can thank me for my help when you have the > time. Though, of course, sending to Manchester Metropolitan University, might have had a slightly greater effect! www.mmu.ac.uk is probably what you'd want. David Lester, Manchester University. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: H98 Report: expression syntax glitch
On Wed, Feb 27, 2002 at 04:00:39PM +0100, Arthur Baars wrote: > In the context-free grammar proposed by Ross Paterson > the following line: > expix -> expi+1B [qop(n,i) expi+1x] > > should be replaced by > expix -> [expi+1B qop(n,i)] expi+1x Yes. (In fact that's what I had in the revised hssource grammar, but I mistranscribed it.) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Behavior of fromInteger on out-of-range arguments
Dean Herrington wrote > It seems to me that the behavior for `(fromInteger x)::Int`, where x is > an Integer outside Int range, should be the same (in terms of the > Haskell report) as that for `y + y`, where y is an Int such that > `toInteger y + toInteger y` is outside Int range. I agree almost entirely. Note that Haskell 98 does not define what happens on overflow (section 6.4). Personally my preference would be for making overflowing operations on Ints cause an error, and on Words wrap, as happens with SML. I think GHC just wraps everything. There is one exception though. According to section 6.4.1 a numeric literal should be interpreted as "the application of the function fromInteger to the appropriate value of type Integer". In my opinion a numeric literal in an exact type (such as Int or Ratio Int) which does not fit in the target representation should ALWAYS raise an error, either at run-time or compile-time, since I can conceive of no conceivable use for typing such a literal, and so it is almost certainly a user error. (The situation is different for inexact types such as Float, since it is understood that say a literal like 0.1 may not be exactly representable, and there is no other convenient way of typing it.) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
library design conventions
it says:
> A function or action taking a some kind of state and returning a pair
> consisting of a result and a new state, the result is the first element
> of the pair and the new state is the second, see e.g. Random.
unfortunatly, Random and the mapAccum{RL} functions don't agree at
all. the accumulating map functions assume the state is in the first
element and the new element is in the second, but random doesn't behave
this way and it appears neither do the libraries.
am i the only one bothered by this? i would prefer if at least the
libraries would change and put the state in the first position of the
pair. it's probably hopeless to get Random to change at this point, as
with the mapAccum functions.
- Hal
--
Hal Daume III
"Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: library design conventions
So I just checked and what Java does is it always loads the unqualified
import, so it doesn't do my stuff with automatically adding the package
name to imports, which is reasonable.
--
Hal Daume III
"Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Wed, 27 Feb 2002, Hal Daume III wrote:
> it says:
>
> > A function or action taking a some kind of state and returning a pair
> > consisting of a result and a new state, the result is the first element
> > of the pair and the new state is the second, see e.g. Random.
>
> unfortunatly, Random and the mapAccum{RL} functions don't agree at
> all. the accumulating map functions assume the state is in the first
> element and the new element is in the second, but random doesn't behave
> this way and it appears neither do the libraries.
>
> am i the only one bothered by this? i would prefer if at least the
> libraries would change and put the state in the first position of the
> pair. it's probably hopeless to get Random to change at this point, as
> with the mapAccum functions.
>
> - Hal
>
> --
> Hal Daume III
>
> "Computer science is no more about computers| [EMAIL PROTECTED]
> than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
>
> ___
> Libraries mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/libraries
>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: H98 Report: expression syntax glitch
On Mon, Feb 25, 2002 at 04:30:24PM +, Malcolm Wallace wrote: > > Yes, but it reports type errors for the variants > > f x = (\x -> x*x .) > > g x = (if x then 1 else 2 +) > > and it accepts > > h = (let op x y = y in 3 `op`) > > so I suspect it's misparsing these as > > f x = (\x -> (x*x .)) > > g x = (if x then 1 else (2 +)) > > h = (let op x y = y in (3 `op`)) > > But I would claim that nhc98 is parsing these correctly, at least But, for example, "x*x ." is not a valid left section - parentheses are required. Ian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: H98 Report: expression syntax glitch
On Mon, Feb 25, 2002 at 04:27:56PM -, Simon Marlow wrote: > > This is a known problem with the Haskell grammar. Another example in > a similar vein is > > let x = 3 in x == 4 == True > > which should parse as > > (let x = 3 in x == 4) == True > > according to the "extends as far to the right as possible" rule, > because '==' is nonfix. In order to do this, the parser must have > access to the fixity information for '==', which is unreasonable > (fixity declarations can even be local to a binding group). I'm not sure I agree with you here. By this point we have lexed and applied the layout rule so all the braces and semi-colons are in place. Extracting the fixity information is fairly easy Noticing when operators are redefined (thus dropping fixity information) is slightly trickier but still doable, and then all you have to do is annotate your tree appropriately. Further, if you first construct a tree of blocks then this can all be done in linear time I believe. I don't see that this is a forced change; it seems to be purely to make implementors lives easier (maybe I am just bitter from spending a while thinking about and implementing this myself!) and makes some previously legal scripts illegal. Thanks Ian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
use of undefined type
I'm developing a tool that will help game programmers to develop games in Haskell. To create a game object, the programmer must call the function *object* as follows: object name_of_object position_of_object speed_of_object I would like also to add another param to this function, which type would be anyone defined by the programmer. Unfortunately, as Haskell does not allow things like: type Game = (Name,Position,Speed,t) where t is an undefined type, I'm forced to add "t" to the left side of the type synonym (type Game t = ...). But this is realling doing a mess in my code, since I have to pass this "t" all around. That's why I ask if anyone knows another idea to solve this problem... Thanks a lot, -- Andre W ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: library design conventions
oops! that was supposed to be a follow up to my post about pacakge, not
about this. sorry :)
--
Hal Daume III
"Computer science is no more about computers| [EMAIL PROTECTED]
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Wed, 27 Feb 2002, Hal Daume III wrote:
> So I just checked and what Java does is it always loads the unqualified
> import, so it doesn't do my stuff with automatically adding the package
> name to imports, which is reasonable.
>
> --
> Hal Daume III
>
> "Computer science is no more about computers| [EMAIL PROTECTED]
> than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
>
> On Wed, 27 Feb 2002, Hal Daume III wrote:
>
> > it says:
> >
> > > A function or action taking a some kind of state and returning a pair
> > > consisting of a result and a new state, the result is the first element
> > > of the pair and the new state is the second, see e.g. Random.
> >
> > unfortunatly, Random and the mapAccum{RL} functions don't agree at
> > all. the accumulating map functions assume the state is in the first
> > element and the new element is in the second, but random doesn't behave
> > this way and it appears neither do the libraries.
> >
> > am i the only one bothered by this? i would prefer if at least the
> > libraries would change and put the state in the first position of the
> > pair. it's probably hopeless to get Random to change at this point, as
> > with the mapAccum functions.
> >
> > - Hal
> >
> > --
> > Hal Daume III
> >
> > "Computer science is no more about computers| [EMAIL PROTECTED]
> > than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
> >
> > ___
> > Libraries mailing list
> > [EMAIL PROTECTED]
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
> ___
> Libraries mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/libraries
>
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
