Re: [stack] adding construction to Joy-like languages

On Jan 1, 2009, at 12:23 AM, Daniel Ehrenberg wrote:

> Factor can, in fact, do all of these things within the typical stack  
> model

Factor is a flexible, reflective language that can be coerced into  
doing almost anything. I'm sure you can embed a nice Lisp or Prolog  
(if you already haven't) that works well with the stack. All you'd be  
doing though is implementing another language inside Factor.

> though I've never needed any of them in practical programming problems

That doesn't mean much. Insert your own "user X of language Y without  
feature Z never needed feature Z" analogy.

>> 1. The single form of construction handles any number of inputs and
>> outputs properly. In contrast, a family of cleave combinators is
>> needed. Factor has "smart combinators" that rely on the types of the
>> functions involved to get around this, but they're quite awkward in
>> comparison to FP's approach.
>
> Could you elaborate on why this is insufficient? Maybe it can be
> remedied, if there's a specific use case you can show.

1. They don't work unless the stack effects are known at the point of  
use.
2. They're meta-level constructs that rely on reflection.
3. They don't have any useful algebraic properties.
4. They can't be typed.
5. Their semantics are very complicated compared to construction.

>> 2. FP has functions which, given a list, return a single element from
>> that list. Factor has no way (that I know of) to index into a stack
>> returning only the element selected.
>
> There's npick, which copies the nth item from the top of the stack on
> to the top, given an integer parameter (IIRC). If you follow that by [
> clear ] dip, then that'll be all that's on the stack.

Good point. I doubt such a style would be remotely efficient in Factor  
though.

>> 3. FP uses lists to group more than one element. As such, you can do
>> something like '[sq, dup]:5' to get '<25, <5, 5>>'. Emulating this
>> behavior is nearly impossible in Factor because all values are  
>> carried
>> inside a stack. As such, you must either return a flat stack like '25
>> 5 5' (which is what '[sq] [dup] bi' would do) or return all stacks
>> independently like '{25} {5 5}' which makes getting at the values
>> painful. I've mentioned this problem earlier but I'm not sure if I'm
>> explaining it adequately.
>
> A better solution is to use an explicit array for problems like this.

Not for the problems I'm looking to address:

1. You'd still need a family of combinators. Smart combinators are not  
a good solution (as I explained above).

2. You're talking about doing something in an ad hoc manner when it's  
convenient. Such an approach doesn't give you any of the guarantees  
that I'm looking for, namely a syntactically obvious number of  
produced and consumed values. Again, with the vector approach I  
suggested, 'x [|f, g, h|]' always yields '(x f) (x g) (x h)'. You  
can't get that sort of rule by altering your programming style.

> I don't understand how the dataflow of a complicated function could be
> represented with the vector system. I don't remember large functions
> in the FP paper, just things like matrix multiplication.

Here's an implementation of FP (with a funny syntax) that comes with a  
number of examples (including a DFT implementation):

    http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/impl/fp_lp/fp/

Additionally, large programs have been written in J using a tacit  
style. I think that's sufficient evidence that the approach is feasible.

- John