From: andrew cooke [mailto:andrew@...]

>First - maybe you add some kind of support for comments on the

>stack, so that operations that pushed values could attach

>comments.  Then a stack dump might show not just values, but

>also comments.



So you want annotations on arbitrary data (not on the stack, but on the

data)? That's not a bad idea, but you'd need to define a new datatype with

room for the annotation.



>Second - could you add pattern matching to definitions, to

>make them simpler to read?  Then swap might be defined

>something like: swap a b == b a



cK added this at my suggestion. I implemented it about 10 years ago in Pygmy

Forth as a machine-code generating compiler, and wanted to add support for

it to the parser (so that any word of the form abc--cba would generate

inline code for the pictured stack shuffle). cK handles it differently, by

providing a word that takes the stack picture as a string at runtime rather

than taking the picture as a token at compile-time, but either way the

effect is much the same (and a good compiler would theoretically generate

much the same code).



>I can already see at least two objections to the second point

>- first that it's not clear whether you match atomic values or

>sub-stacks



Substacks are values, so no problem. If you want to support pattern matching

within lists or other data structures, you have to define a syntax for it,

as Apter did for cK.



> and second that you might lose much of the

>concatenative flavour of the language



No; the "shuffle literals" or "stack pictures" are just a formal way of

expressing stack operators. The English names aren't the only possible

names; it would have made just as much sense for Chuck Moore to have named

"dup" as "a-aa", in which case my stack picture compiler would be an

obvious, simple generalization.



>(or, alternative, that

>if you're used to programming in a such a style, such matching

>appears redundant).



I don't think it is -- it's certainly possible to express all possible stack

manipulations with only a minimal set of stack operators, but it's not at

all efficient or readable. Stack pictures DO help, in my long-past

experience with my Forth mod.



>Andrew



-Billy

On Tue, 6 Apr 2004 08:25:41 -0700, Tanksley, William D. Jr.

<TanksleyJrW@...> wrote:



> From: andrew cooke [mailto:andrew@...]

>> First - maybe you add some kind of support for comments on the

>> stack, so that operations that pushed values could attach

>> comments.  Then a stack dump might show not just values, but

>> also comments.

>

> So you want annotations on arbitrary data (not on the stack, but on the

> data)? That's not a bad idea, but you'd need to define a new datatype with

> room for the annotation.

>

>> Second - could you add pattern matching to definitions, to

>> make them simpler to read?  Then swap might be defined

>> something like: swap a b == b a

>

> cK added this at my suggestion. I implemented it about 10 years ago in Pygmy

> Forth as a machine-code generating compiler, and wanted to add support for

> it to the parser (so that any word of the form abc--cba would generate

> inline code for the pictured stack shuffle). ...snip...



The "abc" part is redundant here.  Something like "stack--cba"

would be self-documenting and more easily understood than "swap

rot", imho.  Or, "[3 2 1] shuffle", which can be extended to any

depth.





> I don't think it is -- it's certainly possible to express all possible stack

> manipulations with only a minimal set of stack operators, but it's not at

> all efficient or readable. Stack pictures DO help, in my long-past

> experience with my Forth mod.

>



Amen!

--

dg

Don Groves <dgroves@...> wrote on 04/06/2004 01:26:27 PM:



> On Tue, 6 Apr 2004 08:25:41 -0700, Tanksley, William D. Jr.

<TanksleyJrW@...> wrote:

>

> > From: andrew cooke [mailto:andrew@...]

> >> First - maybe you add some kind of support for comments on the

> >> stack, so that operations that pushed values could attach

> >> comments.  Then a stack dump might show not just values, but

> >> also comments.

> >

> > So you want annotations on arbitrary data (not on the stack, but on the

> > data)? That's not a bad idea, but you'd need to define a new datatype

with

> > room for the annotation.

> >

> >> Second - could you add pattern matching to definitions, to

> >> make them simpler to read?  Then swap might be defined

> >> something like: swap a b == b a

> >

> > cK added this at my suggestion. I implemented it about 10 years ago in

Pygmy

> > Forth as a machine-code generating compiler, and wanted to add support

for

> > it to the parser (so that any word of the form abc--cba would generate

> > inline code for the pictured stack shuffle). ...snip...

>

> The "abc" part is redundant here.  Something like "stack--cba"

> would be self-documenting and more easily understood than "swap

> rot", imho.  Or, "[3 2 1] shuffle", which can be extended to any

> depth.



cK's shuffle notation supports nested patterns:



         10 [20 30] 40 "a[bc]d--b[da]c" shuffle

      20 [40 10] 30



see http://www.nsl.com/papers/ck.htm#Named%20Parameters



hey, it's nice to see some activity here.



>

>

> > I don't think it is -- it's certainly possible to express all possible

stack

> > manipulations with only a minimal set of stack operators, but it's not

at

> > all efficient or readable. Stack pictures DO help, in my long-past

> > experience with my Forth mod.

> >

>

> Amen!

> --

> dg

>

>

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

----- Original Message -----

From: "Don Groves" <dgroves@...>

To: <concatenative@yahoogroups.com>

Sent: Tuesday, April 06, 2004 1:26 PM

Subject: Re: [stack] Pattern matching, stack comments





> On Tue, 6 Apr 2004 08:25:41 -0700, Tanksley, William D. Jr.

<TanksleyJrW@...> wrote:

>

> > From: andrew cooke [mailto:andrew@...]

> >> First - maybe you add some kind of support for comments on the

> >> stack, so that operations that pushed values could attach

> >> comments.  Then a stack dump might show not just values, but

> >> also comments.

> >

> > So you want annotations on arbitrary data (not on the stack, but on the

> > data)? That's not a bad idea, but you'd need to define a new datatype with

> > room for the annotation.

> >

> >> Second - could you add pattern matching to definitions, to

> >> make them simpler to read?  Then swap might be defined

> >> something like: swap a b == b a

> >

> > cK added this at my suggestion. I implemented it about 10 years ago in Pygmy

> > Forth as a machine-code generating compiler, and wanted to add support for

> > it to the parser (so that any word of the form abc--cba would generate

> > inline code for the pictured stack shuffle). ...snip...

>

> The "abc" part is redundant here.  Something like "stack--cba"

> would be self-documenting and more easily understood than "swap

> rot", imho.  Or, "[3 2 1] shuffle", which can be extended to any

> depth.



apologies if this message appears more than once - i'm not sure

what happened to an earlier try.



cK's shuffle operator understands nested stack-patterns:



   10 [20 30] 40 "a[bc]d--b[da]c" shuffle

20 [40 10] 30



http://www.nsl.com/papers/ck.htm#Named%20Parameters



i agree with billy that programming with pictures of this kind

is very appealing.

I've been reading this list for some time but have never

participated.  Now I want to ask a potentially embarrassing

newbie question:  Is there a free or inexpensive version

of K that I can get my hands on?  I'd like to experiment

with cK, and it seems that a copy of K is a prerequisite.



-Rod



On Apr 6, 2004, at 2:13 PM, Stevan Apter wrote:



>

> ----- Original Message -----

> From: "Don Groves" <dgroves@...>

> To: <concatenative@yahoogroups.com>

> Sent: Tuesday, April 06, 2004 1:26 PM

> Subject: Re: [stack] Pattern matching, stack comments

>

>

>> On Tue, 6 Apr 2004 08:25:41 -0700, Tanksley, William D. Jr.

>> <TanksleyJrW@...> wrote:

>>

>>> From: andrew cooke [mailto:andrew@...]

>>>> First - maybe you add some kind of support for comments on the

>>>> stack, so that operations that pushed values could attach

>>>> comments.  Then a stack dump might show not just values, but

>>>> also comments.

>>>

>>> So you want annotations on arbitrary data (not on the stack, but on

>>> the

>>> data)? That's not a bad idea, but you'd need to define a new

>>> datatype with

>>> room for the annotation.

>>>

>>>> Second - could you add pattern matching to definitions, to

>>>> make them simpler to read?  Then swap might be defined

>>>> something like: swap a b == b a

>>>

>>> cK added this at my suggestion. I implemented it about 10 years ago

>>> in Pygmy

>>> Forth as a machine-code generating compiler, and wanted to add

>>> support for

>>> it to the parser (so that any word of the form abc--cba would

>>> generate

>>> inline code for the pictured stack shuffle). ...snip...

>>

>> The "abc" part is redundant here.  Something like "stack--cba"

>> would be self-documenting and more easily understood than "swap

>> rot", imho.  Or, "[3 2 1] shuffle", which can be extended to any

>> depth.

>

> apologies if this message appears more than once - i'm not sure

> what happened to an earlier try.

>

> cK's shuffle operator understands nested stack-patterns:

>

>   10 [20 30] 40 "a[bc]d--b[da]c" shuffle

> 20 [40 10] 30

>

> http://www.nsl.com/papers/ck.htm#Named%20Parameters

>

> i agree with billy that programming with pictures of this kind

> is very appealing.

>

>

>

> ------------------------ Yahoo! Groups Sponsor

> ---------------------~-->

> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark

> Printer at MyInks.com.  Free s/h on orders $50 or more to the US &

> Canada.

> http://www.c1tracking.com/l.asp?cid=5511

> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/saFolB/TM

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

> ~->

>

>

> Yahoo! Groups Links

>

>

>

>

On Tue, 6 Apr 2004 16:13:30 -0400, Stevan  Apter <sa@...> wrote:



>

> ----- Original Message -----

> From: "Don Groves" <dgroves@...>

> To: <concatenative@yahoogroups.com>

> Sent: Tuesday, April 06, 2004 1:26 PM

> Subject: Re: [stack] Pattern matching, stack comments

>

>

>> On Tue, 6 Apr 2004 08:25:41 -0700, Tanksley, William D. Jr.

<TanksleyJrW@...> wrote:

>> > cK added this at my suggestion. I implemented it about 10 years ago in

Pygmy

>> > Forth as a machine-code generating compiler, and wanted to add support for

>> > it to the parser (so that any word of the form abc--cba would generate

>> > inline code for the pictured stack shuffle). ...snip...

>>

>> The "abc" part is redundant here.  Something like "stack--cba"

>> would be self-documenting and more easily understood than "swap

>> rot", imho.  Or, "[3 2 1] shuffle", which can be extended to any

>> depth.

>

> apologies if this message appears more than once - i'm not sure

> what happened to an earlier try.

>

> cK's shuffle operator understands nested stack-patterns:

>

>   10 [20 30] 40 "a[bc]d--b[da]c" shuffle

> 20 [40 10] 30



Very nice. I know nothing of cK, mostly Forth and some Joy.





> i agree with billy that programming with pictures of this kind

> is very appealing.



So do I, hopefully my 'Amen' gave that impression.

--

dg

From: Don Groves [mailto:dgroves@...]

>The "abc" part is redundant here.  Something like "stack--cba"

>would be self-documenting and more easily understood than

>"swap rot", imho.  Or, "[3 2 1] shuffle", which can be

>extended to any depth.



OTOH, being able to use terms like "xyz--xyzzy" versus "abc--cbcba" does

allow you to maintain a visible difference between different items. In that

case the two shuffles might be handling completely different items --

perhaps there's a "abcxyz--xyzabc" somewhere between them.



In addition, as Stevan pointed out, you can also express other patterns,

such as lists. "ab[cd]--ac[bd]" is a possible example. I like the idea, but

I can't imagine using it :-). If I did, I'd probably modify it to

pattern-match against the car and cdr of the list, not against every

specific item in the list. That way every list pattern would work for ANY

list, not just the lists with the same length as the pattern.



>dg



-Billy

> In addition, as Stevan pointed out, you can also express other patterns,

> such as lists. "ab[cd]--ac[bd]" is a possible example. I like the idea, but

> I can't imagine using it :-). If I did, I'd probably modify it to

> pattern-match against the car and cdr of the list, not against every

> specific item in the list. That way every list pattern would work for ANY

> list, not just the lists with the same length as the pattern.



oh - that's a very nice idea - i hadn't thought of that.  so



     [xy]



always matches x to the car and y to the cdr?  i like it.



>

> >dg

>

> -Billy

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

From: Stevan Apter [mailto:sa@...]

>>probably modify it to pattern-match against the car and cdr of the

>>list, not against every specific item in the list. That way

>>every list pattern would work for ANY list, not just the lists

>>with the same length as the pattern.



>oh - that's a very nice idea - i hadn't thought of that.  so



Oh! Sorry -- I just assumed you had some reason for doing things differently

:-). All the modern pattern-matching languages that incorporate list support

match head and tail.



>    [xy]

>always matches x to the car and y to the cdr?  i like it.



Yup, that's it. You can match deeper into list explicitly, so



  [x[yz]]



matches a list at least two items long, or the language designer can provide

shortcuts so that [xyz] will do the same thing (since it's the obvious thing

to do).



Pattern matching is fun. I enjoyed reading about Haskell; it's a very

powerful language with some useful mathematics that apply very strongly to

concatenative languages. See



http://www.nomaware.com/monads/html/index.html



for a nice tutorial (be warned -- this does assume Haskell knowledge, but I

didn't have any either when I started reading this).



-Billy

----- Original Message -----

From: "Tanksley, William D. Jr." <TanksleyJrW@...>

To: <concatenative@yahoogroups.com>

Sent: Tuesday, April 06, 2004 6:02 PM

Subject: RE: [stack] Pattern matching, stack comments





> From: Stevan Apter [mailto:sa@...]

> >>probably modify it to pattern-match against the car and cdr of the

> >>list, not against every specific item in the list. That way

> >>every list pattern would work for ANY list, not just the lists

> >>with the same length as the pattern.

>

> >oh - that's a very nice idea - i hadn't thought of that.  so

>

> Oh! Sorry -- I just assumed you had some reason for doing things differently

> :-). All the modern pattern-matching languages that incorporate list support

> match head and tail.



but i'm so pre-modern ..



i just think of lists as being "random access" - the head isn't privileged,

"first of x" is just "x 0", &c.



>

> >    [xy]

> >always matches x to the car and y to the cdr?  i like it.

>

> Yup, that's it. You can match deeper into list explicitly, so

>

>  [x[yz]]

>

> matches a list at least two items long, or the language designer can provide

> shortcuts so that [xyz] will do the same thing (since it's the obvious thing

> to do).

>

> Pattern matching is fun. I enjoyed reading about Haskell; it's a very

> powerful language with some useful mathematics that apply very strongly to

> concatenative languages. See

>

> http://www.nomaware.com/monads/html/index.html

>

> for a nice tutorial (be warned -- this does assume Haskell knowledge, but I

> didn't have any either when I started reading this).



every so often i think i ought to learn haskell.  then i realize

how urgent it is that i clean my desk.



seriously, look at this thread:



http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=711c7390.04040321\

22.381cd876%40posting.google.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26g\

roup%3Dcomp.lang.functional





>

> -Billy

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

From: Stevan Apter [mailto:sa@...]

>From: "Tanksley, William D. Jr." <TanksleyJrW@...>

>>Oh! Sorry -- I just assumed you had some reason for doing things

>>differently :-). All the modern pattern-matching languages that

>>incorporate list support match head and tail.



>but i'm so pre-modern ..



>i just think of lists as being "random access" - the head

>isn't privileged, "first of x" is just "x 0", &c.



That's very useful for most applications -- for pattern matching, though,

you have to find some way of describing lists without having to name every

element. Making the first element special happens to work nicely.

Alternately, you can invent a special language to describe the lists, but

that can get complicated.



>seriously, look at this thread:



>http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=

>711c7390.0404032122.381cd876%40posting.google.com&prev=/groups%

>3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.functional



Funny -- all those complex, odd lines of code, and then the one-liner

pattern-matching solution that makes perfect sense on the first reading.



-Billy

so how's this:



top-level elements in a pattern denote items on the stack.



lists in the pattern contain lower-case letters which denote

list-elements, and possibly terminate in a single upper-case

letter which denotes the rest of the list:



     "x[abC]--[aC]x[bC]"



expects e.g.



     .. 10 [1 2 3 4 5 6]



and produces



     .. [1 3 4 5 6]10[2 3 4 5 6]



upper-case letters can't appear as top-level elements:



     x Y z -- x z Y



i can imagine a more general approach, which limits upper-case

letters to a single-occurrence on the left, but permits multiple

occurrences on the right:



     [xyZuv]--[xZyZuZv]



takes



     .. [10 20  30 40 50  60 70]



to make



     .. [10  30 40 50  20  30 40 50  60  30 40 50  70]



what do you think?



----- Original Message -----

From: "Tanksley, William D. Jr." <TanksleyJrW@...>

To: <concatenative@yahoogroups.com>

Sent: Monday, April 12, 2004 8:28 PM

Subject: RE: [stack] Pattern matching, stack comments





> From: Stevan Apter [mailto:sa@...]

> >From: "Tanksley, William D. Jr." <TanksleyJrW@...>

> >>Oh! Sorry -- I just assumed you had some reason for doing things

> >>differently :-). All the modern pattern-matching languages that

> >>incorporate list support match head and tail.

>

> >but i'm so pre-modern ..

>

> >i just think of lists as being "random access" - the head

> >isn't privileged, "first of x" is just "x 0", &c.

>

> That's very useful for most applications -- for pattern matching, though,

> you have to find some way of describing lists without having to name every

> element. Making the first element special happens to work nicely.

> Alternately, you can invent a special language to describe the lists, but

> that can get complicated.

>

> >seriously, look at this thread:

>

> >http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=

> >711c7390.0404032122.381cd876%40posting.google.com&prev=/groups%

> >3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.functional

>

> Funny -- all those complex, odd lines of code, and then the one-liner

> pattern-matching solution that makes perfect sense on the first reading.

>

> -Billy

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

implemented in cK as an extension to shuffle-notation:



top-level elements in a pattern denote items on the stack.



lists in the pattern contain lower-case letters which denote

list-elements, and possibly terminate in a single special

character which denotes the rest of the list:



     "x[ab_]--[a_]x[b_]" shuffle



expects e.g.



     .. 10 [1 2 3 4 5 6]



and produces



     .. [1 3 4 5 6]10[2 3 4 5 6]

From: stevan apter [mailto:sa@...]

>implemented in cK as an extension to shuffle-notation:

>top-level elements in a pattern denote items on the stack.



>lists in the pattern contain lower-case letters which denote

>list-elements, and possibly terminate in a single special

>character which denotes the rest of the list:



Cool.



What special characters are available? Can you give examples to manipulate

more than one array? For example, would "[a_][b*]--[b_][a*]" swap the first

element of two arrays? Would "[a_][b*][c?]--[_][*][?]abc" extract the first

element of three arrays?



-Billy

the syntax for otuto (the language i'm writing - started the parser today)

that prompted me to ask this question originally - is a lot more verbose,

but does a simlar thing.  for example:



{ pick3 | ['a _..] ['b _..] ['c _..] } => { | 'a 'b 'c }



takes a stack with three arrays on top, removes them, and leaves their

inital values. while



{ pick3 | (['a _..] as 'aa) (['b _..] as 'bb) (['c _..] as 'cc) } =>

    { | 'a 'b 'c 'aa 'bb 'cc}



adds them (on top of the arrays) and



{ leaf2 | [ ['a _..] _] } => { | 'a }



picks what might be a leaf from binary node (nested lists).



' marks a variable used in matching, _ matches but cannot be referenced,

and .. is a postfix modifier that changes binding from one value to all

the remaining elements in the list.



so ['a 'b..] splits the list into head 'a and tail 'b, for example.



{ ops | state } => { ops' | state' } is a rewrite rule, from operations

and state before, to operations and state after (those being the two

stacks).



andrew



Tanksley, William D. Jr. said:

> From: stevan apter [mailto:sa@...]

>>implemented in cK as an extension to shuffle-notation:

>>top-level elements in a pattern denote items on the stack.

>

>>lists in the pattern contain lower-case letters which denote

>>list-elements, and possibly terminate in a single special

>>character which denotes the rest of the list:

>

> Cool.

>

> What special characters are available? Can you give examples to manipulate

> more than one array? For example, would "[a_][b*]--[b_][a*]" swap the

> first

> element of two arrays? Would "[a_][b*][c?]--[_][*][?]abc" extract the

> first

> element of three arrays?

>

> -Billy

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

>





--

` __ _ __ ___  ___| |_____   work web site: http://www.ctio.noao.edu/~andrew

  / _` / _/ _ \/ _ \ / / -_)  personal web site: http://www.acooke.org/andrew

  \__,_\__\___/\___/_\_\___|  personal gallery: http://www.acooke.org/pancito

thanks for pointing out that more than one special character

would be useful.  i've reverted to my original scheme, using

upper-case letters:



   [1 2 3][4 5 6][7 8 9]"[aA][bB][cC]--[A][B][C]abc" shuffle

[2 3] [5 6] [8 9] 1 4 7





sa



----- Original Message -----

From: "Tanksley, William D. Jr." <TanksleyJrW@...>

To: <concatenative@yahoogroups.com>

Sent: Wednesday, April 14, 2004 9:03 PM

Subject: RE: [stack] Pattern matching, stack comments





> From: stevan apter [mailto:sa@...]

> >implemented in cK as an extension to shuffle-notation:

> >top-level elements in a pattern denote items on the stack.

>

> >lists in the pattern contain lower-case letters which denote

> >list-elements, and possibly terminate in a single special

> >character which denotes the rest of the list:

>

> Cool.

>

> What special characters are available? Can you give examples to manipulate

> more than one array? For example, would "[a_][b*]--[b_][a*]" swap the first

> element of two arrays? Would "[a_][b*][c?]--[_][*][?]abc" extract the first

> element of three arrays?

>

> -Billy

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

On Thu, 15 Apr 2004, stevan apter wrote:



> thanks for pointing out that more than one special character

> would be useful.  i've reverted to my original scheme, using

> upper-case letters:

>

>   [1 2 3][4 5 6][7 8 9]"[aA][bB][cC]--[A][B][C]abc" shuffle

> [2 3] [5 6] [8 9] 1 4 7



The shuffle strings are beginning to look more and more like

the earlier list notation in Prolog, where the left part of

the above strings would perhaps look like this:

    [A1 | As] [B1 | Bs] [C1 | Cs]

where all pattern matching variables are in upper case, and

the vertical bar indicates that what follows is the (possibly empty)

rest of the list. Your/lower case notation eliminates the need

for that.



But consider the following generalisation of shuffle strings.

First allow me to use a different notation for a moment.

I'll write your "ab[cdE]--....." as (a b [c d E] : ...)

where the left means:

     Let c d and E be the first, second and rest of the ToS list,

       and pop that off

     let b be the second element on the stack, let a be the third

       and pop them off

     With these new names do ...

That looks just like a let expression (not exactly a lambda abstraction)

used in many languages.

But what could the ... be? In shuffle notation it is a sequence

of pushes including perhaps pushes of constructed lists. But could

one allow other things?



I'll only give one example:

      1 2 [3 4 5 6]    (a b [c d E] : c d + E b dup * [E])

==>  7 [5 6] 4 [[5 6]]



In other words, the right hand side can be any Joy program.

The scope of the new names is delimited by the closing )



Must fly.



Many thanks for the well-wishes



   - Manfred

Some of the recent discussion prompts me to clarify the difference

between the (LET-like) generalisation and lambda abstractions.



On Mon, 3 May 2004 phimvt@... wrote:



[sorry to quote myself ..]



> But consider the following generalisation of shuffle strings.

> First allow me to use a different notation for a moment.

> I'll write your "ab[cdE]--....." as (a b [c d E] : ...)

> where the left means:

>     Let c d and E be the first, second and rest of the ToS list,

>       and pop that off

>     let b be the second element on the stack, let a be the third

>       and pop them off

>     With these new names do ...

> That looks just like a let expression (not exactly a lambda abstraction)

> used in many languages.

> But what could the ... be? In shuffle notation it is a sequence

> of pushes including perhaps pushes of constructed lists. But could

> one allow other things?

>

> I'll only give one example:

>      1 2 [3 4 5 6]    (a b [c d E] : c d + E b dup * [E])

> ==>  7 [5 6] 4 [[5 6]]

>

> In other words, the right hand side can be any Joy program.

> The scope of the new names is delimited by the closing )



For the sake of this discussion only, let me change the notation

again to make similarities and differences clearer: write the

above instead as

      LET  a b [c d E]  IN  c d + E b dup * [E]  ENDLET

The general form is

      LET  name-part  IN  body-part  ENDLET

(the difference between this and LET's in other languages is that

the name-part consists just of names - the values given are those

taken from the stack)



Note as I have described it, as a generalisation of shuffle

strings, both parts are immediately executed when encountered

in a program - just like simple swaps and dups.



One might have something rather like this, something which is not

executed when encountered in a program, but which is simply pushed

onto the stack where it can be manipulated and perhaps eventually

executed by some combinator. Write this in the very similar form

     LAMBDA  name-part  IN  body-part  ENDLAMBDA

This would the closest one might have to lambda abstraction in Joy.

So this is to be like a quotation, just to be pushed. No reason

why all combinators should not take such abstractions as arguments

rather than just quotations. The following would hold:

     LAMBDA .. ENDLAMBDA  i   ==   LET .. ENDLET

     [ LET .. ENDLET ]   ==   LAMBDA .. ENDLAMBDA

where of course in row 1 the two occurrences of .. are the same

and ditto in row 2. Furthermore, quotations are just a special

case of lambda abstractions, in which the name-part is empty:

     LAMBDA IN some-body ENDLAMBDA   ==   [ some-body ]



This does not quite mix well with definitions, where one might have

expected

     DEFINE  foo(a b)  ==  foo-body.

to be equivalent to

     DEFINE  foo  ==  LAMBDA a b IN foo-body ENDLAMBDA.

when in fact it would be equivalent to

     DEFINE  foo  ==  LET a b IN foo-body ENDLET.



I am not proposing this as good notation, nor as an addition to Joy.



Any thoughts?



   - Manfred

looks interesting - are you planning to release it for study/use by

others?



i would imagine that it's often useful to match richer patterns than

just first-rest.  e.g. last-allbutlast:



     Xy -> yX    / left rotate



i've relaxed shuffle-patterns in cK to allow the single upper-case

letter to appear *anywhere* in the 'from' pattern, e.g.



     "xYz--zYx" shuffle





----- Original Message -----

From: "andrew cooke" <andrew@...>

To: <concatenative@yahoogroups.com>

Sent: Wednesday, April 14, 2004 9:25 PM

Subject: RE: [stack] Pattern matching, stack comments





>

> the syntax for otuto (the language i'm writing - started the parser today)

> that prompted me to ask this question originally - is a lot more verbose,

> but does a simlar thing.  for example:

>

> { pick3 | ['a _..] ['b _..] ['c _..] } => { | 'a 'b 'c }

>

> takes a stack with three arrays on top, removes them, and leaves their

> inital values. while

>

> { pick3 | (['a _..] as 'aa) (['b _..] as 'bb) (['c _..] as 'cc) } =>

>    { | 'a 'b 'c 'aa 'bb 'cc}

>

> adds them (on top of the arrays) and

>

> { leaf2 | [ ['a _..] _] } => { | 'a }

>

> picks what might be a leaf from binary node (nested lists).

>

> ' marks a variable used in matching, _ matches but cannot be referenced,

> and .. is a postfix modifier that changes binding from one value to all

> the remaining elements in the list.

>

> so ['a 'b..] splits the list into head 'a and tail 'b, for example.

>

> { ops | state } => { ops' | state' } is a rewrite rule, from operations

> and state before, to operations and state after (those being the two

> stacks).

>

> andrew

>

> Tanksley, William D. Jr. said:

> > From: stevan apter [mailto:sa@...]

> >>implemented in cK as an extension to shuffle-notation:

> >>top-level elements in a pattern denote items on the stack.

> >

> >>lists in the pattern contain lower-case letters which denote

> >>list-elements, and possibly terminate in a single special

> >>character which denotes the rest of the list:

> >

> > Cool.

> >

> > What special characters are available? Can you give examples to manipulate

> > more than one array? For example, would "[a_][b*]--[b_][a*]" swap the

> > first

> > element of two arrays? Would "[a_][b*][c?]--[_][*][?]abc" extract the

> > first

> > element of three arrays?

> >

> > -Billy

> >

> >

> >

> > Yahoo! Groups Links

> >

> >

> >

> >

> >

> >

>

>

> --

> ` __ _ __ ___  ___| |_____   work web site: http://www.ctio.noao.edu/~andrew

>  / _` / _/ _ \/ _ \ / / -_)  personal web site: http://www.acooke.org/andrew

>  \__,_\__\___/\___/_\_\___|  personal gallery: http://www.acooke.org/pancito

>

>

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

stevan apter said:

> looks interesting - are you planning to release it for study/use by

> others?



thanks.  yes, of course - i'll stick it on my web pages.  i just finished

the lexer :o)



> i would imagine that it's often useful to match richer patterns than

> just first-rest.  e.g. last-allbutlast:

>

>     Xy -> yX    / left rotate



in otuto lists are linked lists, so that's not going to be a common idiom

(i would have guessed, but i'm coming from a functional languages

background - in my free time i normally use haskell, but this particular

project is in ml - so i expect that i'm going to get a lot of things

wrong.  but that's the way i seem to learn best....)



cheers,

andrew



--

` __ _ __ ___  ___| |_____   work web site: http://www.ctio.noao.edu/~andrew

  / _` / _/ _ \/ _ \ / / -_)  personal web site: http://www.acooke.org/andrew

  \__,_\__\___/\___/_\_\___|  personal gallery: http://www.acooke.org/pancito

From: andrew cooke [mailto:andrew@...]

>the syntax for otuto (the language i'm writing - started the

>parser today) that prompted me to ask this question originally

>- is a lot more verbose, but does a simlar thing.  for example:



>{ pick3 | (['a _..] as 'aa) (['b _..] as 'bb) (['c _..] as 'cc) } =>

>   { | 'a 'b 'c 'aa 'bb 'cc}

>adds them (on top of the arrays) and



Nice.



A question: why is your stack notation reversed from the usual convention?

The convention is to list the stack order in the same way that you'd have to

type the items in order to get them onto the stack.



-Billy

i have two stacks, so one is backwards (they meet at |).  since it's

traditional to put the operator at the left, it ends up like that,

although i didn't know it was backwards until just now!  sorry about that

- i'll see if i can think of an alternative, but this has the advantage

that it looks normal to someone used to functional languages (me!).



cheers,

andrew



Tanksley, William D. Jr. said:

> From: andrew cooke [mailto:andrew@...]

>>the syntax for otuto (the language i'm writing - started the

>>parser today) that prompted me to ask this question originally

>>- is a lot more verbose, but does a simlar thing.  for example:

>

>>{ pick3 | (['a _..] as 'aa) (['b _..] as 'bb) (['c _..] as 'cc) } =>

>>   { | 'a 'b 'c 'aa 'bb 'cc}

>>adds them (on top of the arrays) and

>

> Nice.

>

> A question: why is your stack notation reversed from the usual convention?

> The convention is to list the stack order in the same way that you'd have

> to

> type the items in order to get them onto the stack.

>

> -Billy

>

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

>





--

` __ _ __ ___  ___| |_____   work web site: http://www.ctio.noao.edu/~andrew

  / _` / _/ _ \/ _ \ / / -_)  personal web site: http://www.acooke.org/andrew

  \__,_\__\___/\___/_\_\___|  personal gallery: http://www.acooke.org/pancito