On Tuesday 30 May 2006 20:59, Brian Hulley wrote:
It is quite a tall order to provide immediate typed feedback of an edit buffer that will in general be syntactically incomplete but this is my eventual aim.
One issue in the area of immediate feedback is that Haskell's syntax is troublesome in a few areas. Consider:
foo :: SomeClass a => a -> a
when the user has just typed:
foo :: SomeClass a
should the editor assume SomeClass is a Tycon or a class name?
If SomeClass has been defined somewhere (in the same buffer or in some imported module), the editor will know whether it is a class or a type and can react accordingly (e.g. propose to insert '=>' or use a special color for 'SomeClass'). If not, then the editor should remain agnostic. What is the problem here? No user will expect the editor to unambigously parse /incomplete/ code, or will they?
One idea I had to solve this problem was to change the syntax of Haskell slightly so that constraints would be enclosed in {} instead of preceeding => ie:
foo :: {SomeClass a} a->a
so that in
foo :: {SomeClass
it is already determined that SomeClass must be a class name.
Another thing which causes difficulty is the use of qualified operators, and the fact that the qualification syntax is in the context free grammar instead of being kept in the lexical syntax (where I think it belongs). For example, afaiu according to H98 (but not GHCi) it is permissible to write:
a Prelude . + b
-- qvarsym -> [ modid . ] varsym
whereas in my prototype I put all this into a level immediately above the lexer but below the CFG so that no spaces are allowed thus:
a Prelude.+ b -- no spaces in the qvarsym a `Prelude.(+)` b -- a little generalization a `Prelude.(+) b -- no need for closing `
(The generalization above is intended for when you don't know whether or not the function you're qualifying has been declared as an operator but you want to use it as an operator eg if a pop-up list would appear after you typed `Prelude. with entries such as (+) plus add etc)
With the above changes, it is possible to parse Haskell (or at least as much as I got round to implementing in my C++ prototype) using a simple deterministic recursive descent parser with only 1 token of lookahead.
(There is possibly some confusion in the H98 report about exactly how ambiguous expressions involving typed case alternatives might be parsed eg x
:: a->b -> if x 4 then ... but I'm hoping it will be ok to just fix :: the
syntax here by requiring extra brackets)
Anyway I suppose the point of this post is to see whether or not people feel that such changes are acceptable in an editor, or whether an editor must adhere exactly to the standard (or whether the standard can be changed to enable the determinism and ease of parsing necessary for interactive editing with immediate feedback)?
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. Ben