I am making picoLARC
it is a computer language
I know how to do it basically.
But when I read what you are saying on this news list I feel
that you know a lot more about compilers than I do. I am
talking about optimization and code generation I guess.
I only know what I read in the Lisp In Small Pieces book.
I feel like there is probably a lot I could learn from you
about how to make compilers. I would like to learn it.
I am frustrated by the near total lack of documentation
that programmers provide in and about what they make
that they put out on the web. For one thing. Like the
Squeak compiler and interpreter and VM. I would like
to understand how it works but it seems like a real uphill
battle. Any suggestions?
Is there anything like:( Compiler compileAndRun:'1 + 1' )
that I could single step in Squeak?
Why do 100% of programmers hate to document so much?
Is it because they assume you will get all your questions
answered in the news groups? Isn't that duplicative and
wasteful? Or is the duplication and waste a social benefit.
Dolphin Smalltalk is the only program that I have seen that
is half way decent documented.
And what about COLA LOLA? How could I best try to get
the gist of how LOLA works on the inside? It doesn't work
under Windows does it?
Debian? Is that what I need? I have XP Pro on a laptop
with 21GB of free space left on the 60GB hard drive. It
just seems to keep dwindling. I don't know why.
I could get rid of the pictures and movies I guess, that might help.
Could I get the Linux I need to see LOLA COLA on my
laptop? Could I run it from a USB external drive?
I think I need a bigger hard drive. scrimping was a mistake.
Anyway I am making picoLARC and I feel like COLA
is trying to do some of the same things that I am trying
to do in picoLARC. I have already gotten one good idea
from COLA. The idea of mixing two languages Smalltalk
and Lisp. I tried to do the same thing in picoLARC but
in a pure Lisp way that expands to multiple language
variants of Lisp. I allow an optional language style selector
at the beginning of Lisp expressions that tells which
compiler to use for that expression. p is for PrologLisp
c is for C++Lisp, etc. PrologLisp is a Lisp that acts like
Prolog. And C++Lisp is a Lisp that looks and acts like
a subset of C++ as much as possible.
I feel like I would like picoLARC to be implemented on top
of many other languages so that those languages would
do all the code generation. I have a book that has a section
about generating assembler and most of it seems to be about
prepairing to call library functions.
Isn't that the point of .net? To take care of calling the library
functions? Is it better in Linux?
At some point I would like it if picoLARC could generate
independent machine code but I would like to make use
of the libraries that other languages provide. So I don't
have to provide them myself when others have already
provided them. Is this situation better in Linux?
The thing I don't like about Linux is that there aren't any
programs that deal with stock options like calls and puts
and Leaps and all that. Or am I wrong? I sure wish I was.
I liked what you said about including parser compiler
interpreter generators in the language? What did you mean by this?
I wonder if I could add this idea to picoLARC but I don't know exactly
what it is you are talking about.
i am implementing picoLARC in Smalltalk first because
then I get all the Windowing and stuff for free but it is
slow. picoLARC could be a higher level language on top
of Smalltalk but most coding would still have to be done
in the underlying Smalltalk for speed reasons. But picoLARC
could sit on top of Smalltalk like some of these scripting
languages sit on top of C libraries.
Smalltalk is great for getting everything worked out right.
But I'm afraid that the end result will be too slow for a lot
of things.
So anyway here is an overview of picoLARC that I wrote
for the main Package comment. I hope you will tell me
what you think. There is a section at the bottom that
lists the main points about picoLARC.
You can get the initial version of picoLARC on sourceforge.net .
It requires Dolphin Smalltalk 6.0 community version which
is free. There is a guided tour.
( overview ( date: 20071202 )
picoLARC is a multi language multi compiler interpreter multi platform
programming system.
The main idea is to combine the best things from every programming
language into a single
programming system. Each different language like C++ and Java is
translated into a style
of Lisp. Lisp syntax is a main unifying idea. Lisp syntax is used
because Lisp has the most
powerful syntax of all because Lisp can easily be made to program itself
via macros and a
new thing called Programmers which is like a hierarchy of macros of
sorts. Each different
language style can be called from within other language styles. Each
language style has
its own set of compilers and interpreters. So all these different
languages are combined
together into a single whole where macros and Programmers can be used
throughout. So
macros and Programmers can be used now in every different language style.
Multiple
different kinds of code generation for multiple different kinds of
interpreters and execution
platforms will be supported in the style of the Squeak VM where the VM is
coded in Smalltalk
and then translated into C and compiled to make a new virtual machine.
Various different
styles of this kind of thing will be supported if possible. For instance
the picoLARC system
could be translated by hand into C++ or Java or ML or Haskell or C# or L#
or what have you
and then it could be tightly coupled with everything that those languages
have access to.
And it could also have byte code interpreters set up inside of itself such
that VMs can be
generated for these various different languages and then bytecode images
run on those VMs
like in Squeak. Or native executables could be generated. Or .net
executables.
One of the main ideas is that picoLARC should be reImplemented in as many
possible different
ways on different platforms so as to gain access to the libraries and
functions of those platforms
as easily as possible.
For instance a VM for picoLARC could be coded up in the C++ style of
picoLARC and then
that VM could generate C++ code by a simple translation like is done in
Squeak.
picoLARC C++Lisp functions methods would not use deep free variables so
their
local variables could be put on the stack instead of on the heap in
environments like Lisp does.
So picoLARC C++Lisp could easily compile to run just as fast as C++
depending on how
optimized the picoLARC C++Lisp compiler could eventually be. And then
C++Lisp could
be directly translated into C++ so all the native C++ optimizations that
there are could be.
Like for trying to make a picoLARC VM in C++ like Squeak does etc. Or
C++Lisp could
be used to reImplement the picoLARC that is now written in Smalltalk so
that it could be
translated into C++. The Smalltalk style so far can be considered to be a
large VM that
interprets trees of Eval Objects rather than sequences of byte codes. And
so a C++ version
of that could be made where the VM is bigger and more complex than a VM
that interprets
byte codes. There could be advantages to that way of doing things. It
might make it
easier for C++ programmers to tightly integrate picoLARC with C++. In
Java where you
can serialize any Object network it would be easy to save the picoLARC
image as just
a tree like network of picoLARC Objects.
Perhaps picoLARC could be ported to Squeak so that a new picoLARC VM could
be made
that would sit next to the Smalltalk VM and interact with it. Hopefully
the picoLARC VM
would be much better documented so more people could work on it.
One of the the other main ideas is that each different language style will
have its own Smalltalk
like Class hierarchy and each of these different hierarchies can be
generated from scratch on
demand. By Smalltalk like I don't mean that the Classes will be the same
but that
the Class MetaClass hierarchy will use the same pattern where every Object
has a Class
and the Class defines the behavior of the instance, so the behavior of a
Class C is defined
by the MetaClass that is C's class, the behavior of an instance is defined
by its class etc.
A single unifying way of message dispatch is used based on a picoLARC
version
of GenericFunctions. A GenericFunction is a Dictionary of < classID
functionEval > pairs.
Each GenericFunction is saved in a variable named after a method or
function of sorts.
This results in the fact that methods that are unique in the system in
Leaf Classes can be
dispatched without classID lookup and methods which are defined in the
rootClass of a
hierarchy can be looked up by an Array lookup so it makes things a little
faster for message
dispatch than the way that Smalltalk does it which is by looking up
methods in Classes.
The picoLARC way is to look up methods in GenericFunctions not in Classes
like Smalltalk
does it. picoLARC still has Classes for development purposes and to
organize the
GenericFunctions. GenericFunctions are not defined explicitly in the
source code only
Classes are and the GenericFunctions are created from those Class
definitions.
This GenericFunction way of method dispatch is used for all the different
hierarchies for all
the different language styles and macros and Programmers. It's the same
functionality as
the Smalltalk way but it affords some dispatch speed optimizations that
Smalltalk can't do.
Another main idea is that there will be name spaces called Nodules which
can have Nodules
within Nodules. Nodules can import variables from each other in general
cyclic ways. Data
access is via variables. Each Nodule has a set of variables defined on
it. Each Nodule can
have an arbitrary number of different Smalltalk like hierarchies defined
on it. These hierarchies
are plyable and can be constructed on demand. Unlike the Smalltalk Class
hierarchy which
is very brittle to everything but founder level changes and updates. So
you can define a
Nodule and then tell it to build various hierarchies into itself and then
add to those hierarchies.
picoLARC will combine the text file based way of programming used in the
non Smalltalk
world with the Smalltalk way. When you click on a picoLARC method you
will get the
source code for that method but you will also get all the rest of the file
that source code
is in. So if you scroll up or down far enough you will see the rest of
the file. Accepting
a source code change will cause the entire file in the browser window to
be compiled and
re evaluated to produce functions and methods etc. picoLARC will use a
combination of
text file based and Smalltalk Browser and image based programming to get
the best parts
of both.
A Nodule can be running a byte code interpreter and another one can be
running Eval trees
and they can communicate with each other via Croquet like synchronization
and interface
Objects like Numbers and Strings etc that can pass between them.
( Nodule is another name for Interpreter. A Nodule can be just a name
space or it can be
a name space and an Interpreter. Nodules are implemented by the
Interpreter Class which
as of 20071202 serves as a name space only. )( picoLARC Smalltalk Classes
often have long
prefixes and suffixes to their names and these are often left off here.
So Interpreter is actually
referring to KEGLambdaLispInterpreterV6p1. You could search for the
Interpreter Class by
searching for *Interpreter* in the Class=>Find menu command in Dolphin
Smalltalk. )
--------------------------------------------------------------
So I guess the main ideas of picoLARC are:
Lisp style syntax throughout
Smalltalk style self documenting function names
Macro like Programmers can be used throughout
Different styles of Lisp one for each other nonLisp language
Mixing the different language styles can be done where possible
Smalltalk like Class hierarchies for each language style etc macros
Code generation from a language style into the language it is based on
like into C++ or Java
Tight integration with the language that picoLARC is implemented in like
with Smalltalk
Nodules within Nodules each with its own various Class hierarchies if
desired
Nodules can import variables from each other in general cyclic ways( a
kind of multiple inheritance? )
Nodules can be set up so they form a Smalltalk like hierarchy and in that
case Nodules would
be like prototype based Object systems like Cola where Nodules
could be cloned etc and
behave like Classes or like instances complete with MetaClasses etc
Nodules etc are hot swappable so different versions can be used at least
when picoLARC is
implemented in Smalltalk or using the Smalltalk style Object memory
Smalltalk like Class hierarchies are abstracted so they can be built on
demand for each different
language style and for macro Programmers
Various compilers and interpreters can coexist in different Nodules
Different syncronizable Objects can be syncronized across distance and
implementation
like in Croquet
All message dispatch for the hierarchies is done via picoLARC
GenericFunctions
Pattern matching can be used in macro Programmer calls and PrologLisp
queries etc
picoLARC is meant to be implemented on as many different platforms in as
many
different ways as possible
The whole thing is to be highly documented to provide low barriers to
entry and so it will be
built to last and not to rot
picoLARC has stepping source level debuggers like the ones in Smalltalk
that will
work in the presence of macros and Programmers
picoLARC combines the file and Smalltalk image paradyms of programming
to get
the best parts of both
)-[overview]
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
