"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
On Nov 14, 2005, at 0:02, Jonathan Worthington wrote:
* I'm thinking of a PIR syntax along the lines of this:-
The discussion goes forth and back, like all other discussion we already
had WRT syntax, months and years ago.
What syntax we parse now (and then do nothing with) isn't flexible enough.
Aside from fixing that, the syntax doesn't really matter *that* much, since
it's going to be generated by compilers anyway.
I'd much more prefer that a compiler (amber anyone ;) just emits PIR with
debug syntax so that folks get a feeling how it looks like. E.g.
What's the fascination with overloading comment syntax? Let's at least make
something that isn't a comment but actually gets stashed away somewhere look
different. s/#_dbg/.dbg/
#_dbg file "foo" # file is a bit special but general syntax is:
#_dbg keyword rest # (\w+)\s+(.*)
Not sure about file being special, but OK otherwise.
#_dbg 1 # bare number defaults to line for brevity
#_dbg line 1 # same
Fine.
#_dbg 1.4-8 # line.column-range
I guess this would be the same as:-
.dbg line 1
.dbg column_start 4
.dbg column_end 8
'file' and 'line' and maybe 'column' are special insofar that we might
need/invent a compact storage format for it (this is an optimization -
yes), that is we might have an 'optimized' file/line/column format and a
genernal format with 'key' => stuff mappings.
With what I suggested before, line and column could get just an integer
representation, which is likely cheap enough. I don't think we need to
special case these to get efficient storage.
Future improvements:
#_dbg begin_segment foo # create new segment type
#_dbg stuff bar # goes into segment foo
...
#_dbg end_segment # done with it
Why might we need multiple segments?
Thanks,
Jonathan
