I finally understand this!

[Brian T. Rice]

At 05:44 PM 4/4/00 +0200, Massimo Dentico wrote:
>Alan Grimes wrote:
>> 
>> The biggest problem with the Tunes project, at its current phase, requires
>> that contributers be elite computer scientests, rather than mere
programmers.
>> =\
>> 
>> Also:
>> 
>> Unless you can show me one technical word or symbol that has exactly the
same
>> meaning across all fields of math and science, I propose that we abandon
the
>> idea of a HLL and instead concentrate on a compiler system that will take
>> domain specific languages and turn them into code. =)
>
>IMHO  the  biggest  problem with the Tunes project  is  that  some
>contributors don't understand its goals. This because we are in  a
>different  paradigm, *not* because reflection (the  main  goal  of
>Tunes) is a concept that only a computer scientist can grasp.

I'd say "most" contributors instead of just "some". The common consensus
that there will be a unique LLL within a fully-developed Tunes system seems
to be one of the mis-understandings, as well as the fallacy that the Tunes
site documentation is anywhere near specific enough for development. Of
course, my own "Arrow paper" is little better, but then I stopped short of
a full paper there to make sure that I finish the theory and implementation
strategy first. (PS see below)

>In  the past, self-modifying code (a primitive form of reflection)
>was quite common, motivated by resource constraints above all. The
>problem  with  self-modifying  code  is  that  if  not  adequately
>constrained it's difficult to develop and control.

>What  means  *adequately*  constrained?  Currently  it's  hard  to
>establish.  I think that François have stopped the development  of
>his  code for this reason: he is searching a solid and clear  base
>(a  theory  of  reflection)  on which to  construct  a  Tunes-like
>system.  From a different point of view, Brian is doing  the  same
>with his Arrow System.

I'll agree with this statement about me with the possible exception that
I'm working in a more general field than Fare seems to be doing. If you
want to know where Arrow is going, take a look at my ongoing posts on Slate.

>Reflection  encompass  and go well beyond  "traditional"  compiler
>systems  for  Domain Specific Languages (DSLs). In  a  context  of
>DSLs,   with  a  reflective  system,  you  can  switch  from   one
>representation (language) of the "code"(1) to other more  suitable
>for a specific task; all in a coherent framework. This is only  an
>example of the (potential) power of reflection.

Thank you for pointing this common mistake out.

>It's  not my intention to diminish the importance of DSLs; on  the
>contrary, I want a system which can catch the full flexibility  of
>DSLs.
>
>(1)  In  meta-programming (and reflective) systems there  isn't  a
>clear distinction between data and code.

Well, meta-programming systems make code from their *object* systems work
as data, so there's a little distinction there. And even in reflection,
there are all sorts of grey areas, because of type systems and such, where
not all of a language's data type system is encompassed by its code.
Perhaps this sort of variability in reflective pureness relates closely to
our goal with Tunes, but an immediate formulation of this idea is not
obvious to me.

>-- 
>Massimo Dentico

~