Why Forth, was:Greetings

[Francois-Rene Rideau]

NB: don't post to both tunes-lll@bespin.dhs.org and tunes-lll@tunes.org
since they are the same mailing-list!

>>>: Jason Marshall
>>: Paul Dufresne
>: Jason Marshall

>> Guarded Single-assignment [...]
Single-Assignment basically means that a program (or program fragment)
is transformed into pure style without side effects,
or equivalently that its semantics is expressed in a monotonous logic.

However, as usual, this won't work well for shared variables and resources,
places where communication happen, or just user-redefinable objects.

Don't get me wrong: pure programming is something great,
and should be used whenever it can;
programs are better automatically transformed in pure style
for semantic analysis and optimization, when they can be.
But sometimes, they cannot, and what I'm looking at is precisely
a way to specify what happens at this point.

Also, we have side-effecting implementations of pure programs,
and it is important to explicit the correspondances
between pure programs and their impure implementations,
as well as being able to maintain the consistency of those implementations.
In case you're interested, see my recent paper
	On the Notion of Implementation
	http://www.tunes.org/~fare/tmp/

> Let me just say that I am of the opinion that 'better language'
> is a lazy excuse for slow execution speed.
Sometimes it is, but not always.
Also, there is the question of slow at _what_?
The kind of problems solved with some high-level languages
would just never have been correctly solved in finite time in C;
for these problems, these languages are just infinitely faster than C!
Also, speaking of speed, do you take human development time into account?
Do you take compile time into account?
Often, the two above cost much more than runtime...
Finally, this reminds me of Maciste, that usually runs as
the slow high-level inference engine pig that it is,
but has heuristics to detect times when high-level inferences
don't bring in enough information anymore, and will then
compile the remaining problem subtrees
into efficient partial-evaluated programs.
So that again, speed is a question of the time scale you consider:
micro-optimization for speed is sometime the enemy of macro-optimization.

> If tunes intends to take away some of the details from the user,
> I should hope it doesn't fail to appreciate
> that the details are still there,
> and make the best use of them that it can,
> not the least of which is to improve
> runtime productivity in addition to design time.
The goal of reflection is precisely
to let the user choose the details he wants to consider.
However, in multi-user flavors of the system,
security issues may also prevent users from accessing some details
(least they do it inside unixish paranoid isolation boxes).

>>> So my biggest question at this point is why the decision was made
>>> to use an
>>> existing human-friendly language (Forth)
>>> as the LLL for the Tunes project, as
>>> opposed to some sort of more compiler-friendly format.
This isn't a "choice", but rather a natural outcome of low-level development:
FORTH is a nice model, easy to implement, with great benefits at low cost.
It is here, so that's what we have.
Remember: whoever writes the code gets to decide.
That doesn't mean it's the ultimate way to do things.

For instance, another FORTH-like model (albeit higher-level, with GC,
and with only one "open" stack, corresponding to data),
is the POP Virtual Machine, recently released as free software
	ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/freepoplog.html
that allows pop11, prolog, commonlisp and ml programs to be freely mixed
within a one system image.

> I would tend to believe that a LLL isn't intended for human consumption.
Yes and no: there will still be things written by the human
about the low-level details of the machine.
Even if it's written in a fairly high-level declarative style,
there will have to be a human somewhere who understands fairly well
what code will be produced and why it does the Right Thing(TM).
That said, I agree that a LLL isn't intended for _general_ human consumption.
Actually, neither is any "level" of abstraction of the system:
ideally, every level of abstraction will find its few experts,
so that other people can focus on whichever domain and corresponding
abstraction domain suits them.

>> Forth is a first language supported, but some kind of reflective Scheme
>> is likely to follow.
Looks like to me that reflective Lisp mightn't be Scheme. We'll see.

> [about Oberon] It was simply a description of the
> architecture-neutral code format that helped push me firmly away
> from thinking a Virtual Machine architecture
> was an even remotely good idea (I contend that it is
> not, as it at once keeps too much of certain types of information,
> while loosing other types irretrievably).
Actually, I could contend that even Oberon's (compressed) parsed tree
representation for programs _IS_ some kind of virtual machine;
just not a _sequential_ virtual machine.
So the morale of the story is just the more general cybernetical law:
to achieve a means of efficient communication,
keep the relevant information in your encoding convention,
and eliminate the irrelevant noise.

Best regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Ob(Pure Programming Languages): implicit state _is_ modularity.
If we want to be really radical, and eliminate implicit state,
then we should eliminate it at the meta-level, too,
and remove named variables, leaving us only combinators.
(\Pi (S (K \Pi) (S (S (K S) (S (K K) (S (K P) I))) (S (S (K S)
(S (K (S (K P))) (S (S (K S) (S (K K) (S (K P) I))) (K I)))) (K I)))))