Self is not against Forth [was: Re: HLL is not against LLL]

[Rainer Blome]

faré,

i just realized that you already talked about bootstrapping in your message
from july, 18th.  it had rotted so long in my inbox, it already smelled.
;-)

> The LLL is just a way to bootstrap the HLL, both as implementation and
> target language, much like a FORTH kernels extends into whatever language
> you want. [...]  The compiler is implemented in a restriction of the HLL,
> which is built as an extension to the LLL.  [...] using a self-extensible
> LLL to bootstrap the HLL. Again, a self-extensible LLL is to me some good
> alternative to an explicitly bytecoded system (the LLL could be bytecoded
> itself, or threaded, or translated to native code).

agreed.

>>> But they are unextensible, unadaptable LLLs. I prefer
>>> using some FORTH-like LLL, so it can adapt to the hardware (easy to
>>> add words written in assembly) [...]

why should it be easier to assembly-write forth words than code for other
languages, e.g. self methods?

patrick wrote:
>> Writing the HLL compiler in a language without an object system makes
>> it more difficult to modify.

you replied:
> Why wouldn't objects be expressed easily in some proper extension to
> the LLL ? See object extensions to FORTH (MOPS, OOF).

i don't know these extensions, just i don't want the objects to be an
extension.  i want objects all the way down like patrick does.


maybe the two paradigms are not that far from each other.  can we integrate
them?  let's see!


  would a forth that uses objects for stacks still be a forth?

  not really.  a forth with multiple stacks (each one representing an
object) and some way to name stack positions would be changed beyond
recognition.


  would a self that uses stacks for objects still be a self?

  it certainly wouldn't _be_ a a self, but maybe it'd feel like one.

  hmm.  do we really need names for the slots?  are indices sufficient to
  refer to slots/stack positions?  if the order of an object's components is
  fixed, yes. (with names, as in self, it doesn't matter.)

  the lowest element on a stack could play the role of a parent
  slot and point to another stack. this way you share stuff.

  no need to `allocate activation records _from_ a stack'.  there's just a
  set of stacks and the activation records are part of them, the _are_
  stacks.

  without names for words, there'd be no word stack.  you'd have to know
  where the word is in the stack world.  (i assume that forth compilers
  work by inlining the stack index of words by looking them up at
  compilation time.  is that true?  requires the depth of stacks to be
  immutable.)

  of course, such a language would be difficult to program in without a
  compiler.  so the first compiler is written in another language, no
  problem.

  seems to extend to real self trivially.  (but probably isn't ;-)

  
is this totally wacko?  has this been done already?  (i already mentioned
that i don't know the forth extensions.  actually, i still don't know
modern forth as well.  )


rainer