Method names

Jerome Garcia Jerome.Garcia at wj.com
Mon Nov 2 17:52:22 UTC 1998


     Sorry to jump in but parse trees again!
     
     As this message and the others in this thread mentioning parse trees 
     indicate, having to parse text has its bad points. I think the 
     problems with the more readable forms mentioned all go away if you 
     edit the parse tree directly using an editor that displays the parse 
     tree as text with appropriate visuals to indicate "types" of elements 
     displayed. A comment is just another node in the tree and is visually 
     identifiable as such.
     
     Jerome
     
     --
     
     Jerome E. Garcia
     jegarcia at adventurousmind.com
     


______________________________ Reply Separator _________________________________
Subject: Re: Method names
Author:  Vassili Bykov <vassili at objectpeople.com> at INTERNET
Date:    11/2/98 2:45 PM


At 01:37 PM 11/2/98 +0800, Matthew McDonald <mafm at cs.uwa.edu.au> wrote: 
>It looks like the main difficulty would be that the resulting language 
>couldn't be parsed without extra information - you'd need to know 
>whether or not there was a message called #next:bits to decide whether 
>or not "aBitStream next: 40 bits" meant ((aBitStream next: 40) bits).
     
[Incidentally, that would be (aBitStream next: (40 bits))]
     
Knowing what method selectors exist in the image would not be enough. If 
there existed #next:bits, #next:, and #bits, you would not be able to tell 
which interpretation of "<expr1> next: <expr2> bits" was the proper one 
without knowing (and you can't) the types of the expression results.  What's 
even worse, in a dynamic environment where selectors come and go, adding or 
removing a selector would mean potentially changing the parse tree of some 
of the already compiled methods.
     
--Vassili
     
-- 
Vassili Bykov         vassili at objectpeople.com 
The Object People     http://www.objectpeople.com 
+1(613)225-8812
  "Any sufficiently complicated C or Fortran program contains an ad hoc 
  informally-specified bug-ridden slow implementation of half of Common Lisp."
    -- Greenspun's Tenth Rule of Programming
     





More information about the Squeak-dev mailing list