Why we should remove {} from Squeak

danielv at netvision.net.il danielv at netvision.net.il
Tue Oct 2 17:14:07 UTC 2001


Hi Dave.

Andreas said he likes math's precedence rules. In reply Stephan
suggestws that we embed the whole language of mathematics, instead. I
prefer this to bowing to math's conventions, because code is only
sometimes like math calculations.

So I made the proposal I'm appending. 
A couple of points to clarify my intentions (refering to your questions
- I'm not that radical) -
* As I said in my first reply to Stephane, I don't mind having an object
that's created at compile time, so long as it's immutable (because its
semantics then make its history and time of creation irrelevant). So
Booleans, Blocks (to be precise, closures, if they were), Characters,
Integers and Floats are okay. Arrays and Strings I expect to be mutable,
so they are not ok.
* I'm not talking about CompiledMethods, either, because they're usually
implicit to what you're coding. I don't mind the compiler creating
methods and classes at compile time - a programmer who cares will be
doing reflection and will probably be aware of their method of creation.
Also, I don't have any better idea on what the compiler should do,
rather than create those objects! :-)
* When we need an object, we usually create it in our programs run time.
When we can't afford that, we usually cache it. I'm describing a simple
scheme to make caching, giving us most of the speed and convinience of
the #() and '' syntaxes. It relies on tools and not on special syntax,
and is applicable to other domains, like mathematical notation, or
icons.

I hope this is clear, tell if it isn't.

******** Proposal - 
self premadeFlowFormula forParameters: ...

#premadeFlowFormula is an accessor to a cached object representing a
mathematical expression.

The browser tool recognizes the "premade" prefix, which is a convention
for such things. So it looks for and finds a method called
flowFormulaDefinition, which returns an XML description (in this case,
probably MathML) of the formula. It is this method that would be used
for the lazy initialization of the formula object.

Having found the conventional matching "Definition" method, having
recognized it as standard XML, it checks the schema for the data, and
starts looking for the appropriate object to represent it directly in
the method. This could be an inline editor, or an icon that brings one
up. If this object is used in more than one place (other accessors to
the sender), the browser gives some indication of the further
implication changing it might have.

Of course, this works for math, SVG graphics, icons, whatever.

No syntax changes, your code can be published anywhere and be completely
readable by standard tools, but you get most of the advantages of
Jecel's powerful "just put the objects in the code" usage metaphor.

The convention can serve eToys just as easily as textual browsing tools.

Of course, the browser should provide convinient tools for embedding the
things in the first place, automating the creation of the accessor, lazy
initalization (if caching is wanted) and so forth.
********

"David N. Smith (IBM)" <dnsmith at watson.ibm.com> wrote:
> At 2:11 +0300 10/2/01, danielv at netvision.net.il wrote:
> >...
> >
> >See my proposal in another message on this thread - we should lose the
> >idea of "compile time created" objects, and use tools to make caching
> >easier.
> >...
> >
> >Daniel
> 
> Oh! 
> 
> I didn't find your other thread, so all I have to go on is this. So, you propose no blocks? No compiled methods? No integers, or strings, or floats?
> 
> Or aren't blocks going to be objects anymore? Or integers, like in Java.
> 
> Maybe you could point me to that other proposal so I can go read it...
> 
> Dave
> 
> BTW, I always thought progress came from new ideas that don't quite fit with current notions, but that are useful. In programming languages they might spark creation of a new theoretical framework eventually, rather than the old framework forbidding use of the idea. Am I confused?
> -- 
> _______________________________
> David N. Smith
> IBM T J Watson Research Center
> Hawthorne, NY
> dnsmith at watson.ibm.com




More information about the Squeak-dev mailing list