Ramblings about lists of values and lists of programs:
There has been some discussion as to whether in Joy-like language [1 2] is a
list of values, or a list of programs. The answer for many is "both". I can
understand the appeal of saying that a value is also a function, however
I still find that dissatisfactory for several reasons. When developing a
type-system it becomes challenging to incorporate the duality of a value and
a function. Perhaps there is a way around this, but for me, the problem is
efficiency when compiling to machine code. When compiling then, it is
neccessary to have two representations of [1 2] or to do an on the fly
conversion from value to opcode.
As way of solution I have opted to take the approach that in Cat
programs, [1 2] is a program containing two operations, push_int(1) and
push_int(2). I use a list execution operation ($) to allow programmers to
convert it to a list of values.
This makes compilation and optimization much easier because every list is
now known to be a program. So [1 2 add] can actually be reduced to [3]
without changing the meaning of the program.
However there are now some new problems. If the compiler reduces [1 2 add]
to [3], the program [1 2 add] size becomes equal to 1, where it previously
was 3.
At this point I realize that [1 2] can not have the same type as list of
programs. Instead it makes sense to call it a quotation, and give it a
separate type, and separate operations.
So that's where I'm at for now. Maybe someone has some new light to shed on
the topic.
Thanks,
Christopher
[Non-text portions of this message have been removed]
Christopher Diggins scripsit:
> Perhaps there is a way around this, but for me, the problem isI think having two representations is indeed a good idea, with a
> efficiency when compiling to machine code. When compiling then, it is
> neccessary to have two representations of [1 2] or to do an on the fly
> conversion from value to opcode.
weak hashtable to connect the list object to the compiled-code object
(so that if the list object is GCed, the compiled-code object will
be forgotten). In that way, any operation such as "first" will
operate correctly on the list object, whereas an operation like "i"
can find the compiled-code object indirectly through the hashtable.
This also allows code like "[1 2 3] rest i" to work correctly;
the quotation "1 2 3" will be compiled, "rest" will operate on the
list object giving it "2 3", and when "i" finds that this list
does not have a compiled equivalent, it will compile it and register
the compiled-code object in the hashtable.
Doing it this way preserves full Joy semantics.
--
John Cowan cowan@... http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1. I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
http://math.boisestate.edu/%7Eholmes/holmes/sfdocs.pdf
an interesting concatenative language by set theorist Randall
Holmes.