Things and limitations...
Juan Carlos Arevalo Baeza
jcab@roningames.com
Mon, 14 May 2001 22:46:24 -0700
At 04:50 PM 5/15/2001 +1200, Tom Pledger wrote:
>I did something similar recently, but took the approach of adding more
>parameters to newtype Parser, rather than converting it into a class.
Yes, that's how I started.
>You could try something similar for your generalisations:
>
> newtype Parser ct r = P (ct -> [(r, ct)])
> -- ct: collection of tokens, r: result
This is EXACTLY how I started :)
> instance SuitableCollection ct => Monad (Parser ct)
> where ...
>
> instance SuitableCollection ct => MonadPlus (Parser ct)
> where ...
>
> item :: Collects ct t => Parser ct t
> force :: Parser ct r -> Parser ct r
> first :: Parser ct r -> Parser ct r
> papply :: Parser ct r -> ct -> [(r, ct)]
>
>The `SuitableCollection' class is pretty hard to define, though.
>Either it constrains its members to be list-shaped, or it prevents you
>from reusing functions like `item'. Hmmm... I think I've just
>stumbled across your reason for treating Parser as a class.
:) Maybe. Thanx for your help, though.
>When the input isn't list-shaped, is the activity still called
>parsing? Or is it a generalised fold (of the input type) and unfold
>(of the result type)?
Actually, I guess you can call it destructive pattern-matching.
Salutaciones,
JCAB
---------------------------------------------------------------------
Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com
Senior Technology programmer | mailto:jcab@roningames.com
Ronin Entertainment | ICQ: 10913692
(my opinions are only mine)
JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html