parser (was: bytecodes)
Jecel Assumpcao Jr
jecel at merlintec.com
Fri Nov 3 19:06:56 UTC 2000
> And the PICS ? Can they be implemented with the new bytecode ?
> What is the impact of PICS then ?
Sorry about the confusion - the comments from Urs are from 1993 while
the new bytecodes are from 1996 (I think), so he was thinking
generically and not about what is in Self 4.1.2.
Note that PICs are not implemented in the Mac port of Self. My guess is
that their main performance impact is in providing type information for
the SIC (which is also not implemented on the Mac).
> > [inline "if" and "while" messages]
> but the inlining compiler does that job good, right ?
It sure does!
> Branch bytecodes are IMHO bad, because the parser statycally gives
> meaning to a message (ifTrue:...)
I don't like this about Smalltalk. Self 1.0 also had this problem
(there were a set of messages the compiler knew about and did a good
job on), but now all messages get equal treatment.
> You can encode bytecodes and literals in one vector (using an additional word for bcode
> size, and the padding max. 3 bytes) so you come out with 4+(0..3) bytes :-)
You want an object that is a mix of normal vector and bytevectors like
most Smalltalks used for their method objects? You can't pack the
bytecodes in a normal vector since you only have 30 bits in a smallInt
(not enough for four bytes).
> > That would be great, but as long as we can read in each other's textual
> > Self source it would be a good start too.
> Sure, it's good. My parser is really bad :-)
> Maybe a parser written in Self would be good. Bootstrapped using a bad parser is
Good idea. There is already a very outdated parser that is used as a
benchmark in Self. It is not very well written, however (just like
tinySelf 0 and, perhaps, yours), and would have to be extensively
updated to understand annotations and other Self 4 things.
> We would have then the same parser and 100% source compatibility,
> every effort would be shared and it would a good example of Self's flexibility.
You have to be careful about what interfaces the parser uses (sets of
messages mirrors need to understand).
> Can Mango do the job ?
I don't think so - Mango needs a structured grammar that it can
translate into a LR(1), LALR(1) or SLR(1) parse table (I once used to
know what these were ;-) and you can't write one for Self. The
explicit receiver expressions are likely to be the main problem, though
the abuse of the "." token might also make it impossible to use Mango.
On the other hand, I did try to write a Mango grammar file for Self 3.0
(to be translated into a SLR(1) parse table) in 1996. I can't remember
why I didn't finish it, but know I was stuck in the lexical part. You
can get it at http://www.merlintec.com/s3.grm
More information about the Self-interest