23 Mar 14:54
( picoVerse-:( language ideas ) )
From: Kjell Godo <squeaklist@...>
Subject: ( picoVerse-:( language ideas ) )
Newsgroups: gmane.comp.lang.smalltalk.fonc
Date: 2008-03-23 13:58:07 GMT
Subject: ( picoVerse-:( language ideas ) )
Newsgroups: gmane.comp.lang.smalltalk.fonc
Date: 2008-03-23 13:58:07 GMT
Hi Ian
I would like to propose a few language ideas that I
am putting into picoLARC. I am making a detailed
specification of picoLARC in Smalltalk.
picoLARC is to include all other languages within
itself as lisp dialects.
Macros use the same Object message dispatch
that Methods do. A Macro is just a Method that
takes in KEGParseObjects and returns a
KEGParseObject which is then compiled.
A Programmer is an instance of a ProgrammerClass
which can be put into a Class at compile time and
then messages can be sent to that Programmer
from inside the code being compiled. So an
Object oriented form of Macros is the result.
Thus all languages in picoLARC gain access to
Object Oriented lisp style Macros.
Instead of using different syntax for each language
in picoLARC lisp is used for each. The human
programmer translates C# into a lisp style and
then the picoLARC compiler compiles that like
the C# compiler would. It's probably too hard for
me to do but that's the idea. The programmer
has to swap things around a bit but the underlying
spirit of the lisp style should be like C#, for instance.
anObject->method( ... )->method2( ... )
becomes
( ->method2 ( ->method anObject ... ) ... )
variable = expression ;
becomes
( = variable expression )
Now this will cause people's heads to explode. But we
are doing it because then Macros can be used for each
different sub language in picoLARC.
Method dispatch is done via picoLARC GenericFunctions
such that no Dictionary lookup is needed for unique Methods
in leaf Classes( which have no subClasses ). And for Object
level Methods an Array lookup is done instead of a Dictionary
lookup.
Nodules are sets of variables like namespaces but OOP.
( atIndex:put: aCollection i anObject )
The function name has one less : in it than there are inputs
so we know that this is a Message send. aCollection is
the first input so it is the receiver. The Class C of aCollection
is accessed and fed into the GenericFunction that is saved
in the atIndex:put: variable in the highest Nodule on the
Activation stack. Then a lookup is done and a Function F is
returned that considers its first input to be the receiver of
the message. The Function F is therefore a Method.
This form of Method dispatch can be used by the Macros
and the other language styles as well. Prolog can be
Object Oriented in this way.
Each picoLARC expression can have a language prefix
that tells which Compilers are to compile it.
( lambdaLisp ... )
( prolog ... )
( c# ... )
( c++ ... )
( java ... )
So instead of using different syntax for each language
we use lisp dialects which unifies everything and makes it
so that we can include in picoLARC as many languages as
we want. And yet all of them can make use of Macros.
Also the different languages can be mixed together easily
by the human programmer.
( lambdaLisp ...
( prolog ... )
( c# ... )
... )
lambdaLisp is the default.
Also Class Hierarchies are abstracted so that you can
have as many of them in each Nodule as you want.
A Hierarchy like the one in Smalltalk is proposed.
So you could have multiple Smalltalk like Hierarchies
if you want.
What do you think? Could you use any of these ideas in
Cola?
Will there be a Cola for Windows?
Will the machine code generation also be reflective in
Cola? That would be cool.
.net?
-Kjell
<div> <div>Hi Ian</div> <div> </div> <div>I would like to propose a few language ideas that I</div> <div>am putting into picoLARC. I am making a detailed</div> <div>specification of picoLARC in Smalltalk.</div> <div> </div> <div>picoLARC is to include all other languages within</div> <div>itself as lisp dialects.</div> <div> </div> <div>Macros use the same Object message dispatch</div> <div>that Methods do. A Macro is just a Method that</div> <div>takes in KEGParseObjects and returns a</div> <div>KEGParseObject which is then compiled.</div> <div> </div> <div>A Programmer is an instance of a ProgrammerClass</div> <div>which can be put into a Class at compile time and</div> <div>then messages can be sent to that Programmer</div> <div>from inside the code being compiled. So an</div> <div>Object oriented form of Macros is the result.</div> <div> </div> <div>Thus all languages in picoLARC gain access to</div> <div>Object Oriented lisp style Macros.</div> <div> </div> <div>Instead of using different syntax for each language</div> <div>in picoLARC lisp is used for each. The human</div> <div>programmer translates C# into a lisp style and</div> <div>then the picoLARC compiler compiles that like</div> <div>the C# compiler would. It's probably too hard for</div> <div>me to do but that's the idea. The programmer</div> <div>has to swap things around a bit but the underlying</div> <div>spirit of the lisp style should be like C#, for instance.</div> <div> </div> <div>anObject->method( ... )->method2( ... )</div> <div>becomes</div> <div>( ->method2 ( ->method anObject ... ) ... )</div> <div> </div> <div>variable = expression ;</div> <div>becomes</div> <div>( = variable expression )</div> <div> </div> <div>Now this will cause people's heads to explode. But we</div> <div>are doing it because then Macros can be used for each</div> <div>different sub language in picoLARC.</div> <div> </div> <div>Method dispatch is done via picoLARC GenericFunctions</div> <div>such that no Dictionary lookup is needed for unique Methods</div> <div>in leaf Classes( which have no subClasses ). And for Object</div> <div>level Methods an Array lookup is done instead of a Dictionary</div> <div>lookup.</div> <div> </div> <div>Nodules are sets of variables like namespaces but OOP.</div> <div> </div> <div>( atIndex:put: aCollection i anObject )</div> <div> </div> <div>The function name has one less : in it than there are inputs</div> <div>so we know that this is a Message send. aCollection is</div> <div>the first input so it is the receiver. The Class C of aCollection</div> <div>is accessed and fed into the GenericFunction that is saved</div> <div>in the atIndex:put: variable in the highest Nodule on the </div> <div>Activation stack. Then a lookup is done and a Function F is</div> <div>returned that considers its first input to be the receiver of</div> <div>the message. The Function F is therefore a Method.</div> <div> </div> <div>This form of Method dispatch can be used by the Macros</div> <div>and the other language styles as well. Prolog can be</div> <div>Object Oriented in this way.</div> <div> </div> <div>Each picoLARC expression can have a language prefix</div> <div>that tells which Compilers are to compile it.</div> <div> </div> <div>( lambdaLisp ... )</div> <div>( prolog ... )</div> <div>( c# ... )</div> <div>( c++ ... )</div> <div>( java ... )</div> <div> </div> <div>So instead of using different syntax for each language</div> <div>we use lisp dialects which unifies everything and makes it</div> <div>so that we can include in picoLARC as many languages as</div> <div>we want. And yet all of them can make use of Macros.</div> <div>Also the different languages can be mixed together easily</div> <div>by the human programmer.</div> <div> </div> <div>( lambdaLisp ...</div> <div> ( prolog ... )</div> <div> ( c# ... )</div> <div> ... )</div> <div> </div> <div>lambdaLisp is the default.</div> <div> </div> <div>Also Class Hierarchies are abstracted so that you can</div> <div>have as many of them in each Nodule as you want.</div> <div>A Hierarchy like the one in Smalltalk is proposed.</div> <div>So you could have multiple Smalltalk like Hierarchies</div> <div>if you want.</div> <div> </div> <div>What do you think? Could you use any of these ideas in</div> <div>Cola?</div> <div> </div> <div>Will there be a Cola for Windows?</div> <div> </div> <div>Will the machine code generation also be reflective in</div> <div>Cola? That would be cool.</div> <div> </div> <div>.net?</div> <div> </div> <div>-Kjell</div> </div>
RSS Feed