Re: [stack] disallowing recursive definitions

On Mar 19, 2008, at 19:30 , Manfred Von Thun wrote:
>
> On 8/3/08 3:03 AM, "John Cowan" <[email protected]> wrote:
>>
>> ....
>> Assembler: the ultimate concatenative language....
>
> Indeed, except for those jumps, as of course you know. But the
> mention of assembler triggers an old memory about something
> I have wanted to write about for some time. It concerns not
> so much the high or low level of a concatenative language,
> but what its shortest programs are whose concatenation
> computes the composition of what those shortest programs
> are. In just about all concatenative languages the shortest
> programs are atoms like swap, +, map, 123, “hello”, [a b],
> the first three operators and the lest three push-ops. It is
> from atoms such as these that programs are constructed by
> concatenation. But could there not be small programs, not
> formed by concatenating with others to form their composition,
> which nevertheless have parts: MOLECULES
>
> An assembly program consists of a sequence of lines, each
> holding one instruction, to be executed in sequence unless
> intercepted by a jump instruction. Each instruction produces
> a change somewhere, and the concatenation of the lines
> produces the composition of the changes. But instructions
> have part, too. They consist of an operator such as mul, fetch,
> store, ..., each followed by several inscrutables having to
> do with where things come from and where they should go.
> So an instruction is a sort of molecule composed of several
> atoms. Now think of concatenative languages in which programs
> are concatenated from molecules, each consisting of an
> operator (like swap, + etc) together with additional parts
> that complete what is meant. Note that the additional parts
> are not further parameters that should be taken from the stack.
> What useful additional parts may there be?
>
> I would take a hint from unix,

It occurred to me a while back that the stack is to concatenative
languages as a pipe is to Unix programs and shell scripts.


> which has a rich collection of
> what are called filters, programs that take one input fil and
> produce one output file. The names of such programs, foo, bar,
> baz and zot, can be concatenated to form what is called a pipe:
> (here i dare not think what my mailer will do with the vertical bar)
>
> foo | bar | baz | zot
>
> and this concatenation will take one input file and produce one
> output file such that ... You guessed it. But each of these programs
> may have a useful default behaviour and also allow switches to
> modify the default. The switches are typically single letters
> precededd by a minus sign. So the pipe might actually look like
> this:
>
> foo –a –g | bar –x | baz -e –q –w –e –r | zot –m –d
>
> So in the terminology I am tempted to adopt, here we have
> the concatenation of four molecules or instructions,
> where the first instruction consists of  three atoms, namely
> a program and two switches.
>
> Apart from the pipe of output-input files, it may be necessary
> to use other files, and there are lots of ways of doing that.
>
> The upshot: have we in the concatenative world missed out
> on something useful by not allowing parts to the smallest
> programs. There is a lot one could and should discuss here,

Agreed!
--
don


> but not me, not tonight.
>
>   - Manfred
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/concatenative/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/concatenative/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/