[ANN] goprep, a go lexical preprocessor framework
Scott Lawrence
framework for go. The only significant demo I've written so far adds a
'gofor' statement[2], where
gofor x { y }
is translated to
go func () { for x { y } }()
The framework's shortcomings are many (processing is purely sequential,
no proper error checking, incorrect line number reporting, no system for
watching nested depth of {}/[]/(), etc.), but it should be sufficient to
make playing around with various language extensions easy.
Goinstall'able from github.com/bytbox/goprep/goprep.
Happy hacking!
[1] https://github.com/bytbox/goprep
[2] https://github.com/bytbox/goprep/blob/master/examples/goforpp.go
--
Scott Lawrence
SteveD
framework for go.
get a feeling for new syntax extensions without having to actually
modify the parser.
And yes, error checking and line number translation was definitely the
trickiest part of that project. A language like C is built for
preprocessing and has #line directives. Lua can be executed from a
custom environment that translates line references; the second is
possible with Go but could be awkward to implement.
steve d.
minux
On Jan 2, 11:45 am, Scott Lawrence <byt...@gmail.com> wrote:> A new
toy some might find useful: goprep[1] is a lexical preprocessor>That's cool; I did LuaMacro for exactly the same reasons, as a way to
framework for go.
get a feeling for new syntax extensions without having to actually
modify the parser.
And yes, error checking and line number translation was definitely the
trickiest part of that project. A language like C is built for
preprocessing and has #line directives. Lua can be executed from a
//line <filename>:<linenr>
Scott Lawrence
> with Go, you can use this meta-comment for C's #line:
> //line <filename>:<linenr>
It's still somewhat tricky to get right, especially with go's automatic
semicolon insertion that makes it difficult to tell exactly what line
one is currently on.
Error handling during the translation stage is still problematic, of course.
--
Scott Lawrence
minux
On 01/02/2012 10:25 AM, minux wrote:It's still somewhat tricky to get right, especially with go's automatic
> //line <filename>:<linenr>
semicolon insertion that makes it difficult to tell exactly what line
one is currently on.
into the Lexer itself to give out better (more accurate) diagnostics.
So, I think the same might be true for Go. Unless we are integrating the preprocessor
into the compiler, we'll always have trouble in reporting accurate line numbers.
Maybe some day the Go compiler can gain some macro (in Lisp's sense, not C's)
(or metaprogramming) support? (Though I doubt that.)