>> However, in Haskell, if I write
>>
>>   foo = if x
>>           then y
>>           else z
>>
>> that's different to
>>
>>   foo =
>>     if x
>>       then y
>>       else z
>>
>> To parse the "then" part, you *must* know how far the "if" part is 
>> indented. 
> 
> You only need to know if it's indented less, the same, or more than foo, 
> right?

Yeah.

> In which case you have three tokens.  indent, outdent, and dent.

The above expressions use the "layout rule". You can, however, write 
Haskell code where whitespace is not significant. (At least, not 
significant in the same way it's not significant in Pascal; it still 
delimits tokens, etc.) According to the language spec, Haskell with 
layout can be transformed into Haskell without layout.

For example,

   foo x =
     case x of
       1 -> "one"
       2 -> "two"
       3 -> "three"

would become

   foo x = case x of {1 -> "one"; 2 -> "two"; 3 -> "three"}

I think perhaps the best thing would be to perform this transformation 
first, and only then attempt to do the actual parsing. The explicitly 
delimited stuff looks a damn site easier to parse.

Of course, the fun part is now trying to relate the location of any 
parse errors back to the original source code. Indeed, with everything 
I've done so far, it seems that making it *work* is relatively easy, but 
making it give useful error messages if the user makes a mistake is 
drastically harder.

(Want to type-check something? That's easy. Just unify a few terms. 
What, it doesn't unify, and you want to know where the error is? Uh... 
good luck with that.)

>> Well, you can totally tokenise the input without knowing anything 
>> about what user-defined operators exist. (There are rules about what 
>> characters you may use.) But it seems that you can't build a correct 
>> parse tree until you know the operator precedences, so...
> 
> And you can find the definitions without knowing the precidences, right? 
> You can distinguish between definitions that use user-defined operators 
> and those which don't?

Technically *all* operators are user-defined. (The only exception is the 
list syntax, which - for reasons unknown - is hard-wired into the 
language.) But sure, you need to hunt down the various definitions for 
parsing, type checking, execution... whatever it is you want to do. It's 
just a question of how your particular tool does it.

The only significant point is that this prevents you writing a 
stand-alone Haskell parser; it can't be done. You can't parse Haskell 
without comprehending it.

Post a reply to this message