Mats Nygren wrote:
> 
> Paul,
> 
> I made a lot of fuss about these matters not long ago. I entirely
> support your line of development, in fact I have already made the
> suggestion you made in my upcoming version of the code generation. I'm
> on vacation now and it will take a while before I have something to
> present and then we have the headache of trying to coordinate different
> changes. I hope you will help with this when the time comes (autumn).

Looking forward to it. My own changes are very modest. I have added some
support for outputing Delphi Object pascal syntax, but they are
incomplete.

Hope you're enjoying your vacation.

> By doing the code generation with a visitor it is easy to make similar
> codegenerators with inheritance. 

You are absolutely right. The visitor pattern is what this should be.
CCodeGenerator seems like it wanted to go in this direction a little bit
in terms of the way the code starts up and the way the generator is
relied on for some functionality. But the responsibility is shared
around too much. This happens often in Smalltalk -- there is a tension
between modularity and delegation.

It is very cumbersome otherwise to do this by modifying the existing
Squeak code. You need to subclass several classes and copy code and make
minor changes. I started this for doing Pascal and then gave up and just
added methods to the existing parsing related classes along side the C
code. The problem is I started from modifying the C methods an in a few
places I missed changes and it defaulted to using the C syntax -- which
I only noticed after starting some changes to the output done by hand.

Fairly unrelated, but I have problems with reserved word sometimes. For
example, I'll make a variable called "string" but that is a Delphi
Pascal reserved word inthe generated code. Early VM's had this by using
"class" as a variable when that word is reserved in C++. (I presume that
isn't the case anymore?)

> I have sketched different mappings of
> Squeak to C, Python and Scheme code. All of these follows the same
> general patterns and the same pattern as the "pretty printing" of
> Squeak-syntax.

Great! Love to see the Python one sometime (no rush).  

On the other side, I think it might be possible to load Python modules
into Squeak...

> I hope you will support the idea of refactoring the code generation
> along these lines, as that is a very useful organisation. I have
> described it very cursory on my Swiki-page. 

Interesting: 
  http://minnow.cc.gatech.edu/squeak/1450

> And in the recent "syntax war".

It turns out I hadn't read a single item in that thread...
Not that I'm not interested, just that the topic sounded contentious.
Interesting to look at it now.

About three years ago I posted something related on "Squeak and the
Babel of programming languages" suggesting the Squeak development
environment as a grand unifier. Available here (a big page -- search on
"babel"):
  http://www.create.ucsb.edu/squeak/9612.html
As luck would have it, somehow "=20" got appended to the end of each
line by my email client... Showing how the universe is still resisting
having a common language. :-)

It is a really interesting issue -- how to have commonality and
interoperability between systems with different assumptions and
libraries.

> There are more to this of course, in due time.
> 
> BTW, I also devised the idea of being able to produce any C-identifier
> from within Squeak. By using roman numerals like this for example:
> 
>    fprintf(stdout, "%d %d", x+1, y+1); /* how to get this */
> 
>    stdout printfI: "%d %d" II: x+1 III: y+1 " like this "
> 
> In the way one can make Squeak-names in C etc (with '_') and
> multiparameter calls without having a keyword-style name.

People may be confused choosing between IIII vs IV.

May I suggest p1, p2, p3, p4, etc? Or something like that?

As in:
  stdout printfPPPp1: "%d %d" p2: x+1 p3: y+1 " like this "

I stuck in the PPP for clarity, but it could be removed or substituted,
or reflect the number of parameters.

> Someone have already made roman numerals in Squeak, probably this is
> easy to use.
> 
> I have also devised ways of getting rid of the C code that is written as
> string directly handed over to output. They create many problems.
> 
> And then there is the handling of types ..

Perhaps we need a GUI tool that makes it easy to track every variable by
name in a class and assign likely types.
 
> You might want to check out some reply from me to Henrik Gedenryd
> with a .cs for showing the generated code in a browser, simplifies trying
> out these kind of things, you will have to adapt it a little of course but
> it should be easy to do. "re: slang to c" it is called.

Thanks for the pointer. This would help with testing generation.

> Paul Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> > Michael Lucas-Smith wrote:
> > > I like this. It gives the chance to be able to FileIn C/Pascal code back in
> > > to Smalltalk.. as long as the C/Pascal code follows the right coding
> > > 'rules'
> >
> > Wow. I hadn't thought of this. Excellent point. Round trip!
> 
> This was my main point, the usefulness of this.
> 
> <hm>
> I promised to end the war, but this is only a reply to a posting isnt it?
> </hm>

Hope to not kindle that myself... Too busy on other stuff...

> Good luck!
> 
> </mats>

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com