On 2006 mei 30, at 17:33, Brian Hulley wrote:
But the buffer will nearly always be incomplete as you're editing it.
I was kind of hoping that the syntax of Haskell could be changed so
that for
any sequence of characters there would be a unique parse that had a
minimum
number of "gaps" inserted by the editor to create a complete parse
tree, and
moreover that this parse could be found by deterministic LL1 recursive
descent.
If you use my parsercombinators, and are willing to work on the
grammar I think this can in principle be done. The combinators
automatically "correct" incorrect (i.e. in this case incomplete)
input, but:
- you may really need some time to tune the grammar so the
corrections are what a user might expect (there are many hooks for
doing so, but it will takje some effort, since this s also a human
interface issue)
- making a Haskell grammar that parsers top-down is not an easy
task, and making it LL1 is definitely impossible, but also not needed
if you use my combinators
- we could in principle provide you with a complete parser for
Haskell using our combinators that was tested by replacing the GHC
parser with this parser, and that worked (contact [EMAIL PROTECTED] to
get a copy of his code)
- did you think about how to handle the offside rule? If not, the
good news is that we have combinators for that too.
Doaitse Swierstra
Haskell already seems so very close to having this property - its a
real
pity about =>
Not only the =>, but e.g. the commonality between patterns and
expressions makes left factorisation a not so simple task.
The problem is: when Haskell was designed, no one seems to have
thought
about the syntax from the point of view of making it easy to parse or
ensuring that it would have this nice property for editing.
foo :: {SomeClass a} a->a
a Prelude.+ b -- no spaces in the qvarsym
a `Prelude.(+)` b -- a little generalization
a `Prelude.(+) b -- no need for closing `
I would not like an editor that forces me to use a special coding
style (like using brackets where not strictly necessary). Even less
would I like to use one that introduces non-standard syntax.
My humble opinion is that you'll have to bite the bullet and
implement
your syntax recognizer so that it conforms to Haskell'98 (including
the approved addenda) [and addtionally however many of the existing
extensions you'll manage to support]. It may be more difficult but in
the end will also be a lot more useful. And you'll have to find a way
to (unobtrusively!) let the user know whether some piece of code does
not yet have enough context to parse it unambigously.
Thanks for the feedback - I suppose I was being overly optimistic
to think I
could just change the language to suit my editor ;-).
I'll have to find a balance between what I'm able to implement and
what is
specified in Haskell98 (or Haskell' etc) - just as GHCi has done with
qvarsym, and perhaps have different levels of conformance to H98 so
people
could choose their preferred balance between conformity and
instantaneousness of feedback (everything would of course still be
loaded/saved as H98).
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
