related to my previous post:
k has a combinator 'each' which resembles map. in joyish
terms, it takes a size n list of lists and an n-ary program
p and applies p to corresponding elements of the lists.
[[1 2 3][4 5 6]] [+] each
[5 7 9]
each is tolerant:
[1 [4 5 6]] [+] each
[5 6 7]
this is called "atomic extension". again, if transpose were
tolerant, 'each' could be defined (inefficiently) as
each == [transpose] dip [infra first] cons map
(in my version of joy - 15:46:02 may 13 2003 (NOBDW) - tranpose
doesn't work as i expected - shouldn't [[1 2 3][4 5 6]] tranpose
-> [[1 4][2 5][3 6]] ?)
the atomic primitives of k have a built-in each-to-the-atoms
recursion. e.g. [[1 2 3][4 5 6]] [+] each <-> [1 2 3][4 5 6] +.
On Thu, 29 May 2003, stevan apter wrote:
> related to my previous post:I agree that 'each' might indeed be a very useful addition to
>
> k has a combinator 'each' which resembles map. in joyish
> terms, it takes a size n list of lists and an n-ary program
> p and applies p to corresponding elements of the lists.
>
> [[1 2 3][4 5 6]] [+] each
> [5 7 9]
Joy, and some definition similar to yours would be right.
It resembles mapr2 (= zipwith) and the (unwritten) map2 for
Joy in the binary case at least. But it uses a single list
for the two list operands, rather than two separate lists.
For the binary case this would do:
each == [uncons uncons pop] dip mapr2 (or map2 in future)
But you are suggesting the most general case, perhaps even
n = 0:
[[1 2 3][4 5 6][7 8 9]] [+ +] each ==> [12 15 18]
[[1 2 3][4 5 6] ] [+ ] each ==> [5 7 9]
[[1 2 3] ] [succ] each ==> [2 3 4]
[ ] [42] each ==> [ ]
Yes, it does look like a sensible sort of combinator to have.
> each is tolerant:But, similar to the case at the end of my reply,
>
> [1 [4 5 6]] [+] each
> [5 6 7]
what do you do when the binary operator is not + but, say cons:
[[1 2 3] [[4] [5] [6]] [cons] each
==> [[1 4] [2 5] [3 6] ] ? ordinary each
==> [[[1 2 3] 4] [[1 2 3] 5] [[1 2 3] 6] ] ? "tolerance of each"
> this is called "atomic extension". again, if transpose wereIt works for me.
> tolerant, 'each' could be defined (inefficiently) as
>
> each == [transpose] dip [infra first] cons map
>
> (in my version of joy - 15:46:02 may 13 2003 (NOBDW) - tranpose
> doesn't work as i expected - shouldn't [[1 2 3][4 5 6]] tranpose
> -> [[1 4][2 5][3 6]] ?)
The 'transpose' operator is in the seqlib.joy "sequence" library,
and there is an identical one 'm-transpose-m' in the mtrlib.joy
"matrix" library.
> the atomic primitives of k have a built-in each-to-the-atomsBut I am not so sure about the built-in-each for the atoms,
> recursion. e.g. [[1 2 3][4 5 6]] [+] each <-> [1 2 3][4 5 6] +.
for two reasons: (1) It will only work for atoms, of course,
and for non-atomic operators to be 'each'ed over a list there
would still have to be a combinator 'each' to handle arbitrary
quotations. (2) There are likely to be some (perhaps not many)
cases of ambiguity arising:
[[1 2] [3]] [[4] [5 6]] concat
=> [[1 2] [3] [4] [5 6]] ? (concat of two lists)
=> [[1 2 4] [3 5 6]] ? (built-in-each for concat)
Thanks for the discussion.
- Manfred
----- Original Message -----
From: <phimvt@...>
To: <concatenative@yahoogroups.com>
Sent: Friday, May 30, 2003 2:36 AM
Subject: Re: [stack] atomic extension, each
>
> On Thu, 29 May 2003, stevan apter wrote:
>
> > related to my previous post:
> >
> > k has a combinator 'each' which resembles map. in joyish
> > terms, it takes a size n list of lists and an n-ary program
> > p and applies p to corresponding elements of the lists.
> >
> > [[1 2 3][4 5 6]] [+] each
> > [5 7 9]
>
> I agree that 'each' might indeed be a very useful addition to
> Joy, and some definition similar to yours would be right.
> It resembles mapr2 (= zipwith) and the (unwritten) map2 for
> Joy in the binary case at least. But it uses a single list
> for the two list operands, rather than two separate lists.
> For the binary case this would do:
> each == [uncons uncons pop] dip mapr2 (or map2 in future)
> But you are suggesting the most general case, perhaps even
> n = 0:
> [[1 2 3][4 5 6][7 8 9]] [+ +] each ==> [12 15 18]
> [[1 2 3][4 5 6] ] [+ ] each ==> [5 7 9]
> [[1 2 3] ] [succ] each ==> [2 3 4]
> [ ] [42] each ==> [ ]
> Yes, it does look like a sensible sort of combinator to have.
there are two specialized forms, which are also useful:
[10 20] [1 2 3] [+] right
[[11 21] [12 22] [13 23]]
[1 2 3] [10 20] [+] left
[[11 21] [12 22] [13 23]]
>
> > each is tolerant:
> >
> > [1 [4 5 6]] [+] each
> > [5 6 7]
>
> But, similar to the case at the end of my reply,
> what do you do when the binary operator is not + but, say cons:
>
> [[1 2 3] [[4] [5] [6]] [cons] each
> ==> [[1 4] [2 5] [3 6] ] ? ordinary each
> ==> [[[1 2 3] 4] [[1 2 3] 5] [[1 2 3] 6] ] ? "tolerance of each"
[[1 2 3] [[4] [5] [6]]] [cons] each
[[1 4] [2 5] [3 6]]
i.e.
1 [4] -> [1 4]
2 [5] -> [2 5]
3 [6] -> [3 6]
neither [1 2 3] nor [[4] [5] [6]] is an atom - they're both
lists of size 3.
>
> > this is called "atomic extension". again, if transpose were
> > tolerant, 'each' could be defined (inefficiently) as
> >
> > each == [transpose] dip [infra first] cons map
>
>
> >
> > (in my version of joy - 15:46:02 may 13 2003 (NOBDW) - tranpose
> > doesn't work as i expected - shouldn't [[1 2 3][4 5 6]] tranpose
> > -> [[1 4][2 5][3 6]] ?)
>
> It works for me.
> The 'transpose' operator is in the seqlib.joy "sequence" library,
> and there is an identical one 'm-transpose-m' in the mtrlib.joy
> "matrix" library.
ah - i haven't gotten to the point where i know how to work
with the joy libraries. i need to spend some time on this ...
i thought transpose was a primitive.
>
> > the atomic primitives of k have a built-in each-to-the-atoms
> > recursion. e.g. [[1 2 3][4 5 6]] [+] each <-> [1 2 3][4 5 6] +.
>
> But I am not so sure about the built-in-each for the atoms,
> for two reasons: (1) It will only work for atoms, of course,
> and for non-atomic operators to be 'each'ed over a list there
> would still have to be a combinator 'each' to handle arbitrary
> quotations.
in k (ck) there's a non-atomic operator 'find'
list x ? -> index of first occurrence of x in list
or list size if x not in list.
[[[10 20 30 20][40 50][60 70]] [20 30 60]] [?] each
[1 2 0]
'find' is the inverse of 'at'.
each penetrates just one level - whatever it finds there is
what it finds. but in APL, 'find' is "right-atomic". if x
is an atom, it behaves just like k's 'find'. but if x is a
list, then it penetrates to the atoms in x and does a 'find'
with that. the result has the structure of x. so there is
scope for deciding how primitives like 'find' behave.
(2) There are likely to be some (perhaps not many)
> cases of ambiguity arising:
> [[1 2] [3]] [[4] [5 6]] concat
> => [[1 2] [3] [4] [5 6]] ? (concat of two lists)
> => [[1 2 4] [3 5 6]] ? (built-in-each for concat)
right - concat shouldn't be atomic. i think that most primitives
are either obviously atomic (like +) or obviously not (like concat
and size). there are only a few (at least in my experience) which
aren't obviously one or the other (like 'find'), and in each such
case the standard sorts of deliberation are called for - ease of
use, typical cases, consistency with other cases, &c.
>
> Thanks for the discussion.
thank you!
>
> - 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/
>
>