Where is this new compiler project?  Where is NewCompiler?  I would like to
see it.
Does anybody know where that book about the Squeak Compiler went to?

the rest down below is all nonsense and I wouldn't read it if I were you.

i knew this was going to cost me.

What is atomic loading?  Does it mean no dependencies or dependencies are
handled?
It seems to me that there needs to be some kind of intellegent dependencies
manager that works a lot better and is a lot smarter than what has been put
out there so far.

How can I learn about how a good Squeak compiler works?  Without years and
millions of dead hours?

Modularity is very good.  I think that all of Squeak should be very self
explaining.  This can be done if you put your explanations of what is going
on after the body of the method.  Colored source is good too.  See Dolphin.
But without reformating.

I am making picoLARC on sourceforge.net.  Each lisp/smalltalk expression
gets compiled by an instance of a Compiler Class.  Each expression( let if
define etc ) has its own KEGLambdaLispCompiler subClass with one
standard method and zero or more helper methods in it.  Each Compiler
outputs an instance of a subClass of the Eval Class.  An Eval can be
evaluated at runtime by >>evalWithActivationRec: or it could generate byte
codes which do the same thing via some method like
EvalSubClass>>generateByteCodesOn:usingCodeWalker: where the CodeWalker
could tie Evals together or do optimizations?  Is this not a good design?  I
know I like the part about one Compiler Class for each expression and one
corresponding Eval Class.  But I haven't done any byte code generation yet
so I don't know about that part.  One Compiler per Eval is not strict.  The
ApplicationCompiler can output several different related kinds of Evals for
the different function calls and message sends.

What is this visitor pattern?  I don't like the idea of putting byte code
generation into a single Class.  But I feel like maybe I don't know what I'm
talking about.  To modify the byte code generation for an expression you
would subClass the Eval Class and modify the
>>generateByteCodeOn: aCodeStream.  The initial implementor would try to
seperate out the parts that might be modified by someone into seperate
methods that get called by
>>generateByteCodeOn: so these helper methods would generally be overridden
and not
>>generateByteCodeOn: unless that method was really simple.  So the initial
implementor has to think about reuse and the places where modification might
occure.  So you would have a lot of simple
>>generateByteCodeOn: methods instead of one big complex one.

There are all different ways of calling a function or method or query etc in
picoLARC and these are all subClasses of KEGLambdaLispApplicationEvalV6p1
and it seems to work fine.

But overriding >>generateByteCodesOn: is not good enough is it?  The
Compiler Classes can't have hard coded Eval instance creations either
right?  The Compiler Class has to be subClassed also and the
>>meaningOf:inEnviron: needs to have a
( self createEval ) expression in it that could be subClassed and
overridden.  And then that subClass has to be easily inserted into the
expression dispatch table that pairs up expressions with expression
Compilers.  So when that table gets made there should be a
( tableModifier modify: table ) which could stick the < expression Compiler
> pairs in that are needed.

I think that is all that would be required to modify the compilation of an
expression.
I will have to make these changes to picoLARC so it will be more modifiable.

I think the Compiler should be very modular.  For picoLARC one Class per
expression and one Class per Eval seems to work good.  Stuffing lots of
seperate things into a single Class and doing a procedural functional thing
and not an OOP thing does not seem good to me.

I think that the Compiler should be very clean and a best practices example
with a long comment at the bottom of each method telling all about what it
does.  Writing it out and referencing other related methods helps to think
about what is really going on and then a better design without hacks comes
out.  I don't think hacking should be encouraged at all.  Hacking just makes
a mess.

And then this practice of not making any Package comments has got to stop.
I think that people who do that should be admonished in some way.  I think
that the Package comment for the Compiler should contain the design document
for it that tells all about how it is designed.  If it needs to be long then
it should be long.  It should include: How to understand the Compiler.
There should be a sequence of test cases that start simple and show how it
all works.

And that should go for the VM too.  This idea that the VM can be opaque and
only recognizable to a few is not good.

These should be works of art and not hacked up piles of rubbish to be hidden
away into obscurity.

There is this idea that one should only care about what something does.  And
the insides of it are a random black box that you tweek and pray on.  But I
think that the insides should be shown to the world.  They should
be displayed on a backdrop of velvet.  Especially the Compiler and VM and VM
maker.  And then the whole Windowing thing should be modularized so you can
have multiple different Windowing systems.

And what about having multiple VMs?  It would be cool if picoLARC could be
inside of Squeak in that way.  It would be cool if one VM was generalized so
that it could support different dialects and languages.  And another was
specific and fast.  And you could make various kinds of VMs and images and
output them onto disk without a lot of trouble.  It would come with gcc and
all that junk all set up so it would just work.  If you already had gcc you
could tell it not to download it.

picoLARC has simple name spaces called Nodules where you can have Nodules
inside of Nodules and Nodules can multiply inherit variables from others.
Maybe such a thing could be used in Squeak?  Then you could have multiple
VMs.  And VMs inside of VMs.

I think that Dolphin Smalltalk could be held up as an example of pretty.

I hope picoLARC will be another one.

I think that Squeak is pretty in a somewhat cancerous sort of way.
The cancer is all the hacking.  That goes on.
The vision is great but the hacking and undocumenting gum up all those big
ideas.

Sure it's quick but it rots away quickly too.

Undocumented features.  In Smalltalk this is less of a problem but in like
Lisp say you make this great feature but then don't document it.  You might
as well have not even made it.

On Mon, Sep 1, 2008 at 2:12 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/9/2 Edgar J. De Cleene <edgardec2001 at yahoo.com.ar>:
>  >
> >
> >
> > El 9/1/08 5:39 PM, "Eliot Miranda" <eliot.miranda at gmail.com> escribió:
> >
> >> The thought of a committee fills me with horror :)  I don't think we
> need
> >> anything so baroque :)
> >>
> >> Best
> >> Eliot
> >
> >
> > Peron said:
> > If you wish nothing happens, nominate a comitee
> >
>
> You both right. My intent was only to get people's attention on this
> problem and discuss different points of view and their needs.
> Then implementors (like me) making things need to be done. Thats all.
> If no-one sharing the thought that we need a better compiler at all,
> then i can simply take away my words, and we will stay where we still
> sitting. :)
>
>
>
> --
>  Best regards,
> Igor Stasenko AKA sig.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080901/14984f0f/attachment.htm