posted by lucjansz

posted by AliPang

In the book Hutton didn't explain why he chose List instead of the Maybe type. I'm glad you touch that subject in the lecture.

posted by paks8150

In the ideal world we want to have lists as a generalization of Maybe but we don't want to loose the type safety that Maybe offers.

This problem is complete Deja Vu for me: I encountered the same tension between the option type and the list type in an attempt to implement a lazy functional L-system library in haXe back in 2007.

Thanks for the "epic fail" parser, haha.

Deja Vu again! Brian Beckman repeated this so many times it was burned into my memory: the state monad is a function from state to state contents pair. This looks exactly as what we see here: you start with a string and get back a string and a tree.

Erik, why do you not like the layout rule in this case and use explicit delineation. I don't think you mention this.

This whole parsing business is reminiscent of unfolding. Expansion of some input into a more complex form. Composition, application and unfolding, hmm...

posted by exoteric

posted by naasking

posted by exoteric

Perhaps like exoteric, I felt a little dissatisfied with the return type of Parser being "list of..." rather than "Maybe...". I've come to admire the expressive power of Haskell types and this seems like a bit of a hack. Considering, as you pointed out, that both the list and Maybe types comprise Monads, I am wondering where the advantage exists for using the list type. Monads allow for map, filter, lift operations, no?

posted by dpratt71

I don't own Hutton's book, but I can think of a few reasons for not using Maybe. It would require introducing a new datatype to the reader, while the reader is already familiar with the list type. Also, it takes more characters to write when pattern matching on a Maybe value .

Now, in a real project you'd use the appropiate data type. If you know that at most only a single answer will be produced, use Maybe.

posted by ShinNoNoir

There must be a way to use the same list abstraction, only constrained to apply to [n,m] elements. Such value-restrictions upheld by a type system appear to be what dependent typing does. This provides a new expressive dimension which is missing in order to type programs correctly without also loosing the abstraction provided by lists over options. The ideal must be a way to fluently move from intensional to extensional semantics by explicitly coercing a type into the extensional domain of structural compatibility.

It also reminds me of template metaprogramming. Someone built a compile-time regexp module in D and there's also a compile-time raytracer in D. In the last case you may discuss the applicability of that but at least it shows the expressive power.

http://www.digitalmars.com/d/2.0/templates-revisited.html

Now time to play with parsers in C# using LINQ...

posted by exoteric

I can certainly see that:

parse p "something"

is preferable to

p "something"

However, to me it seems that it makes semantics exlicit rather than type conversion.

Erik hardly seems more likely to be confused here than I am, so I think I'm missing some fundamental alternative way of viewing this.

As I'm writing this I think I'm starting to get it. Using parse makes it explicit that p is a parser. Since applying a parser to a value always returns a value with a type that has the same relationship to the input value's type, using parse makes both the semantics and the type conversions explicit.

Am I understanding this correctly?

If not, I'd appreciate it if someone could expand upon Erik's statements.

posted by Magnus Lidbom

posted by head.in.the.box

type Parser a = String -> [(a,String)]

item :: Parser Char
item = \inp -> case inp of
               []     -> []
               (x:xs) -> [(x,xs)]
              
return' :: a -> Parser a
return' v = \inp -> [(v,inp)]

p' :: Parser (Char,Char)
p' = do x <- item
            z <- item
            y <- item
            return' (x,y)

It gives the following error:

posted by leomm

posted by zurk

One of the links is this: http://www.comlab.ox.ac.uk/people/Richard.Bird/index.html

Another one is this: http://portal.acm.org/portal.cfm?coll=GUIDE&dl=GUIDE&CFID=63594272&CFTOKEN=61762843

Regards

posted by leomm

C

posted by Charles

Regards

posted by leomm

2) Extend the parser for arithmetic expressions to support substraction and
   division, based upon the following extensions to the grammar:
        
        expr ::= term (+ expr | - expr | e)
        term ::= factor (* term | / term | e)

expr' :: Parser Int expr' = do t <- term' do symbol "+" e <- expr' return (t + e) +++ do symbol "-" e <- expr' return (t - e) +++ return t term' :: Parser Int term' = do f <- factor' do symbol "*" t <- term' return (f * t) +++ do symbol
 "/" e <- expr' return (f `div` e) +++ return f factor' :: Parser Int factor' = do symbol "(" e <- expr' symbol ")" return e +++ natural eval' :: String -> Int eval' xs = case parse expr' xs of [(n,[])] -> n [(_,out)] -> error ("unused input " ++ out) [] ->
 error "invalid input" 

posted by paks8150

posted by rehaskell9

posted by siryc

His name is Gilad Bracha. His blog is http://gbracha.blogspot.com/ 

You can also watch him on C9: http://channel9.msdn.com/tags/Gilad+Bracha

C

posted by Charles

posted by Sachin

posted by David