[Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Paul Keir
Hi,

 

I'm having some difficulty using the Parsec library, perhaps you could
help. I've reduced my problem as shown below. I would like the
'only_prod' parser to require the reserved string only, _optionally_
followed by an identifier. As part of 'mytest', this should then be
followed by the reserved string end.

 

mytest = do { only_prod; end }

only_prod = do { reserved only; try identifier }

end = reserved end

 

i.e. I'd like both

 parseTest mytest only end

and

parseTest mytest only green end

to parse successfully. As it stands, only the second is successful. The
first fails with:

 

parse error at (line 1, column 9):

unexpected end of input

expecting letter or digit or end

 

Does anyone have an idea how I could repair the situation?

 

Thanks in advance,

Paul

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Albert Y. C. Lai

Paul Keir wrote:
I’m having some difficulty using the Parsec library, perhaps you could 
help. I’ve reduced my problem as shown below. I would like the 
‘only_prod’ parser to require the reserved string “only”, _optionally_ 
followed by an identifier. As part of ‘mytest’, this should then be 
followed by the reserved string “end”.


Look into option, optional, and optionMaybe.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Derek Elkins
On Tue, 2008-03-25 at 11:47 -0400, Albert Y. C. Lai wrote:
 Paul Keir wrote:
  I’m having some difficulty using the Parsec library, perhaps you could 
  help. I’ve reduced my problem as shown below. I would like the 
  ‘only_prod’ parser to require the reserved string “only”, _optionally_ 
  followed by an identifier. As part of ‘mytest’, this should then be 
  followed by the reserved string “end”.
 
 Look into option, optional, and optionMaybe.

And in particular, try doesn't do what you (Paul) think it does.  try
however is a rather important combinator of Parsec so I would behoove
you to look up it's documentation and the explanations of it in the
Parsec letter.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Paul Keir
Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but in any case, 
defining my only_prod as

only_prod = do { reserved only; option [] identifier }

or

only_prod = do { reserved only; identifier | return [] }

gives the same error responses as before. I will anyway look closer at option.

You're right that I don't understand try, but it's not for lack of trying. My 
examples' use of try though was just a stab at a readable failure. Maybe I 
should refactor my example.

Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Brandon S. Allbery KF8NH


On Mar 25, 2008, at 12:43 , Paul Keir wrote:
Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but  
in any case, defining my only_prod as


only_prod = do { reserved only; option [] identifier }

or

only_prod = do { reserved only; identifier | return [] }

gives the same error responses as before. I will anyway look closer  
at option.


The other problem here is that just using a given string in  
reserved doesn't prevent it from being parsed elsewhere by  
identifier.  (Note the character offset of the error was 9, i.e.  
just past only end, and it was looking for end or more identifier  
characters.)


Are you using the higher level parser facilities from  
Text.ParserCombinators.Parsec.Token, or rolling your own?  If the  
latter, you will need to modify identifier to not accept keywords.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Paul Keir
Thankyou. Yes, I'd also noticed that only end could result in the end part 
being taken as an identifier. The language I'm parsing actually doesn't have 
reserved words though; so end and only are both possible valid identifiers. 
I should then probably replace my use of say, reserved only, with string 
only; whiteSpace; for clarity. Still stuck though...

P


-Original Message-
From: Brandon S. Allbery KF8NH [mailto:[EMAIL PROTECTED]
Sent: Tue 25/03/2008 19:58
To: Paul Keir; haskell-cafe@haskell.org Cafe
Subject: Re: [Haskell-cafe] Parsec (Zero or One of)
 

On Mar 25, 2008, at 12:43 , Paul Keir wrote:
 Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but  
 in any case, defining my only_prod as

 only_prod = do { reserved only; option [] identifier }

 or

 only_prod = do { reserved only; identifier | return [] }

 gives the same error responses as before. I will anyway look closer  
 at option.

The other problem here is that just using a given string in  
reserved doesn't prevent it from being parsed elsewhere by  
identifier.  (Note the character offset of the error was 9, i.e.  
just past only end, and it was looking for end or more identifier  
characters.)

Are you using the higher level parser facilities from  
Text.ParserCombinators.Parsec.Token, or rolling your own?  If the  
latter, you will need to modify identifier to not accept keywords.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Brandon S. Allbery KF8NH


On Mar 25, 2008, at 16:26 , Paul Keir wrote:
Thankyou. Yes, I'd also noticed that only end could result in the  
end part being taken as an identifier. The language I'm parsing  
actually doesn't have reserved words though; so end and only  
are both possible valid identifiers. I should then probably replace  
my use of say, reserved only, with string only; whiteSpace; for  
clarity. Still stuck though...





But now you have an ambiguity in your language, which is exactly why  
the parse is failing:  only end could be waiting for end, or for  
end of file / whatever tokens might follow this clause.  In the worst  
case, the latter might lead to a situation where an unambiguous parse  
is impossible.


You might want to provide a better description of the full language  
--- and think about how it would need to be implemented to avoid  
ambiguity.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: [Haskell-cafe] Parsec (Zero or One of)

2008-03-25 Thread Paul Keir
Many thanks.

-Original Message-
From: Brandon S. Allbery KF8NH [mailto:[EMAIL PROTECTED]
Sent: Tue 25/03/2008 20:29
To: Paul Keir; haskell-cafe@haskell.org Cafe
Subject: Re: [Haskell-cafe] Parsec (Zero or One of)
 

On Mar 25, 2008, at 16:26 , Paul Keir wrote:
 Thankyou. Yes, I'd also noticed that only end could result in the  
 end part being taken as an identifier. The language I'm parsing  
 actually doesn't have reserved words though; so end and only  
 are both possible valid identifiers. I should then probably replace  
 my use of say, reserved only, with string only; whiteSpace; for  
 clarity. Still stuck though...



But now you have an ambiguity in your language, which is exactly why  
the parse is failing:  only end could be waiting for end, or for  
end of file / whatever tokens might follow this clause.  In the worst  
case, the latter might lead to a situation where an unambiguous parse  
is impossible.

You might want to provide a better description of the full language  
--- and think about how it would need to be implemented to avoid  
ambiguity.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe