# wolfram automata

## Stevan Apter — 2003-05-17 14:37:36

    stack manipulation sometimes feels clumsy.  as i acquite

    facility in the language (thinking stackishly as opposed to

    having the arguments to a function all at once by name), i

    notice certain "patterns of difficulty":  "the stack looks

    like this ... and i want that piece ... &c."  the functional

    parts are usually easy to design, but lining up the data to

    operate on takes up more time than i like.

    so anyway, here's an implementation of wolfram's "new kind of

    science" cellular automata.  a couple of k-specific primitives:

    8 2 # makes a vector of eight 2s.  1 3 2 &: makes a list of

    length 1+3+2 = [0 1 1 1 2 2].  ! is rotate (2 [1 2 3 4] ! -> 3 4 1 2),

    !: is enumerate ( 3 !: -> [0 1 2]).

    \ cellular automata in ck;

    [8 2 # swap vs reverse]                       `rule    def \ 30 rule;

    [dup 2 * &: 1 concat !]                       `start   def \ 3 start -> 1 1

    1 0 1 1 1;

    [2 [0 concat reverse] do]                     `sheet   def \ could use a

    cylinder instead;

    [swap 2 group reverse]                        `rpair   def \ a b -> [b a];

    [swap dup size !: [rpair] dip [gen] right]    `ca      def \ 15 start 30

    rule ca;

    [swap drop 3 swap # 2 swap sv at]             `cell    def \;

    [[1 raze] dip swap sheet cell]                `gen     def \;

    [stack [first] map " *" of sysout;]           `disp    def \;

    30 start 25 [30 rule ca] Do disp                           \ 30 wide, 25

    gens, rule 30;

                                  *

                                 ***

                                **  *

                               ** ****

                              **  *   *

                             ** **** ***

                            **  *    *  *

                           ** ****  ******

                          **  *   ***     *

                         ** **** **  *   ***

                        **  *    * **** **  *

                       ** ****  ** *    * ****

                      **  *   ***  **  ** *   *

                     ** **** **  *** ***  ** ***

                    **  *    * ***   *  ***  *  *

                   ** ****  ** *  * *****  *******

                  **  *   ***  **** *    ***      *

                 ** **** **  ***    **  **  *    ***

                **  *    * ***  *  ** *** ****  **  *

               ** ****  ** *  ******  *   *   *** ****

              **  *   ***  ****     **** *** **   *   *

             ** **** **  ***   *   **    *   * * *** ***

            **  *    * ***  * *** ** *  *** ** * *   *  *

           ** ****  ** *  *** *   *  ****   *  * ** ******

          **  *   ***  ****   ** *****   * ***** *  *     *

         ** **** **  ***   * **  *    * ** *     *****   ***

## Nick Forde — 2003-05-19 12:49:12

    Stevan Apter writes:

      > stack manipulation sometimes feels clumsy.  as i acquite

     > facility in the language (thinking stackishly as opposed to

     > having the arguments to a function all at once by name), i

     > notice certain "patterns of difficulty":  "the stack looks

     > like this ... and i want that piece ... &c."  the functional

     > parts are usually easy to design, but lining up the data to

     > operate on takes up more time than i like.

     Although I don't often find working with the stack awkward I do find

    that Joy code littered with stack functions is very hard to read. I'm

    a great fan of source code that "speaks for itself", i.e. is easy to

    read without the need for supporting comments. I once worked on a

    large Smalltalk application for programming FPGAs (place, route,

    synthesis & timing analysis). Even though the code contained some

    pretty complex algorithms and there were about 20 of us working on the

    source at any one time it contained very few source code

    comments. This was simply because Smalltalk encourages descriptive

    source and the methods tended to be kept very short and simple. There

    just wasn't the need for comments in the way I've found with other

    languages.

    When reading Joy I often find the stack manipulators disrupt my chain

    of thought. They force me to stop and figure out the state of the

    stack before and after they are applied. I have found that this can be

    reduced somewhat by keeping definitions as simple as possible and

    trying to keep stack manipulation to the start or end of

    functions. I'd be interested to know of any approaches adopted by

    Forth programmers which might help with this.

    It did occur to me that a collection of "multiplexer" combinators may

    be useful for plugging together incompatible functions. They may also

    provide some benefits in helping specify the stack state before and

    after a function call. These could be written to be typeless and

    perform pure stack manipulation or alternatively they could also be

    used to enforce type checking. Such combinators would allow a design

    by contract style in Joy but I'm not sure of their impact on the

    functional purity of the language or what other theoretical

    implications they may have.

    The only reason I havn't experimented much with this is that the main

    place I find stack manipulation obtrusive is when it has to be

    performed within other combinators. Use of stack multiplexers may help

    a little with this but probably isn't much different from adding

    variables to Joy! :-)

    Nick.

## Stevan Apter — 2003-05-19 14:11:27

    billy has suggested a middle way, which i've implemented in ck:

        10 20 30 "abc--cbca" shuffle

      30 20 30 10

    stack-patterns operate only at the top level of the stack.  but

    i mean to implement list forms on both sides of --.  so e.g.

        "a[b]c--b[ac]b"

    would do the obvious thing.  everything is still variable free,

    unless you count letters in the stack-pattern as such.

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

    From: "Nick Forde" <nickf@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, May 19, 2003 8:49 AM

    Subject: [stack] wolfram automata

    > Stevan Apter writes:

    >  > stack manipulation sometimes feels clumsy.  as i acquite

    >  > facility in the language (thinking stackishly as opposed to

    >  > having the arguments to a function all at once by name), i

    >  > notice certain "patterns of difficulty":  "the stack looks

    >  > like this ... and i want that piece ... &c."  the functional

    >  > parts are usually easy to design, but lining up the data to

    >  > operate on takes up more time than i like.

    >

    > Although I don't often find working with the stack awkward I do find

    > that Joy code littered with stack functions is very hard to read. I'm

    > a great fan of source code that "speaks for itself", i.e. is easy to

    > read without the need for supporting comments. I once worked on a

    > large Smalltalk application for programming FPGAs (place, route,

    > synthesis & timing analysis). Even though the code contained some

    > pretty complex algorithms and there were about 20 of us working on the

    > source at any one time it contained very few source code

    > comments. This was simply because Smalltalk encourages descriptive

    > source and the methods tended to be kept very short and simple. There

    > just wasn't the need for comments in the way I've found with other

    > languages.

    >

    > When reading Joy I often find the stack manipulators disrupt my chain

    > of thought. They force me to stop and figure out the state of the

    > stack before and after they are applied. I have found that this can be

    > reduced somewhat by keeping definitions as simple as possible and

    > trying to keep stack manipulation to the start or end of

    > functions. I'd be interested to know of any approaches adopted by

    > Forth programmers which might help with this.

    >

    > It did occur to me that a collection of "multiplexer" combinators may

    > be useful for plugging together incompatible functions. They may also

    > provide some benefits in helping specify the stack state before and

    > after a function call. These could be written to be typeless and

    > perform pure stack manipulation or alternatively they could also be

    > used to enforce type checking. Such combinators would allow a design

    > by contract style in Joy but I'm not sure of their impact on the

    > functional purity of the language or what other theoretical

    > implications they may have.

    >

    > The only reason I havn't experimented much with this is that the main

    > place I find stack manipulation obtrusive is when it has to be

    > performed within other combinators. Use of stack multiplexers may help

    > a little with this but probably isn't much different from adding

    > variables to Joy! :-)

    >

    > Nick.

    >

    >

    >

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

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

    >

    >