Hi,
[Mostly addressed to Waldemar.]
Bert Freudenberg <[EMAIL PROTECTED]> writes:
>> Is Coke the language for developers implementing their own COLA? Then,
>> will we have to use a certain amount of Smalltalk syntax in addition
>> to Lisp for the implementation? The Brainfuck example had to use both,
>> too.
>
> It's not Lisp. It's S-expressions, chosen because they're one of the
> simplest conceivable syntaxes for tree-like data.
To expand on this, from my experience in actually using and modifying
the frankenchicken, and from reading the OLA papers:
The default "Coke" syntax will be S-exprs with a mechanism similar to
OMeta for defining DSLs. Since many people (myself included) like C
syntax for bit-bashing and Smalltalk syntax for object orientation,
those will be the first few DSLs (as Ian explained: ' or [] mean
you're in Smalltalk mode, and {} (will) mean you're in C mode).
>From that point (having defined the syntax grammars and implemented
their semantics as static/dynamic compilers in Coke), it would be
trivial to declare a whole file as C code or Smalltalk code or "Coke".
I don't share your opinion, Waldemar, that this will be too hard for
people to understand. S-exprs are wonderful for metaprogramming
programming once you have a decent paren-flashing editor. C syntax is
ingrained in the mind of every systems programmer out there, so it has
its uses. Smalltalk is the most concise notation for sending messages
to a world full of objects, which will relieve the Java and C++ crowd.
Rather than a confusion of different languages, I believe that each of
the three, once bootstrapping is complete, will serve to attract a
following and encourage them to learn about the other syntaxes for
when they are appropriate.
I think something that *is* confusing about the current system is that
the many of the Jolt programs illustrate obscure nooks and crannies of
the system as it is, and are not written in what will evolve to be a
idiomatic "Coke" programming style, with DSLs and all ([] and ' are
poor substitutes for a complete OMeta-style system). Rumour has it
that this will start to change soon, as Ian is getting ready to land
the new parsing framework.
I'm especially interested in the bootstrap process to help uncover
what those general Coke idioms are. If you or anybody else truly care
about this project, I encourage to take its development on an
evolutionary basis, identify a wart that you think you can remove from
the frankenchicken, and have at it!
The bootstrap plan is clearly laid out in one of the OLA papers, and
now we're getting pretty close to having Jolt host Coke. Once that is
done, we get to cut away a lot of the scaffolding, and make Coke into
a self-hosting both JITting interpreter and offline compiler (and
exposed as a C library to boot).
I have a feeling that if you keep asking about specifics before the
system is self-hosting, you'll be pretty disappointed with the
answers, and consume a lot more bandwidth. "Wait and see," is not a
great answer: "contribute and discover" is a much better one, IMO.
The brainfuck example didn't really "have to use both," it just chose
to use some Pepsi objects because they were readily available and it
would have been tedious to reimplement their functionality in Jolt.
Also, since Jolt is only a JIT, you'd pay the price of compiling them
every time you ran the program.
Coke won't be that way: the ability to be an offline compiler will
make it a flexible replacement for GCC (the Compiler Collection), and
using Pepsi objects (with minor extensions to the default Coke syntax
as in Jolt, or something more major such as the Smalltalk syntax for
entire compilation units), C stanzas, or other moods (such as
platform-specific assembler) can be fully pay-as-you-go. That is,
each supported library/language is replacable if you so desire. Its
JIT will make it an attractive target for scripting languages, too.
Of course, the best solution will be to exploit the rich libraries
developed for other languages by implementing frontends to Coke.
Coke's "default environment," the syntax and libraries we typically
build on to implement a frontend, has yet to find its own idiomatic
style, but that style is driven by concision.
Turning to Occam's Razor, if we are driven by concision, we will
probably find the best explanation of computing. Other environments
are driven by the inability to cast away historical baggage, which in
my eyes is a tragic flaw. Let the historical baggage be borne out in
the language frontends, without sacrificing the simplicity and
effectiveness of the core.
I wrote more than I meant to, but I'll leave it for you to find a more
concise representation of this e-mail in your brain. ;)
--
Michael FIG <[EMAIL PROTECTED]> //\
http://michael.fig.org/ \//
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
