|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |