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;
*
***
** *
** ****
** * *
** **** ***
** * * *
** **** ******
** * *** *
** **** ** * ***
** * * **** ** *
** **** ** * * ****
** * *** ** ** * *
** **** ** *** *** ** ***
** * * *** * *** * *
** **** ** * * ***** *******
** * *** **** * *** *
** **** ** *** ** ** * ***
** * * *** * ** *** **** ** *
** **** ** * ****** * * *** ****
** * *** **** **** *** ** * *
** **** ** *** * ** * * * *** ***
** * * *** * *** ** * *** ** * * * *
** **** ** * *** * * **** * * ** ******
** * *** **** ** ***** * ***** * * *
** **** ** *** * ** * * ** * ***** ***
Stevan Apter writes:
> stack manipulation sometimes feels clumsy. as i acquiteAlthough I don't often find working with the stack awkward I do find
> 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.
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.
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/
>
>