CLIP some more!

[iepos@tunes.org]

It looks like this discussion (on applicative systems) has
pretty much settled down...

> >For instance, how might I formalize a
> >"divmod" function, that takes a couple numbers and yields both 
> >the result of their division and the remainder?
> 
> >The best way I can think of to formalize it is as a function
> >that takes three parameters: a "continuation" function (which the
> >two results will be applied to), and the two numbers. [...]
> 
> Now this is a confusing and interesting problem.  My personal feeling is
> that it's wiser to restrict functions to returning exactly one value; that
> single value may be a tuple.

In an applicative system, that may well be the best approach.
And, by the way, a function that takes a continuation and passes
some values to that continuation makes a good substitute for a tuple.
For instance, the function that takes a function "f" and yields
"f 2 3 4" is a good way to emulate the tuple "(2,3,4)". So maybe
it would be best to make "divmod" yield this kind of tuple of the
two numbers...

> Here's another idea: write a language which contains two distinct parts: one
> mapping language and one procedural language.  The mapping language is your
> original functional language; the procedural language is some ideal
> concatenative language.

Hmm... Not sure about this...

> [dishware, numlock lights, etc.]
> 
> The problem with it is that you assume
> that name-based functional and object oriented styles can be combined
> seamlessly and without effort on your part.  This assumption has been proven
> false so many times in so many different languages it's a little scary.

Well... maybe this would be a problem, then...

> >What do you think... ?
> 
> I know which one I would prefer to work with -- the unified list, all the
> way.  There's just no way I'd want to deal with a whole bunch of
> variable-stack-effect words.

Hmm... I'm pretty sure I want the variable-stack-effect words whether
or not I also have unified lists... Surely one would like to have
"dup2", "dip2", "sip2", and such, and probably similar things for "3".
It would seem inelegant to me to have support for "2" and "3" versions
without making a general version.

If I do end up using unified lists (and this is likely), the main
primitives will just be "wrap" and "unwrap" (in the absense of
"reverse", "map", "concat", and things)... If one wants to do
more complex things with lists, then the thing to do is to unwrap
them first and then use the variable-stack-effect words (and
then wrap it back up again, if needed) ...

The reverse approach (getting rid of many stack-manipulating constructs,
in favor of list ones) might also work, I suppose...

> >- "iepos" (Brent Kerby)
> 
> -Billy

- "iepos" (Brent Kerby)