<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Pieter and Erik,<br><br>Thanks for your reply.<br><br>My question comes from "how to program functional". The examples I've seen about FP look like toy examples for me. I would like to develop a methodology for guiding me writing big FP stuff. In OO, there is the UML and the Design Patterns world and now the Extreme-programming school, etc. How FP fits in this? <br><br>I know I need to make a paradigm shift, but would like to hear from Library developers some practical guides. I'll look into what you just said, thanks!<br><br>Also, it would be nice if Clean has a CleanDoc in next release... having the IDE helping you thru the API with features like 'auto-completion', and, for example type inference as tool-tips
go for a later wish-list ;-)<br><br>Regards<br>Carlos<br>BTW, I'm getting there and I am loving it!<br><br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: "zuurb078@planet.nl" <zuurb078@planet.nl><br>To: Pieter Koopman <pieter@cs.ru.nl><br>Cc: Carlos Aya <carlosayam@yahoo.com.au>; clean-list@science.ru.nl<br>Sent: Wednesday, 7 May, 2008 12:03:54 AM<br>Subject: RE: [clean-list] Parser, why three type variables<br><br><title>Re: [clean-list] Parser, why three type variables</title>
<div id="idOWAReplyText64335" dir="ltr"><div dir="ltr"><font color="#000000" face="Arial" size="2">Hi,</font></div><div dir="ltr"><font color="#000000" face="Arial" size="2">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.</font></div><div dir="ltr"><font face="Arial" size="2">Erik</font></div></div><div dir="ltr"><br><hr tabindex="-1"> <font face="Tahoma" size="2"><b>Van:</b> Pieter Koopman [mailto:pieter@cs.ru.nl]<br><b>Verzonden:</b> di 6-5-2008 12:00<br><b>Aan:</b> zuurb078@planet.nl<br><b>CC:</b> Carlos Aya; clean-list@science.ru.nl<br><b>Onderwerp:</b> Re: [clean-list] Parser, why three type variables<br></font><br></div><div><p><font size="2">Hi,<br><br>my parser library has parsers with 3 type parameters: Parser s r t.<br>s is the type of the symbols parsed (the
tokens)<br>r is the result of this parser. The type r can be identical to s (for<br>instance for the combinator symbol), but often is it a (part of) syntax tree<br>t is the final result. Rather than constructing some intermediate data<br>type, my parser combinators use continuations to handle the parser<br>results. The success continuation transforms the parse results of type r<br>to elements of type t. Basically the success continuation acts like a<br>function of type r->t.<br>That is the reason I needed those 3 type arguments, see<br><a rel="nofollow" target="_blank" href="http://www.st.cs.ru.nl/papers/1999/koop98-EffCombParsIFL98.ps.gz">http://www.st.cs.ru.nl/papers/1999/koop98-EffCombParsIFL98.ps.gz</a> for<br>details.<br><br>Hope this helps,<br><br>Pieter Koopman<br><br>Erik Zuurbier wrote:<br>> Carlos,<br>><br>> I wrote those parser combinators based on Pieter Koopman's work with<br>> only two type parameters. Pieter also has a
version with three type<br>> parameters, necessary for the XOR-combinator and the way he improved<br>> the library's efficiency. I did not like that approach and found a<br>> different way. See the help file that comes with the library.<br>><br>> But after that Pieter found a bug that appeared in both of his<br>> libraries but solved it only for his 3-parameter library. I could not<br>> solve it for the 2-parameter library so I reworked my parser library<br>> based on his improved 3-parameter library.<br>><br>> It is true, the parser library that emits error messages does not need<br>> the third parameter, but to my opinion it is not trivial to take it<br>> out. Hope Pieter reads this and will once find the time to debug his<br>> 2-parameter library as well, after which I can base the error-message<br>> emitting library on it.<br>><br>> Regards<br>> Erik Zuurbier<br>> ----- Original Message -----
From: "Carlos Aya" <carlosayam@yahoo.com.au><br>> To: <clean-list@science.ru.nl><br>> Sent: Sunday, May 04, 2008 5:48 AM<br>> Subject: [clean-list] Parser, why three type variables<br>><br>><br>>> Hello,<br>>><br>>> In the parsers library one finds...<br>>><br>>> :: Parser s r t<br>>><br>>> and<br>>><br>>> parse :: !(Parser s r r) [s] String String -> Result r<br>>><br>>> Still not clear for me, from a software design point of view, why<br>>> three type variables in 'Parse' if 'parse' use only 2 in the type?<br>>> Why we want the type engine to have that free 't' around? I saw the<br>>> combinators and none of them touch it... hope I didn't overlooked<br>>> something... any help appreciated.<br>>><br>>> regards<br>>> Carlos<br>>><br>>><br>>><br>>> Get the name you
always wanted with the new y7mail email address.<br>>> www.yahoo7.com.au/y7mail<br>>><br>>><br>>><br>>> _______________________________________________<br>>> clean-list mailing list<br>>> clean-list@science.ru.nl<br>>> <a rel="nofollow" target="_blank" href="http://mailman.science.ru.nl/mailman/listinfo/clean-list">http://mailman.science.ru.nl/mailman/listinfo/clean-list</a><br>><br>> _______________________________________________<br>> clean-list mailing list<br>> clean-list@science.ru.nl<br>> <a rel="nofollow" target="_blank" href="http://mailman.science.ru.nl/mailman/listinfo/clean-list">http://mailman.science.ru.nl/mailman/listinfo/clean-list</a><br></font></p></div></div></div></div><br>
<hr size=1>
Get the name you always wanted with the <a href="http://au.rd.yahoo.com/mail/taglines/au/y7mail/default/*http://au.yahoo.com/y7mail/?p1=ni&p2=general&p3=tagline&p4=other" target=_blank>new y7mail email address</a>.
</body></html>