# strings, lists, symbols

## sa@dfa.com — 2003-05-21 18:15:06

    "abc" first .

    'a

     "abc" size .

    3

     "abc" leaf .

    true

     "abc" list .

    false

    if a string has size, and first is defined on it, why isn't it

    a list?  why isn't "..." rationalized as list-notation for characters?

    (in k, we have another datatype, symbols, which are leaves (leafs),

    written `abc)

## John Cowan — 2003-05-21 20:36:18

    sa@... scripsit:

     > if a string has size, and first is defined on it, why isn't it

    > a list?  why isn't "..." rationalized as list-notation for characters?

     Many Joy operations are polymorphic on lists and strings, but that does

    not make lists and strings the same.  In Scheme-Joy, sets are lists,

    but in C-Joy they are a distinct datatype.

     > (in k, we have another datatype, symbols, which are leaves (leafs),

    > written `abc)

     Joy has a symbol datatype too, but no way of notating it.  You can push

    the symbol foo on the stack with

    	"foo" intern

    or

    	[foo] first

    --

    "In my last lifetime,                           John Cowan

    I believed in reincarnation;                    http://www.ccil.org/~cowan

    in this lifetime,                               jcowan@...

    I don't."  --Thiagi                             http://www.reutershealth.com

## stevan apter — 2003-05-21 22:45:24

    From: "John Cowan" <cowan@...>

     > sa@... scripsit:

    >

    > > if a string has size, and first is defined on it, why isn't it

    > > a list?  why isn't "..." rationalized as list-notation for characters?

    >

    > Many Joy operations are polymorphic on lists and strings, but that does

    > not make lists and strings the same.  In Scheme-Joy, sets are lists,

    > but in C-Joy they are a distinct datatype.

     yes, i didn't have in mind that strings and lists should be the same

    datatype, internally or externally.  i was, in fact, questioning the

    decision to count strings as leafs (what IS the preferred plural here?).

    i've been thinking of a leaf as a thing without parts, whereas strings

    do seem to have parts, namely characters.  as you point out, joy sets

    also have size and parts (and they're leafs as well.)

## John Cowan — 2003-05-22 01:54:44

    stevan apter scripsit:

     > yes, i didn't have in mind that strings and lists should be the same

    > datatype, internally or externally.  i was, in fact, questioning the

    > decision to count strings as leafs (what IS the preferred plural here?).

     I'm not sure; leaves or leafs, either works for me.  But what makes lists

    fundamentally different from other aggregates is their use as quotations.

    So leaf simply means non-list (atom in Lisp).

    --

    And through this revolting graveyard of the universe the muffled, maddening

    beating of drums, and thin, monotonous whine of blasphemous flutes from

    inconceivable, unlighted chambers beyond Time; the detestable pounding

    and piping whereunto dance slowly, awkwardly, and absurdly the gigantic

    tenebrous ultimate gods --  the blind, voiceless, mindless gargoyles whose soul

    is Nyarlathotep. (Lovecraft) John Cowan|jcowan@...|ccil.org/~cowan

## stevan apter — 2003-05-22 02:41:16

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

    From: "John Cowan" <cowan@...>

    To: <concatenative@yahoogroups.com>

    Sent: Wednesday, May 21, 2003 9:54 PM

    Subject: Re: [stack] strings, lists, symbols

    > stevan apter scripsit:

    >

    > > yes, i didn't have in mind that strings and lists should be the same

    > > datatype, internally or externally.  i was, in fact, questioning the

    > > decision to count strings as leafs (what IS the preferred plural here?).

    >

    > I'm not sure; leaves or leafs, either works for me.  But what makes lists

    > fundamentally different from other aggregates is their use as quotations.

    > So leaf simply means non-list (atom in Lisp).

    take the list ['a 'b 'c].  0 at is 'a, 1 at is 'b, 2 at is 'c.

    take the string "abc".  the same is true, but ['a'b'c] != "abc".

    as far as i can see, the only context which distinguishes them

    is the leaf predicate (and those combinators which make implicit

    use of that predicate.)

    currently, concat isn't defined for characters.  but one could

    easily imagine that "ab" = 'a'b concat, and in general, that

    ['a'b'c...] flatten = "abc...".  ("a" != 'a of course.)

    so it seems like a short step to saying that ['a'b'c] and "abc"

    are just different ways of writing the same thing.

    this is the approach i've taken in ck, but here i'm just taking

    my lead from k.

    as you may know, various APLs have incorporated enclose/disclose

    operators, by means of which a list (array) can be turned into a

    scalar (atom).  e.g. <10 20 30, the enclose of the vector 10 20 30,

    is a scalar, ><10 20 30 discloses it.  some APLs say that scalar=

    <scalar, some treat them as different.  what makes something a

    scalar is that array operations can't "see" into its structure.

    what jars about joy strings is that they can be penetrated by

    some operations (first, at), seem to have structure (size), but

    can't be penetrated by others (map, step).

    ah, good old h.p., cheerful as ever ...

    >

    > --

    > And through this revolting graveyard of the universe the muffled, maddening

    > beating of drums, and thin, monotonous whine of blasphemous flutes from

    > inconceivable, unlighted chambers beyond Time; the detestable pounding

    > and piping whereunto dance slowly, awkwardly, and absurdly the gigantic

    > tenebrous ultimate gods --  the blind, voiceless, mindless gargoyles whose soul

    > is Nyarlathotep. (Lovecraft) John Cowan|jcowan@...|ccil.org/~cowan

    >

    >

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

    >

    >

## phimvt@lurac.latrobe.edu.au — 2003-05-23 07:41:40

    On Wed, 21 May 2003, stevan apter wrote:

    [...]

    > take the list ['a 'b 'c].  0 at is 'a, 1 at is 'b, 2 at is 'c.

    > take the string "abc".  the same is true, but ['a'b'c] != "abc".

    >

    > as far as i can see, the only context which distinguishes them

    > is the leaf predicate (and those combinators which make implicit

    > use of that predicate.)

    The really important difference between strings and lists is

    that lists can contain other lists, but strings cannot contain

    other strings - at least that is how it is in Joy.

    More generally, any language design has to make some decisions about

    whether to emphasise conceptual purity and efficiency. Most languages make

    some sort of compromise: forget about natural numbers, but have integers

    and reals, implemented differently. Booleans true and false? well integers

    will do - well maybe.. Strings are arrays - well maybe yes, maybe no. [I

    remember reading something clever about the finer points of this for C,

    but I cannot reconstruct it here]. Strings are just lists of characters?

    Maybe. Characters the same as unit strings? Maybe yes, maybe no. All sorts

    of considerations. Sets must allow set operations, and even the 32 bit

    sets of the original implementations of Pascal were very useful for the

    Pascal compiler - and I have found them useful for lots of stuff

    elsewhere. In C you can do it just with 32 bit integers - and that's how I

    implemented them in Joy. Lots of compromises everywhere. (Someone should

    write a book about it.) Anyhow, in Joy at least lists are just a special

    case of quotations.

    > currently, concat isn't defined for characters.  but one could

    > easily imagine that "ab" = 'a'b concat, and in general, that

    > ['a'b'c...] flatten = "abc...".  ("a" != 'a of course.)

    "flatten" as used in Lisp/Scheme terminology means: turn a list

    of lists into a single list. That is how it is currently implemented

    in the seqlib.joy library. But you remark made me look at it again:

    In Joy flatten should turn a list of aggregates into a single aggregate.

    This is what it should do:

      [ [peter paul] [3 6 1] ]   flatten   ==>   [peter paul 3 6 1]

      [ "hello there" " bye" ]   flatten   ==>   "hello there bye"

      [ {1 3 5 7 9} {2 4 20} ]   flatten   ==>   {1 2 3 4 5 7 9 20}

    I have implemented this in my working version of seqlib, and

    it will appear on the web page at the next update.

    > so it seems like a short step to saying that ['a'b'c] and "abc"

    > are just different ways of writing the same thing.

    Depending on the implementation of lists, there may or may not be

    an advantage in keeping them separate.

    > this is the approach i've taken in ck, but here i'm just taking

    > my lead from k.

    Can this approach deal with nested lists - homogeneous and also

    inhomogeneous, as in

        [ ['a 'b 'c] ['d 'e 'f] ['g 'h] ]

        [  'a 'b 'c  ['d 'e 'f]  'g 'h  ]

    [..]

    > what jars about joy strings is that they can be penetrated by

    > some operations (first, at), seem to have structure (size), but

    > can't be penetrated by others (map, step).

    I have aimed to make all structures "penetrable" whenever it

    makes sense:

        [1 2 3]  [dup *]  map       ==>    [1 4 9]

        {1 2 3}  [dup *]  map       ==>    {1 4 9}

         "JOY    [32  +]  map       ==>    "joy"

    Similarly for step. If I have missed some, please let me know.

     - Manfred

## stevan apter — 2003-05-23 14:12:19

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

    From: <phimvt@...>

    To: <concatenative@yahoogroups.com>

    Sent: Friday, May 23, 2003 3:41 AM

    Subject: Re: [stack] strings, lists, symbols

    >

    > On Wed, 21 May 2003, stevan apter wrote:

    >

    > [...]

    >

    > > take the list ['a 'b 'c].  0 at is 'a, 1 at is 'b, 2 at is 'c.

    > > take the string "abc".  the same is true, but ['a'b'c] != "abc".

    > >

    > > as far as i can see, the only context which distinguishes them

    > > is the leaf predicate (and those combinators which make implicit

    > > use of that predicate.)

    >

    > The really important difference between strings and lists is

    > that lists can contain other lists, but strings cannot contain

    > other strings - at least that is how it is in Joy.

    "abc\"def\"ghi" seems to do the right thing, at least under

    one interpretation of "contains".  this goes to an earlier

    reply by john on the topic, namely that lists play a special

    role in joy as executable program representations, i.e. as

    quotations.

    suppose joy had a primitive which took joy code-strings and

    parsed and executed them:

        "[2 3 4]" xeq

      [2 3 4]

    then

        "2 3 \"[+]\" xeq i" xeq

      5

    >

    > More generally, any language design has to make some decisions about

    > whether to emphasise conceptual purity and efficiency. Most languages make

    > some sort of compromise: forget about natural numbers, but have integers

    > and reals, implemented differently. Booleans true and false? well integers

    > will do - well maybe.. Strings are arrays - well maybe yes, maybe no. [I

    > remember reading something clever about the finer points of this for C,

    > but I cannot reconstruct it here]. Strings are just lists of characters?

    > Maybe. Characters the same as unit strings? Maybe yes, maybe no. All sorts

    > of considerations. Sets must allow set operations, and even the 32 bit

    > sets of the original implementations of Pascal were very useful for the

    > Pascal compiler - and I have found them useful for lots of stuff

    > elsewhere. In C you can do it just with 32 bit integers - and that's how I

    > implemented them in Joy. Lots of compromises everywhere. (Someone should

    > write a book about it.) Anyhow, in Joy at least lists are just a special

    > case of quotations.

    >

    > > currently, concat isn't defined for characters.  but one could

    > > easily imagine that "ab" = 'a'b concat, and in general, that

    > > ['a'b'c...] flatten = "abc...".  ("a" != 'a of course.)

    >

    > "flatten" as used in Lisp/Scheme terminology means: turn a list

    > of lists into a single list. That is how it is currently implemented

    > in the seqlib.joy library. But you remark made me look at it again:

    > In Joy flatten should turn a list of aggregates into a single aggregate.

    > This is what it should do:

    >   [ [peter paul] [3 6 1] ]   flatten   ==>   [peter paul 3 6 1]

    >   [ "hello there" " bye" ]   flatten   ==>   "hello there bye"

    >   [ {1 3 5 7 9} {2 4 20} ]   flatten   ==>   {1 2 3 4 5 7 9 20}

    > I have implemented this in my working version of seqlib, and

    > it will appear on the web page at the next update.

    in k, any two objects can be concatenated thus:

        1,2 -> 1 2

        "a","b" -> "ab"

        &c.

    the "over" combinator (a generalization of APL "reduce") takes a

    function and applies it successively to its previous result and

    the next element(s), so "flatten" can be defined as:

        ,/

    analogous to the definition of "sum" as +/.

        ,/("ab";"c";"defghi")        <- "c" is a char, "ab" is a list of two chars

    "abcdefghi"

    "scan" gives you a list of the intermediate states:

      ,\("ab";"c";"defghi")

    ("ab"

     "abc"

     "abcdefghi")

    >

    > > so it seems like a short step to saying that ['a'b'c] and "abc"

    > > are just different ways of writing the same thing.

    >

    > Depending on the implementation of lists, there may or may not be

    > an advantage in keeping them separate.

    >

    > > this is the approach i've taken in ck, but here i'm just taking

    > > my lead from k.

    >

    > Can this approach deal with nested lists - homogeneous and also

    > inhomogeneous, as in

    >     [ ['a 'b 'c] ['d 'e 'f] ['g 'h] ]

    >     [  'a 'b 'c  ['d 'e 'f]  'g 'h  ]

    k or ck?  in k we would write these as

          ("abc";"def";"gh")           <- 3 strings of size 3 3 2

          ("a";"b";"c";"def";"g";"h")  <- 3 chars, a list of size 3, 2 chars

    "a" is a character atom, "ab" is a character list (string), but

    to get the unit character list you've got to say

           ,"a"        / enlist character "a"

    in ck i've adopted joy notation, so

           [['a 'b 'c]['d 'e 'f]['g 'h]]

    displays as

           ["abc" "def" "gh"]

    and

           [  'a 'b 'c  ['d 'e 'f]  'g 'h  ]

    as

           ['a 'b 'c "def" 'g 'h]

    in both cases, the ck display algorithm finds the most compact

    representation, assuming that "..." is list notation for strings.

    >

    > [..]

    >

    > > what jars about joy strings is that they can be penetrated by

    > > some operations (first, at), seem to have structure (size), but

    > > can't be penetrated by others (map, step).

    >

    > I have aimed to make all structures "penetrable" whenever it

    > makes sense:

    >     [1 2 3]  [dup *]  map       ==>    [1 4 9]

    >     {1 2 3}  [dup *]  map       ==>    {1 4 9}

    >      "JOY    [32  +]  map       ==>    "joy"

    > Similarly for step. If I have missed some, please let me know.

    well, i was thinking mainly about the tree combinators, which stop

    at leaves.  those don't penetrate strings.

    >

    >  - Manfred

    >

    >

    >

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

    >

    >