Version française
Home     About     Download     Resources     Contact us    
Browse thread
Patch to 3.10.0 compiler enabling simple spell-checking
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Edgar Friendly <thelema314@g...>
Subject: Re: [Caml-list] Patch to 3.10.0 compiler enabling simple spell-checking
Yitzhak Mandelbaum wrote:
> Very cool! Do you think there's any way you could separate it from the
> compiler, like Learner et al.'s SEMINAL work, which separates type error
> messages from the compiler?. Separation could help ensure this (and any
> other, similar) ideas don't accidentally introduce bugs into the
> compiler, and make it much easier for you to maintain. A very simple
> hack might be tod wrap ocamlc in a script that parses such error
> messages and then tokenizes the source file, looking for similar strings?
> 
> Cheers,
> Yitzhak
> 
Separating it from the compiler would keep from interfering with the
compiler's activities, but it would add some difficulties:

Parsing ocaml - I guess I could steal the parser out of the current
source code, and use the internal parse tree, but it'd be a lot more
difficult than what I've done so far.

Namespaces - Ocaml has a ton of namespaces.  At the moment, the patch
doesn't find mistyped module names, but it does distinguish the
following: type parameters, type constructors, classes, row variables,
values, constructors, labels and instance variables.

Visibilty/scope - A simple script would have to add much complication to
keep track of where each identifier is visible - Maybe easy, maybe not.

Parsing the output of the ocaml compiler - ocamlc lacks i18n to make
this extra difficult, but the error messages don't follow any spec, and
could change at any time.


On the plus side, if the simpler hack were built into an IDE, it could
embed a list of corrections into a right-click menu, like a spell
checker.  It could do this outside the current cycle of edit -> compile
-> edit

I don't have interest in doing this - my ideas of a super-ocaml-IDE seem
too big for me to program ATM.

E.