[clean-list] Parser, why three type variables

[zuurb078 at planet.nl]

Hi,
So sorry for the noise I emitted. I should have said that I only need two *continuations* instead of three. I don't need the XOR-continuation. Taking that out is not trivial for me. But all of this is irrelevant to Carlos' question.
Erik

________________________________

Van: Pieter Koopman [mailto:pieter at cs.ru.nl]
Verzonden: di 6-5-2008 12:00
Aan: zuurb078 at planet.nl
CC: Carlos Aya; clean-list at science.ru.nl
Onderwerp: Re: [clean-list] Parser, why three type variables



Hi,

my parser library has parsers with 3 type parameters: Parser s r t.
s is the type of the symbols parsed (the tokens)
r is the result of this parser. The type r can be identical to s (for
instance for the combinator symbol), but often is it a (part of) syntax tree
t is the final result. Rather than constructing some intermediate data
type, my parser combinators use continuations to handle the parser
results. The success continuation transforms the parse results of type r
to elements of type t. Basically the success continuation acts like a
function of type r->t.
That is the reason I needed those 3 type arguments, see
http://www.st.cs.ru.nl/papers/1999/koop98-EffCombParsIFL98.ps.gz for
details.

Hope this helps,

Pieter Koopman

Erik Zuurbier wrote:
> Carlos,
>
> I wrote those parser combinators based on Pieter Koopman's work with
> only two type parameters. Pieter also has a version with three type
> parameters, necessary for the XOR-combinator and the way he improved
> the library's efficiency. I did not like that approach and found a
> different way. See the help file that comes with the library.
>
> But after that Pieter found a bug that appeared in both of his
> libraries but solved it only for his 3-parameter library. I could not
> solve it for the 2-parameter library so I reworked my parser library
> based on his improved 3-parameter library.
>
> It is true, the parser library that emits error messages does not need
> the third parameter, but to my opinion it is not trivial to take it
> out. Hope Pieter reads this and will once find the time to debug his
> 2-parameter library as well, after which I can base the error-message
> emitting library on it.
>
> Regards
> Erik Zuurbier
> ----- Original Message ----- From: "Carlos Aya" <carlosayam at yahoo.com.au>
> To: <clean-list at science.ru.nl>
> Sent: Sunday, May 04, 2008 5:48 AM
> Subject: [clean-list] Parser, why three type variables
>
>
>> Hello,
>>
>> In the parsers library one finds...
>>
>> :: Parser s r t
>>
>> and
>>
>> parse :: !(Parser s r r) [s] String String -> Result r
>>
>> Still not clear for me, from a software design point of view, why
>> three type variables in 'Parse' if 'parse' use only 2 in the type?
>> Why we want the type engine to have that free 't' around? I saw the
>> combinators and none of them touch it... hope I didn't overlooked
>> something... any help appreciated.
>>
>> regards
>> Carlos
>>
>>
>>
>>      Get the name you always wanted with the new y7mail email address.
>> www.yahoo7.com.au/y7mail
>>
>>
>>
>> _______________________________________________
>> clean-list mailing list
>> clean-list at science.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/clean-list
>
> _______________________________________________
> clean-list mailing list
> clean-list at science.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/clean-list


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.science.ru.nl/pipermail/clean-list/attachments/20080506/9e43aead/attachment.html