Re: [stack] adding construction to factor

On Jan 4, 2009, at 11:31 AM, William Tanksley, Jr wrote:

>> It  treats stacks as if they were vectors in More's array
>> theory, e.g. '5 == {5}'.
>
> Is "stacks" a typo here?

Ah, perhaps. I suppose Factor calls them "arrays". I was thinking  
"stacks" because I was using them as such.

What I essentially mean to say is that construction needs a single  
array of values to operate on. If you give it a non-array, it'll  
bundle it into a one element array for you (else it won't touch it).  
For each value that results from the construction, it will convert one  
element arrays to just the elements they contain non-recursively (else  
it won't touch them).

That's not exactly how More's theory works, but it seemed to make a  
little more sense to do it this way given that I'm grafting it onto a  
stack-based language. Ideally, you'd base the whole language on  
vectors instead of stacks which would give you a nice syntax for  
conveying the semantics. For example, if parentheses represented  
vectors, I could write the semantics very simply:

    x [(F)]   == (x F)
    x [(F,G)] == (x F) (x G)
    ...

>> 5 [( sq , dup , neg , drop ])  ==  25 { 5 5 } -5 { }
>> 5 3 2@ [( + , - )]  ==  8 2
>> 5 [( 5 + , 5 - )]  ==  10 0
>
> Yes; that's nice and clear. It occurs to me that this is a parallel
> execution operator.

Aye. Unlike with cleave, there's no way the quotations can interact  
here (barring side-effects). Even the type system I have cannot  
prevent interaction from occuring in cleave; I'd have to add row  
variable concatenation to be able to handle it (where '0' is the empty  
row and '++' is concatenation):

    bi :: R x [R x -> S] [0 x -> T] -> S++T

Compare this to the usual type for 'bi' (which allows the second  
quotation to access the result of the first):

    bi :: R x [R x -> S] [S x -> T] -> T

Anyway, I'm thinking of writing up an interpreter for a Joy-like  
language that uses vectors instead of lists and separates vectors from  
quotation. Both changes should make it easier to do parallel  
reduction. The change to vectors should make it easier as it makes  
construction more useful and construction enables parallel evaluation  
as you already discovered. Separating vectors from quotations and  
making quotation opaque will help as it's not generally legal to  
simplify a quotation in Joy. This is because '[1 2 +] != [3]' as you  
could always use it as a list instead of a quotation later on and  
they're obviously not equivalent lists. Making it impossible to peek  
inside a quotation solves this problem.

- John