Re: [stack] things

spir wrote:
> William Tanksley <[email protected]> s'exprima ainsi:
> By the way, I have another issue with "code is data". Code is always
> valid data -- but is the converse statement true?

Trivially, no. Data will in general error out if you try to execute
it. :-)

More interestingly, it is possible to build a system in which all data
is always valid code, as long as you allow non-termination and data out
of range errors like division by zero or empty-stack in "valid code".
It's necessary to have the code format be entirely flat (non-nested) so
that you can't possibly have syntax errors. It's also essential to
accept the entire input token set, obviously. The simplest way to be
100% sure that every token is always acceptable would be to tokenize
down to bytes or even bits (and then define the meaning of every
possible token), rather than down to words (which limits you to only
words that are listed in some arbitrary dictionary).

In other words, you'd have to build a bytecode interpreter.

> > Why do you have an accumulator? Why not just use the stack directly?

> Again the purpose is primarily self-pedagogical: to make it explicit
> that everything is an action/word/function:

I truly don't understand how making literals _not_ be a function (?)
will help you understand how everything is a function. It looks like
you're designing a language with a deliberate, obvious mistake baked
into it in order to help yourself see why it's a mistake. If that's your
goal, feel free, but I don't see how it's going to teach you anything;
the process of coding anything in the resulting language will be utterly
forbidding, since the trivial mistake of forgetting to push will be
silently ignored for no obvious reason. That mistake (forgetting to
push) seems unrelated to the mistake you're trying to understand (not
making everything a function).

> Then again I will get rid of this requirement in favor of a Forth-like
> behaviour were literals (including code expressions) are implicitely
> pushed.
> One may also read that () means push -- but in fact parens are rather
> useful for "things" are inherently composite (and nestable): it make
> clear the difference between eg "(1 2)" and "(1) (2)" while without
> parens both would read "1 2".

Again, I have no clue whatsoever why you need to have _anything_ "mean"
push. The word "push" has no meaning whatsoever if you lack an
accumulator. I'd need to have some introduction to the value of having
an accumulator; the problems are painfully obvious to me, while the
value remains entirely obscure.

> I read something about a data type that gets rid of the distinction
> between a "1-uple" (how do you call tuples of length 1 in english?)
> and the single item it holds but I can imagine it practically. Also, a
> 0-uple should be (equal/identical to) 'nothing'?

1-tuple and 0-tuple.

Yes, you can implicitly wrap and unwrap 1-tuples if you want (there are
consequences, but I think you'd learn more by experiencing them), but
you can't automatically unwrap a 0-tuple -- what would fall out of it?
In Lisp, a 0-tuple is special. In NIAL there are actually two entirely
different languages that depend entirely on what type a 0-size array is
(is it an array containing nothing of any type, or is it an array
containing nothing of a specific type?).

-Wm