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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe