Re: [stack] things

spir wrote:
> All those talks about concatenativity let me "dream" about a tiny
> language designed only to exhibit some properties -- or the lack of
> them. An attempt to have a base of concrete ;-) facts to reason.
> Here a kind of informal description I wish you experimented language
> designers will comment & criticize; before I really start a foolish
> implementation. It may be written in Io (using a modified version of
> IoPEG, see http://code.google.com/p/iopeg/), for I'm learning this
> language.

Sounds like fun; I hope you enjoy it.

> Then I intend to explore how modifications will let the language get
> or lose this one or that one property.

I agree that you'll learn something from this. Nowak is right that
you'll also learn something valuable from using a good concatenative
language, so you may want to start by coding something in a known-good
concatenative language -- perhaps it might be worthwhile to code your
new language in Factor or Joy. I'd say that Factor is the more practical
choice, given the amount of documentation and libraries.

> -3- single data type: "thing"
> This is a kind of tree which nodes can have any number of leaf or
> branch children. Or a nestable list. (If someone would try to explain
> me, outside the list, the difference between a tree and a recursive
> list -- thanks a lot ;-). Meaning something like

There's no difference. Some trees can have limitations that lists don't
have; but every list is also a tree.

> -4- plain text data
> Basically, things are internally stored as plain text the same way
> they are literally expressed in source code (thinking at TCL). Wich
> should be the Lisp-like (...) expression above.

I hate this. It's your choice, but I don't think this is one of the
pleasant features of TCL.

> -5- one unique "operational" primitive word: "write"
> Write will take the topmost item on the stack and write it out into a
> tree view like shown above.

Not unique. Most interactive languages have a "show top stack item"
function. Traditionally it's named "." (Forth, I believe, started that
tradition).

> -6- every action is explicitely word call
> There are some "meta-primitives", first of all push and pop that must
> be expressed. Things read (or produced by possible future words) go
> into an accumulator. Push moves them from the accumulator to the top
> of the stack. Pop removes the topmost item. Do "does" code that should
> be on the stack (if the code is a defined word, it may be referenced
> instead).

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

Many Forth processors DO have accumulator registers, but they
automatically merge them with the stack. I don't see why you'd use one.

> 	:writeOne 1 write
> in Forth could written
> 	writeOne : 1 push write push do pop pop

In Forth that would be

: writeOne 1 . ;

> An intriguing idea is to change Thing's structure into a kind of
> nested record (or dict), or named tree, where nodes have
> keys/names/indexes. Like for instance:
> (point:(kind:center position:(33 99) color(127 0 255)))

I heard of one language that does this (I lack the time to search, but
it's a derivative of LISP that processed dictionaries instead of lists).
It's interesting to try to imagine what would happen if you attempted to
execute a dictionary -- what would named elements of the dictionary do?

> [I do not know how to call such a mix of record and list.]

It looks like a record that maps from symbol/string to "item"s. By the
way, I would recommend you name "item" something more standard and
descriptive -- if it's always a list, you might as well call it a list.

> Then a word definition written as
> 	name:(block)
> directly maps to a thing literal without any word-name data item: the
> word's name is the top-level key of the thing.

That's one thing you could do, but it doesn't tell you what happens if
someone types:

name:(some thing with:(something else))

I don't know if you care. I don't, except for idle curiosity.

> denis

-Wm