# RE: [stack] Pattern matching, stack comments

## Tanksley, William D. Jr. — 2004-04-06 15:25:41

    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

## Don Groves — 2004-04-06 17:26:27

    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

## Stevan Apter — 2004-04-06 20:13:30

    ----- 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.

## Rod Price — 2004-04-06 20:26:35

    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

    >

    >

    >

    >

## Tanksley, William D. Jr. — 2004-04-06 20:50:59

    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

## Stevan Apter — 2004-04-06 21:26:04

    > 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

    >

    >

    >

    >

    >

## Tanksley, William D. Jr. — 2004-04-06 22:02:36

    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

## Stevan Apter — 2004-04-06 22:21:46

    ----- 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.0404032122.381cd876%40posting.google.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.functional

    >

    > -Billy

    >

    >

    >

    > Yahoo! Groups Links

    >

    >

    >

    >

    >

## Don Groves — 2004-04-06 22:43:56

    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

## sa@dfa.com — 2004-04-06 18:16:19

    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

    >

    >

    >

    >

    >

## Tanksley, William D. Jr. — 2004-04-13 00:28:04

    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

## stevan apter — 2004-04-13 01:28:41

    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

    >

    >

    >

    >

    >

## stevan apter — 2004-04-15 00:56:46

    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]

## Tanksley, William D. Jr. — 2004-04-15 01:03:30

    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

## andrew cooke — 2004-04-15 01:25:26

    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

## stevan apter — 2004-04-15 10:17:40

    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

    >

    >

    >

    >

    >

## stevan apter — 2004-04-15 22:22:19

    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

    >

    >

    >

    >

    >

## andrew cooke — 2004-04-15 23:59:26

    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

## Tanksley, William D. Jr. — 2004-04-16 17:17:46

    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

## andrew cooke — 2004-04-16 18:14:26

    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

## phimvt@lurac.latrobe.edu.au — 2004-05-03 07:26:32

    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

## phimvt@lurac.latrobe.edu.au — 2004-05-07 06:48:07

    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