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