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
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
