types and operators

[Francois-Rene Rideau]

>:spc
>>:utsl
>>>:Eric
>>>>:utsl
>>>>>:Eric

[Tagging type of values with a (1) bit or (2) a cell]

Note that option (4) is to tag not individual values, but structures,
which again can be done with a count, bitmap, set of function, etc.

[About option 2]
>>> That's the problem.  You will use those.  The code we write, or the
>>> techniques we chose will not resemble those of Forth.  If our guide
>>> for the LLL is to be Forth it should be essentially Forth.  Under
>>> Option 1 we can write a GCing ANS Forth as fast as any other.  Under
>>> this plan who knows what we will write but it won't be Forth.  Further
>>> the compiled code will be implemented quite differently.
>>>
>   There is Forth, and then there's Forth.  I've implemented a Forth-like
> language that is precicely that, Forth-like.  It's not Forth.  And the next
> revision of that language is even less like Forth (or more like Forth than
> Forth is) yet the ability to have ANS Forth code is possible (I have a
> problem with the way ANS Forth defined flow control words, but that's due to
> prior art in Forth systems - I won't let that stand in the way of a nice
> implementation 8-)
> 
>   I might want to ask:  What is Forth?  Is it the idea of a stack based RPN
> language?  Or is it what ANS Forth is?  Or F-83 or Forth 83 or Forth 79 or
> ...
>
Yeah. We shouldn't focus on ANS. ANS is good for what it's meant:
standardizing the various existing FORTH languages for their common usage,
that is embedded system and small static software.
Here we mean something much more dynamic.


>>> My point is we'll get lost in this implementation and never get
>>> anywhere as Fare was in M4 and assembly.
again, :( :( :( :( :(
>>
>> You're probably right there... I still think it would a very interesting
>> idea, but I'll agree to go with option 1 for the initial implementation,
>> as you describe it. Sounds good to me.
>>
>   I disagree.  Option 2 is much better in the long run (and TUNES is a
> Useful, Not Expediant System, although at times it certainly seems as if
> everyone is trying for an Expediant system).
>
>   Sure, you loose memory, but you gain a mich finer control of type
> information (in fact, who's to say that the type information is a series of
> bits, it could be the address of a function, say), and once you know the
> code works with static types (i.e. code where the type information is
> determinate and doesn't chance from run to run) then you can remove the type
> checking code and the types themselves!  And you never loose precision in
> your integers, characters, pointers or floats.
>
I admit option 2 mustn't be unjustly neglected,
but I'm not convinced that it is better in the long run:
* you can never remove all type information from data elements,
 because the GC will always need to differentiate pointers from integers.
* when there's dynamic type information, I quite prefer the
 indirection being from the descriptor to the data cell than
 from the data cell to the descriptor:
 this allows to share data cells for multiple objects,
 to dynamically traverse a structure using space only for
 the particular objects being inspected, etc.
* having bit-tagged values as the default doesn't prevent having
 full precision objects and/or untested pointers as boxed values;
 that is, it ain't incompatible with option (4),
 and the combo seems much efficient to me than option (2).

My conclusion is that I guess that option 1 should be better in most cases,
but I'm asking for precise measurements before anyone can affirm whether
or not this is the case.


>> Some of
>> the HLL people might like the Lispish Forth better.
>> (Big surprise that'd be.)
>
>   I'm not one of the HLL people and I like the Lispish Forth better (since
> that's seems to be the way my Forth-like lanaguage is headed).
>
I'm not sure what you both call "Lispish Forth"...


>   -spc (And Postscript is more Forth than Forth is ... )
 Still, Postscript has some deep flaws (mostly lack of scoping),
that make it useless for higher-order programming.
Note: Postscript level 2 does have GC...
Maybe we should start from Postscript rather than FORTH...

Thinking about getting the (huge, because of drawing primitives)
Postscript specs,

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"