|
List Info
Thread: #flatten for seq-collections, #join: for collection classes
|
|
| #flatten for seq-collections, #join:
for collection classes |
  United States |
2007-06-05 23:09:01 |
scompall nocandysw.com--2007-nocandy/smalltalk--backstage--2.2
--patch-26
(also attached) adds "flattening" to sequenceable
collections, and
"joining" to collection classes (or
"withAllWithAll:" . These
are
more or less equivalent, and both are present because while
the
"flatten" operation more naturally dispatches on
the collection class of
its result, it is more naturally the responsibility of the
collection
being flattened.
Because of the convenience of {}-syntax, flatten is also
useful as a
more efficient concatenation operator than #','. In fact,
this is what
I intended it for.
I didn't see "flattening" as something that could
be properly done to a
non-Sequenceable collection (out of order, as it were),
similarly to how
a non-sequenceable collection cannot be the with: in a
#copyReplaceFrom:to:with:. Joining is still available on
Collection.
If I am mistaken, I can fix it by moving #flatten: to
Collection and
adding a #flatten to Collection like:
flatten
^self isEmpty ifTrue: [#()]
ifFalse: [self flatten: self anyOne
species]
The #flatten: method was inspired by the aesthetic of
COMMON-LISP:CONCATENATE
<http://www.lispworks.com/documentation/Hy
perSpec/Body/f_concat.htm>.
One may note that #flatten shares with #from: an interesting
property:
it is designed to be used often with {}-expressions, where
such can be
efficiently compiler-optimized with Presource, my Smalltalk
compiler-extension goodie. If there is interest, I can show
how this CL
compiler-macro-like extension can be done, and perhaps
improve support
for compiler context-sensitivity (wrt current class,
category, and such)
in Presource's RewritingCompile.
--
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
Failure to imagine vast possibilities usually stems from a
lack of
imagination, not a lack of possibility.
_______________________________________________
help-smalltalk mailing list
help-smalltalk gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
|
|
|
| Re: #flatten for seq-collections,
#join: for collection classes |
  Italy |
2007-06-06 00:03:57 |
> Because of the convenience of {}-syntax, flatten is
also useful as a
> more efficient concatenation operator than #','. In
fact, this is what
> I intended it for.
Very cool! However, what about just calling #join also the
instance-side #flatten, and omitting the instance-side
#flatten: (which
is simpler to do with a class-side #join ?
#flatten is more for something like
#((1 2) 3 (4 5)) => 1 2 3 4 5
This can be done by adding a #flattenInto: method that does
"add: self"
or "self do: [ :each | each flattenInto: dest ]"
(the latter for
collections and streams).
As a nitpick, #inject:into: is slow -- streams might be
faster -- and
#fold: is nicer anyway for the size computation.
And after Lisp, Smalltalk mimics APL too! :-P
Thanks,
Paolo
_______________________________________________
help-smalltalk mailing list
help-smalltalk gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
|
|
| Re: #flatten for seq-collections,
#join: for collection classes |
  United States |
2007-06-06 00:53:33 |
On Wed, 2007-06-06 at 07:03 +0200, Paolo Bonzini wrote:
> Very cool! However, what about just calling #join also
the
> instance-side #flatten, and omitting the instance-side
#flatten: (which
> is simpler to do with a class-side #join ?
While coming up with a name for the instance-side (first
#concatenate,
then #join as it happens, then #flatten), I thought it
sounded too
general. How about #joinAll?
> #flatten is more for something like
>
> #((1 2) 3 (4 5)) => 1 2 3 4 5
More like (with Presource)
(#((1 2) 3 (4 5)) collect: #mklist sendingBlock) flatten
> This can be done by adding a #flattenInto: method that
does "add: self"
> or "self do: [ :each | each flattenInto: dest
]" (the latter for
> collections and streams).
>
> As a nitpick, #inject:into: is slow -- streams might be
faster
I can eliminate the second #inject:into: in ArrayColl.st
quite easily if
you are comfortable with
| newInst start |
newInst := ...
start := 1.
aCollection do: [:subColl |
"this start := thing right here...the stack is my
temporary storage "
subColl replaceFrom: start to: (start := start + subColl
size) - 1
with: subColl].
^newInst
Maybe I'm duplicating a little of what WriteStream does, but
I see the
main benefit of it as when tracking position isn't so
trivial or
resizing might be necessary.
> and #fold: is nicer anyway for the size computation.
like "(aCollection collect: [:each | each size]) fold:
[:a :b | a +
b]" ?
--
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
Failure to imagine vast possibilities usually stems from a
lack of
imagination, not a lack of possibility.
_______________________________________________
help-smalltalk mailing list
help-smalltalk gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
|
|
| Re: #flatten for seq-collections,
#join: for collection classes |
  United States |
2007-06-06 03:32:05 |
scompall nocandysw.com--2007-nocandy/smalltalk--backstage--2.2
--patch-27
also attached, which renames #flatten to #joinAll, removes
#flatten:,
and removes one use of #inject:into:.
--
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
Failure to imagine vast possibilities usually stems from a
lack of
imagination, not a lack of possibility.
_______________________________________________
help-smalltalk mailing list
help-smalltalk gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
|
|
|
| Re: #flatten for seq-collections,
#join: for collection classes |
  United States |
2007-06-06 12:14:21 |
On Wed, 2007-06-06 at 17:01 +0200, Paolo Bonzini wrote:
> Also, I was reading on monads recently and they call
exactly this
> operation "join" (in that case, the contained
items are supposed to be
> of the same kind of the cointainer -- but that's just a
special case).
>
> If you're not too negative, I'd rather keep the easy
name.
Join isn't too bad; it's less messy than #concatenate at
least.
--
;;; Stephen Compall ** http://scompall.no
candysw.com/blog **
Failure to imagine vast possibilities usually stems from a
lack of
imagination, not a lack of possibility.
_______________________________________________
help-smalltalk mailing list
help-smalltalk gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk
|
|
[1-5]
|
|