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