are concatenative languages applicative?

John Nowak — 2008-04-24 22:10:13

Apologies for starting a new thread of sorts, but the "Object Cat"  

thread already had run through three or four different topics, and it  

seems like a good idea to discuss this in such a way that it'll be  

archived properly. I'd really like an answer here.



First off, let me say that I'm not particularly interested in if Joy's  

'i' is an 'eval'. This does, as Chris pointed out, seem to get us  

bogged down in implementation details. As far as I can tell, 'eval' is  

defined to be some procedure that works on code, be that code a string  

or some more structured form of data. In a language like Cat, there's  

no such code being passed around as there is in Joy, and I don't think  

there's anyone here who would say Cat isn't concatenative.



What I'm interested in is this "dequotation" rule:



    [$A] i  ==  $A



In other words, these are all equivalent:



    1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i



An important thing to note here is that this translation is just a  

rewriting of function-level code. '$A' is a function, not a value.   

This seems fundamentally different from this rule in the combinatory  

calculus, where 'x' is a *value*, not a function:



    (I x)  ==  x



(William already has said essentially the same thing with respect to  

operators and operands.)



I guess my questions are as follows: Are concatenative languages  

applicative, and if so, what's the equivalent of '[$A] i == $A' in the  

lambda calculus? If such a translation cannot be given, does that mean  

concatenative languages are non-applicative? If so, is there another  

term besides "concatenative" that can be used to describe their  

properties?



- John

John Cowan — 2008-04-24 22:47:56

John Nowak scripsit:



 > What I'm interested in is this "dequotation" rule:

> 

>     [$A] i  ==  $A

> 

> In other words, these are all equivalent:

> 

>     1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i

> 

> An important thing to note here is that this translation is just a  

> rewriting of function-level code. '$A' is a function, not a value.   



 
Well, yes and no.  In Joy, at least, *everything* is a value, and

every value may be applied to the stack.  So [1 2 3] is the value

"the list containing 1, 2, and 3" where 1, 2, 3, and the list itself

are just values.  Only when we apply i (which itself is just a symbol)

to a stack with [1 2 3] at the top of it are 1, 2, and 3 applied

to the rest of the stack.



This is quite different from Cat (or Scheme) where some values are

applyable and some are not.



-- 

Mos Eisley spaceport.  You will never           John Cowan

see a more wretched hive of scum and            cowan@...

villainy -- unless you watch the                http://www.ccil.org/~cowan

Jerry Springer Show.   --georgettesworld.com

John Nowak — 2008-04-24 23:39:09

On Apr 24, 2008, at 6:47 PM, John Cowan wrote:



 > John Nowak scripsit:

>

>> What I'm interested in is this "dequotation" rule:

>>

>>    [$A] i  ==  $A

>>

>> In other words, these are all equivalent:

>>

>>    1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i

>>

>> An important thing to note here is that this translation is just a

>> rewriting of function-level code. '$A' is a function, not a value.

>

> Well, yes and no.  In Joy, at least, *everything* is a value, and

> every value may be applied to the stack.  So [1 2 3] is the value

> "the list containing 1, 2, and 3" where 1, 2, 3, and the list itself

> are just values.



 
We need to be more careful. Joy programs are expressed entirely in  

terms of functions. Joy is a function-level language. I'll give three  

examples to make this clear:



- '[1 2 3]' is a *function* of type 'A -> A [B -> B Num Num Num]';  

when evaluated, it pushes the *value* [1 2 3] of type '[A -> A Num Num  

Num]' onto the stack



- '1 2 3' is a *function* of type 'A -> A Num Num Num'; when  

evaluated, the *values* 1, 2, and 3 get pushed onto the stack



- '3' is a *function* of type 'A -> A Num', not a value of type 'Num'  

as in Haskell or ML; when evaluated, the *value* 3 gets pushed onto  

the stack



In short, even '3' is a function in Joy. This should be obvious as we  

can assign a name to it:



    foo = 3



Here, we're not binding 'foo' to the value of 3; we're declaring that  

'foo' is a function that pushes '3' onto the stack. According, in the  

expression 'foo foo +', we can substitute 'foo' for it's definition,  

yielding '3 3 +', which then evaluates to '6'. Never at any point are  

we manipulating values.



So this gets me back to my question...



- John

Don Groves — 2008-04-25 01:58:18

On Apr 24, 2008, at 3:10 PM, John Nowak wrote:



 > Apologies for starting a new thread of sorts, but the "Object Cat"

> thread already had run through three or four different topics, and it

> seems like a good idea to discuss this in such a way that it'll be

> archived properly. I'd really like an answer here.

>

> First off, let me say that I'm not particularly interested in if Joy's

> 'i' is an 'eval'. This does, as Chris pointed out, seem to get us

> bogged down in implementation details. As far as I can tell, 'eval' is

> defined to be some procedure that works on code, be that code a string

> or some more structured form of data. In a language like Cat, there's

> no such code being passed around as there is in Joy, and I don't think

> there's anyone here who would say Cat isn't concatenative.

>

> What I'm interested in is this "dequotation" rule:

>

>    [$A] i  ==  $A

>

> In other words, these are all equivalent:

>

>    1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i

>

> An important thing to note here is that this translation is just a

> rewriting of function-level code. '$A' is a function, not a value.

> This seems fundamentally different from this rule in the combinatory

> calculus, where 'x' is a *value*, not a function:

>

>    (I x)  ==  x

>

> (William already has said essentially the same thing with respect to

> operators and operands.)

>

> I guess my questions are as follows: Are concatenative languages

> applicative, and if so, what's the equivalent of '[$A] i == $A' in the

> lambda calculus?



 
As I understand it, the lambda calculus form  \X.E  represents an  

abstraction

(\X) and an application (E). Seems to me a straightforward reading of  

Joy's

[foo] as an abstraction and i as being/causing an application is the  

equivalence

you seek. Joy's i and lambda calculus' dot perform the same function  

in their

respective languages.



Am I the only one here who thinks the word "function" has too many  

meanings?

--

don





 > ...If such a translation cannot be given, does that mean

> concatenative languages are non-applicative? If so, is there another

> term besides "concatenative" that can be used to describe their

> properties?

>

> - John 

Don Groves — 2008-04-25 02:26:59

On Apr 24, 2008, at 6:58 PM, Don Groves wrote:



 > On Apr 24, 2008, at 3:10 PM, John Nowak wrote:

>

>> Apologies for starting a new thread of sorts, but the "Object Cat"

>> thread already had run through three or four different topics, and it

>> seems like a good idea to discuss this in such a way that it'll be

>> archived properly. I'd really like an answer here.

>>

>> First off, let me say that I'm not particularly interested in if  

>> Joy's

>> 'i' is an 'eval'. This does, as Chris pointed out, seem to get us

>> bogged down in implementation details. As far as I can tell, 'eval'  

>> is

>> defined to be some procedure that works on code, be that code a  

>> string

>> or some more structured form of data. In a language like Cat, there's

>> no such code being passed around as there is in Joy, and I don't  

>> think

>> there's anyone here who would say Cat isn't concatenative.

>>

>> What I'm interested in is this "dequotation" rule:

>>

>>   [$A] i  ==  $A

>>

>> In other words, these are all equivalent:

>>

>>   1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i

>>

>> An important thing to note here is that this translation is just a

>> rewriting of function-level code. '$A' is a function, not a value.

>> This seems fundamentally different from this rule in the combinatory

>> calculus, where 'x' is a *value*, not a function:

>>

>>   (I x)  ==  x

>>

>> (William already has said essentially the same thing with respect to

>> operators and operands.)

>>

>> I guess my questions are as follows: Are concatenative languages

>> applicative, and if so, what's the equivalent of '[$A] i == $A' in  

>> the

>> lambda calculus?

>

> As I understand it, the lambda calculus form  \X.E  represents an

> abstraction

> (\X) and an application (E). Seems to me a straightforward reading of

> Joy's

> [foo] as an abstraction and i as being/causing an application is the

> equivalence

> you seek. Joy's i and lambda calculus' dot perform the same function

> in their

> respective languages.

>

> Am I the only one here who thinks the word "function" has too many

> meanings?

> --

> don



 
I didn't finish answering your question: The lambda calculus equivalent

of [$A] i is \A.S where S is the stack.

--

don









 >

>

>

>> ...If such a translation cannot be given, does that mean

>> concatenative languages are non-applicative? If so, is there another

>> term besides "concatenative" that can be used to describe their

>> properties?

>>

>> - John

>

>

>

> ------------------------------------

>

> Yahoo! Groups Links

>

>

>

> 

John Cowan — 2008-04-25 02:35:46

John Nowak scripsit:



 > We need to be more careful. Joy programs are expressed entirely in  

> terms of functions. Joy is a function-level language. I'll give three  

> examples to make this clear:

> 

> - '[1 2 3]' is a *function* of type 'A -> A [B -> B Num Num Num]';  

> when evaluated, it pushes the *value* [1 2 3] of type '[A -> A Num Num  

> Num]' onto the stack



 
I deny this.  I say that the type of [1 2 3] as a value is [Int Int Int],

and as a function its type is A -> A [Int Int Int].



 > - '1 2 3' is a *function* of type 'A -> A Num Num Num'; when  

> evaluated, the *values* 1, 2, and 3 get pushed onto the stack



 
I agree with that.



 > - '3' is a *function* of type 'A -> A Num', not a value of type 'Num'  

> as in Haskell or ML; when evaluated, the *value* 3 gets pushed onto  

> the stack [...]



 
You are making a distinction between '3' and 3 that I believe to be

unwarranted.  There is only 3, and it is both a numeric value and

a function to be applied to the stack.



 > In short, even '3' is a function in Joy. This should be obvious as we  

> can assign a name to it:

> 

>     foo = 3

> 

> Here, we're not binding 'foo' to the value of 3; we're declaring that  

> 'foo' is a function that pushes '3' onto the stack. 



 
We are doing both at once.



 > Never at any point are we manipulating values.



 
The function +, among many others, can only be understood in terms

of values.



-- 

Barry gules and argent of seven and six,        John Cowan

on a canton azure fifty molets of the second.   cowan@...

        --blazoning the U.S. flag               http://www.ccil.org/~cowan

John Nowak — 2008-04-25 03:29:47

On Apr 24, 2008, at 10:35 PM, John Cowan wrote:



 > John Nowak scripsit:

>

>> - '1 2 3' is a *function* of type 'A -> A Num Num Num'; when

>> evaluated, the *values* 1, 2, and 3 get pushed onto the stack

>

> I agree with that.

>

>> - '3' is a *function* of type 'A -> A Num', not a value of type 'Num'

>> as in Haskell or ML; when evaluated, the *value* 3 gets pushed onto

>> the stack [...]

>

> You are making a distinction between '3' and 3 that I believe to be

> unwarranted.  There is only 3, and it is both a numeric value and

> a function to be applied to the stack.



 
Maybe I'm not being precise enough. The type of the term '3' is 'A ->  

A Num', just like the type of '1 2 3' is 'A -> A Num Num Num'.



 >> In short, even '3' is a function in Joy. This should be obvious as we

>> can assign a name to it:

>>

>>    foo = 3

>>

>> Here, we're not binding 'foo' to the value of 3; we're declaring that

>> 'foo' is a function that pushes '3' onto the stack.

>

> We are doing both at once.



 
No we're not; we don't evaluate the right-hand side to figure out what  

to bind 'foo' too.



 >> Never at any point are we manipulating values.

>

> The function +, among many others, can only be understood in terms  

> of values.



 
Sure, but when we're manipulating programs, such as translating '1 [2  

+] i' to '1 2 +', we're not manipulating any terms bound to values.



- John

John Cowan — 2008-04-25 03:56:31

John Nowak scripsit:



 > Maybe I'm not being precise enough. The type of the term '3' is 'A ->  

> A Num', just like the type of '1 2 3' is 'A -> A Num Num Num'.



 
That is, those are their types when they are seen as functions.  When

seen as values, their types are 'Num' and 'Num Num Num'.



 > No we're not; we don't evaluate the right-hand side to figure out what  

> to bind 'foo' too.



 
Correct.  The declaration "foo == 3" means that as functions 'foo' and '3'

have the same function type, namely 'A -> A Int'.  (As values, they are

still different:  '3' has type Int, 'foo' has type Symbol.)



But where we differ, or did differ, is about '[1 2 3]', which I say has a

function type of 'A -> A [Num Num Num]', not 'A -> [A -> A Num Num Num]]'.

And that is because Joy lists are not inherently quotations, though they

are treated as quotations by certain functions.



-- 

Man has no body distinct from his soul,                 John Cowan

for that called body is a portion of the soul           cowan@...

discerned by the five senses,                           http://www.ccil.org

the chief inlets of the soul in this age.  --William Blake

John Nowak — 2008-04-25 04:10:34

On Apr 24, 2008, at 11:56 PM, John Cowan wrote:



 > But where we differ, or did differ, is about '[1 2 3]', which I say  

> has a

> function type of 'A -> A [Num Num Num]', not 'A -> [A -> A Num Num  

> Num]]'.

> And that is because Joy lists are not inherently quotations, though  

> they

> are treated as quotations by certain functions.



 
Well, to be clear, I said A -> A [B -> B Num Num Num]. Either way, I  

should've said that I don't give a damn about Joy, but rather  

concatenative languages in general. I think I've answered my own  

question anyway: No, they're not applicative.



- John

Manfred Von Thun — 2008-04-30 04:25:09

On 25/4/08 11:58 AM, "Don Groves" <dgroves@...> wrote:



 > On Apr 24, 2008, at 3:10 PM, John Nowak wrote:

> 

>> > First off, let me say that I'm not particularly interested in if Joy's

>> > 'i' is an 'eval'. This does, as Chris pointed out, seem to get us

>> > bogged down in implementation details.

> 

 
Emphatically, it is not an implementation detail. Any programming

language ultimately runs in machine language, which is sequential

(with jumps, though). At intermediate levels it can be implemented

in functional or in procedural languages. Any functional language

can be implemented in a functional or a procedural language, or

by rewriting ­ even concurrent rewriting. The details of the rewriting

will depend on the syntax of the functional language. For a

concatenative language, here is a (crazy, but correct) algorithm

for rewriting an expression in the language, using several clerical

workers concurrently:

 > 

 
REPEAT:

    The workers at random select an operator in the expression.

    If it is immediately preceded by the appropriate number of

    operands, replace the operands and the operator by a value.

    (For example, (... 2  3 +  ...) is replaced by (... 5 ...).)

UNTIL there are no more operators in the expression

 > 

 
This is a way of implementing any concatenative language, even

if crazy. The usual stack implementation of concatenative languages

is just an efficient way of finding operators that are immediately

preceded by their operands.



Whether Joy¹s i combinator is an eval is a semantic question that

is independent of the implementation, whether by stack or by

rewriting.

 > 

 
 - Manfre





[Non-text portions of this message have been removed]

Manfred Von Thun — 2008-04-30 05:48:22

On 25/4/08 8:10 AM, "John Nowak" <john@...> wrote:



 > [..]

> What I'm interested in is this "dequotation" rule:

> 

> [$A] i  ==  $A

> 

> In other words, these are all equivalent:

> 

> 1 2 [3 * *] i  ==  1 2 3 * *  ==  1 [2 3] i [* *] i

> 

> An important thing to note here is that this translation is just a

> rewriting of function-level code. '$A' is a function, not a value.

> This seems fundamentally different from this rule in the combinatory

> calculus, where 'x' is a *value*, not a function:

> 

> (I x)  ==  x

> 

 
Indeed, they are different, and there is no exact equivalent because the

combinatory calculus does not have any kind of quoting mechanism.



Incidentally, the quote/eval relationship holds in any language

that has these two operators, where eval is essentially dequote

(I did not invent the term dequote, it is used by semanticists as in

the first example:)



    eval(quote(snow is white) = (show is white) = true

    eval(quote((2 + 3) * 4)) = ((2 + 3) * 4) = 20



 > I guess my questions are as follows: Are concatenative languages

> applicative, ....

> 

 
The ones I know about do not have an explicit application operation

(unlike +). Nor do they have an implicit application operation

(unlike function composition).



The semantics of function composition can be explained in terms

of application (apl):



     (A B C..)  apl  X  =  (B C..) apl (A apl X)

     () apl X  =  X



This is quite general, independent of what sort of a thing X

might be. It also holds for languages which have function operations

other than function composition. But it is independent of how

the language is implemented. It is true that for implementations

of concatenative languages the X is invariably a stack and the

two clauses above are at the heart of the implementation.



 > .... and if so, what's the equivalent of '[$A] i == $A' in the

> lambda calculus? ....

> 

 
There is no equivalent. Lambda calculus, like combinatory

calculus, does not have a quote operator. The equivalent of

your combinatory calculus (I x) = x is of course (lambda x. x).

 > 

> ....If such a translation cannot be given, does that mean

> concatenative languages are non-applicative? ...



 
Having the quote/eval pair (or a syntactic variant) should not be

part of the definition a concatenative language. The two issues

(of quote/eval pair and concatenativity) are entirely independent.

So the lack of such a translation does not ..mean.. that concatenative

languages are non-applicative.



Nevertheless concatenative languages ..are.. non-applicative.

The lambda calculus and its derivatives (Lisp) are applicative,

and so is the combinatory calculus. Both have the important

operation of applying a function to arguments(s). Lambda calculus

also has function abstraction, combinatory calculus does not.



 > 

> ... If so, is there another

> term besides "concatenative" that can be used to describe their

> properties?

> 

 
Billy Tanksley invented the term when he founded this group.

(thanks William). I prefer his term to the ludicrous alternative:



Language-in-which-the-associative-operation-of­program-

concatenation-denotes-the-associative-operation-of-function-

composition-as-the-principal-program-forming-construction.

 > 

 
  - Manfred

 > 







 
[Non-text portions of this message have been removed]

Robbert van Dalen — 2008-04-30 08:24:34

> The details of the rewriting

> will depend on the syntax of the functional language. For a

> concatenative language, here is a (crazy, but correct) algorithm

> for rewriting an expression in the language, using several clerical

> workers concurrently:

> >

> REPEAT:

>     The workers at random select an operator in the expression.

>     If it is immediately preceded by the appropriate number of

>     operands, replace the operands and the operator by a value.

>     (For example, (... 2  3 +  ...) is replaced by (... 5 ...).)

> UNTIL there are no more operators in the expression

> >

> This is a way of implementing any concatenative language, even

> if crazy. The usual stack implementation of concatenative languages

> is just an efficient way of finding operators that are immediately

> preceded by their operands.



 
This possibility to do concurrent rewritings of expressions is the

sole reason why Enchilada has postfix syntax. Therefor I would claim

it isn't crazy at all :)



- Robbert.

Manfred Von Thun — 2008-05-13 05:45:10

Still on the topic of quote and eval, it occurred to me that the Unix

command

languages (sh, csh, ksh, bash,..) have their own eval operator. It is the

backquote mechanism, which will evaluate what is enclosed inside the

backquotes `...` (I don¹t know what my mailer will do to it, it is the key

just under escape key at the top left). Example:



echo ³Today¹s date and the current time is `date`, have a nice day!²



Here the echo means print the following message which contains a short

backquoted command. The command returns a string that will be spliced

into the message. More complex commands can be backquoted:



echo ³In your home directory you have `ls ­la ~ | wc ­l ` files²



Here the ls command produces an output which is piped (with |)

to the wordcount facility wc to count just the lines.



The beauty of the various Unix utilities is that you can pipe the output

of one to become the input to the next. The backquote substitution

can make good use of it.



Is there a lesson to be learned for concatenative languages?

We have discussed Unix pipes briefly before, and their semantics

is clear: a pipe  X | Y | Z computes the composition of the functions

X, Y and Z, just as any other concatenative language. But the

backquote is something else deserving a thorough examination.



  - Manfred







[Non-text portions of this message have been removed]

rahul — 2008-05-13 17:52:18

....

 > Is there a lesson to be learned for concatenative languages?

> We have discussed Unix pipes briefly before, and their semantics

> is clear: a pipe  X | Y | Z computes the composition of the functions

> X, Y and Z, just as any other concatenative language. But the

> backquote is something else deserving a thorough examination.



 
You may find this interesting



http://rosettacode.org/wiki/Category:UnixPipes



(Using unix pipes and files rather than the shell language).



 >   - Manfred



 
Rahul

William Tanksley, Jr — 2008-05-13 20:19:46

Manfred Von Thun <m.vonthun@...> wrote:

 > Still on the topic of quote and eval, it occurred to me that the Unix

>  command

>  languages (sh, csh, ksh, bash,..) have their own eval operator. It is the

>  backquote mechanism, which will evaluate what is enclosed inside the

>  backquotes `...` (I don¹t know what my mailer will do to it, it is the key

>  just under escape key at the top left).



>  Is there a lesson to be learned for concatenative languages?



 
I don't know what the lesson would be. Backquotes escape from a string

context to an executation/evaluation context. I suppose one could do

that in a concatenative language that had a string syntax.



More generally, I suppose one could "escape" from any context to an

evaluation, thus allowing you to compute a value at runtime which will

be compiled into the current quotation.



 >   - Manfred



 
-Wm

John Cowan — 2008-05-13 20:35:10

Manfred Von Thun scripsit:



 > The beauty of the various Unix utilities is that you can pipe the output

> of one to become the input to the next. The backquote substitution

> can make good use of it.



 
Backquotes -- as is clearly shown by the alternative syntax $(...) --

essentially belong to the lexical level of the shell, just like $name

substitution.  So they are very like Lisp macros: code inside backquotes

runs in a subshell to produce *source code* which is then evaluated by

the main shell in context, just as a Lisp macro runs in an subordinate

evaluator to generate Lisp code to be run by the main evaluator in

context.



-- 

What has four pairs of pants, lives             John Cowan

in Philadelphia, and it never rains             http://www.ccil.org/~cowan

but it pours?                                   cowan@...

        --Rufus T. Firefly

Christopher Diggins — 2008-05-13 20:43:00

So IIUC applying the idea to a concatenative language like Cat:



   [is_weekend ["happy'] ["sad"] if] ` apply



Will generate different code depending on the day of week it is compiled.



Neat!



- Christopher



 On Tue, May 13, 2008 at 4:35 PM, John Cowan <cowan@...> wrote:

>

>

>

>

> Manfred Von Thun scripsit:

>

>

> > The beauty of the various Unix utilities is that you can pipe the output

> > of one to become the input to the next. The backquote substitution

> > can make good use of it.

>

> Backquotes -- as is clearly shown by the alternative syntax $(...) --

> essentially belong to the lexical level of the shell, just like $name

> substitution. So they are very like Lisp macros: code inside backquotes

> runs in a subshell to produce *source code* which is then evaluated by

> the main shell in context, just as a Lisp macro runs in an subordinate

> evaluator to generate Lisp code to be run by the main evaluator in

> context.

>

> --

> What has four pairs of pants, lives John Cowan

> in Philadelphia, and it never rains http://www.ccil.org/~cowan

> but it pours? cowan@...

> --Rufus T. Firefly

>

>

> 

Manfred Von Thun — 2008-05-14 05:49:56

On 14/5/08 6:19 AM, "William Tanksley, Jr" <wtanksleyjr@...> wrote:

 > 

> Manfred Von Thun <m.vonthun@... <mailto:m.vonthun%40latrobe.edu.au>

> > wrote:

> 

>> >  Is there a lesson to be learned for concatenative languages?

> 

> I don't know what the lesson would be. Backquotes escape from a string

> context to an executation/evaluation context. I suppose one could do

> that in a concatenative language that had a string syntax.

> 

 
Maybe I should not have chosen those examples with the chatty strings inside

which

the backquote occurred. Here is an example that illustrates the Eval =

Unquote

principle:  Eval(Quote(x)) = x:



echo `date`  =  date



For a concatenative language the lesson would be a facility to reach out

into the numerous Unix utilities which compute unary functions from

streams of bytes to streams of bytes. It would start with a string in the

concatenative language and end up with another string. All the Unix piping

would be done at the level of the concatenative language. The example

of counting the files in the home directory would look like one or the

other of these:



³la ~²  ls  ³-l² wc

³ls ­la ~² unix ³wc ­l² unix



This should leave a string of digits on top of the stack (or perhaps better,

an integer).



 > More generally, I suppose one could "escape" from any context to an

> evaluation, thus allowing you to compute a value at runtime which will

> be compiled into the current quotation.

> 

 
I definitely meant escaping to unix. Escaping to evaluate a quotation

is already in Joy: suppose there is a quotation on top of the stack. Then



stack swap infra first



or something similar will push the result of executing the quotation

onto the stack. Whether that result is to be spliced into another

quotation (what you called the current) is another matter again.



  - Manfred







[Non-text portions of this message have been removed]

Manfred Von Thun — 2008-05-14 06:25:32

On 14/5/08 6:35 AM, "John Cowan" <cowan@...> wrote:

 > 

> Manfred Von Thun scripsit:

> 

>> > The beauty of the various Unix utilities is that you can pipe the output

>> > of one to become the input to the next. The backquote substitution

>> > can make good use of it.

> 

> Backquotes -- as is clearly shown by the alternative syntax $(...) --

> essentially belong to the lexical level of the shell, just like $name

> substitution. 

> 

 
Thank you, I did not know about the alternative syntax. My relevant manual

(in this case Bourne¹s ..The Unix Programming Environment.. 1982 (?)

does not have it. But my eMac here knows about it...



 >  So they are very like Lisp macros: code inside backquotes

> runs in a subshell to produce *source code* which is then evaluated by

> the main shell in context, just as a Lisp macro runs in an subordinate

> evaluator to generate Lisp code to be run by the main evaluator in

> context.



 
Yes, Lisp¹s macros .. I have never used them in the 5 or 6 pages of Lisp

that I have written. Oleg has some amazing things to say about

various lambda calculus interpreters hidden inside Lisp and Scheme,

with call by name and call by value. I can¹t find it right now, sorry.



  - Manfred







[Non-text portions of this message have been removed]

John Cowan — 2008-05-14 14:15:44

Manfred Von Thun scripsit:



 > Thank you, I did not know about the alternative syntax. My relevant manual

> (in this case Bourne¹s ..The Unix Programming Environment.. 1982 (?)

> does not have it. But my eMac here knows about it...



 
It didn't exist that long ago, but it is in Posix, and therefore in the

ash/dash, ksh, and bash shells at least.



 > Yes, Lisp¹s macros .. I have never used them in the 5 or 6 pages of Lisp

> that I have written. Oleg has some amazing things to say about

> various lambda calculus interpreters hidden inside Lisp and Scheme,

> with call by name and call by value. I can¹t find it right now, sorry.



 
"Lisp programmers don't write in Lisp: their macros do it for them."



-- 

Work hard,                                      John Cowan

play hard,                                      cowan@...

die young,                                      http://www.ccil.org/~cowan

rot quickly.

Raymundo Quirino Baquirin — 2008-05-16 20:40:20

Hi, Manfred,



This discussion triggered a memory which caused me to consult a REXX

manual.  In REXX ordinary strings enclosed in matching single or

double quotes are considered commands to be sent to the operating

environment.  In fact, any expression which upon evaluation was not

recognized as a language instruction is considered a command--quoting

the expression if in fact it was an OS command tells REXX not to

bother evaluating it, just ship it off to the OS and get a return code

back.  In fact, the operating environment could be set to a custom

program, not necessarily the OS shell.



IMHO something like this would be great for an embedded Joy, such as

JoyJ.  Of course something like the Unix backquote syntax would be

required.



Servus,



Ray



--- In concatenative@yahoogroups.com, Manfred Von Thun <m.vonthun@...>

wrote:

 >

> 

> 

> 

> On 14/5/08 6:19 AM, "William Tanksley, Jr" <wtanksleyjr@...> wrote:

> > 

> > Manfred Von Thun <m.vonthun@... <mailto:m.vonthun%40latrobe.edu.au>

> > > wrote:

> > 

> >> >  Is there a lesson to be learned for concatenative languages?

> > 

> > I don't know what the lesson would be. Backquotes escape from a string

> > context to an executation/evaluation context. I suppose one could do

> > that in a concatenative language that had a string syntax.

> > 

> Maybe I should not have chosen those examples with the chatty

 
strings inside

 > which

> the backquote occurred. Here is an example that illustrates the Eval =

> Unquote

> principle:  Eval(Quote(x)) = x:

> 

> echo `date`  =  date

> 

> For a concatenative language the lesson would be a facility to reach out

> into the numerous Unix utilities which compute unary functions from

> streams of bytes to streams of bytes. It would start with a string

 
in the

 > concatenative language and end up with another string. All the Unix

 
piping

 > would be done at the level of the concatenative language. The example

> of counting the files in the home directory would look like one or the

> other of these:

> 

> ³la ~²  ls  ³-l² wc

> ³ls ­la ~² unix ³wc ­l² unix

> 

> This should leave a string of digits on top of the stack (or perhaps

 
better,

 > an integer).

> 

> > More generally, I suppose one could "escape" from any context to an

> > evaluation, thus allowing you to compute a value at runtime which will

> > be compiled into the current quotation.

> > 

> I definitely meant escaping to unix. Escaping to evaluate a quotation

> is already in Joy: suppose there is a quotation on top of the stack.

 
Then

 > 

> stack swap infra first

> 

> or something similar will push the result of executing the quotation

> onto the stack. Whether that result is to be spliced into another

> quotation (what you called the current) is another matter again.

> 

>   - Manfred

> 

> 

> 

> [Non-text portions of this message have been removed]

>