|
![](/i/fill.gif) |
Tim Attwood wrote:
> Interesting, maybe you should clean it up and publish it under your
> real name, maybe somewhere like the Monad.Reader or some such.
> It certainly wouldn't hurt to share some of your technical musings with
> a larger audience of functional programmers.
Well, that's vaguely my idea. It's part of a sequence of "portfolio"
documents I'm writing, in case I need to show somebody some day what my
writing skills are like. (Most of my documents never get finished.
Except the ones at work - which, obviously, I can't show to anybody.)
I think the Monad.Reader would be the wrong place though; combinator
libraries ARE very well known within the FP community. It's the people
outside that it's going to be new to. (I'm not sure where *would* be an
appropriate place to publish it though.)
> In general I prefer a top down approach to learning, but the
> bottom up pattern you are following is frequently used in
> academia.
I'm not even sure how you'd explain Parsec from the top down. The whole
design of the system is that you build parsers in a bottom-up style, so
that seems a logical way to describe it.
> Maybe you should mention buildExpressionParser
> and makeTokenParser?
I already mentioned buildExpressionParser. (Top of page 9.) I merely
didn't refer to it by name.
The aim of the document is not to be a reference manual for Parsec (I
mean, I've changed all the function names and the entire syntax for
starters!), but to give OOP enthusiasts a taste of how Parsec does
things. Knowing that you can feed a datastructure into a library
function and have it construct your parser for you is sufficient, IMHO.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |