Why isn't Perl highly orthogonal?
Terrence Brannon
One day my boss asked me: "how do you get the length of an array in
Perl?" So I told him:
scalar @array;
But of course what irked me is how unintuitive and irregular Perl is
and how this forced my boss to ask me something like that.
LENGTH $string => length $string
LENGTH @array => scalar @array
PORTION $string => substring $string, $offset, $length
PORTION @array => @array[$offset..$offset+$length]
In other words, conceptually similar operations do not map to the same
name in Perl. Why does this make Perl a better and not worse language,
than the intended replacement to Perl, Ruby, which is in fact highly
regular in all places where Perl isn't, with the above being just a
few examples?
--
Terrence Brannon
Dave Cross
The length of a string and the number of elemetns in an array really
aren't the same thing at all, so it makes sense to me that I find them
in different ways. The same goes for substrings and array slices.
Thinking of these concepts as similar seems to meto be a hangover from
C, where strings are arrays of characters, but surely we've moved on
since then.
Maybe your boss is a C programmer?
Dave...
--
<http://www.dave.org.uk> SMS: s...@dave.org.uk
Daniel Chetlin
Perhaps you and your boss see things differently from other programmers
regarding both of these examples. I don't think the majority of Perlers
identify the length of a string as similar to the size of an array. Why
not interpret `length @array' to mean the length of all array elements
combined? In fact, the Perlish way to determine the size of an array is
extremely natural to me, because the value of an array in scalar context
presents the ability to say `if (@array > 4)'. Wonderfully expressive,
and much more natural than `if (length @array > 4)', IMO. In your eyes,
which one seems better? Similar logic can be applied to your PORTIONs --
no Perl programmer equates substrings with slices. Why do you?
Generally, there is quite a major difference between strings and arrays
or even lists in Perl.
And I don't think you'll find that Ruby is different from Perl in this
way. A current thread on ruby-talk is the question of why String#sort
and Array#sort do what was perceived to be different things. I suspect
you would expect String#sort to sort by character, rather than by line.
-dlc
fbeel sbe gur gbegherq ynathntr; guvf vf uneq
Thelma Lubkin
: The length of a string and the number of elemetns in an array really
: aren't the same thing at all, so it makes sense to me that I find them
: in different ways. The same goes for substrings and array slices.
: Thinking of these concepts as similar seems to meto be a hangover from
: C, where strings are arrays of characters, but surely we've moved on
: since then.
: Maybe your boss is a C programmer?
if aray[8] can hold 8 5-character strings (ie aray's
elements are char*5), a C programmer would say it's a length
8 array, not a length 40 array.
Why the gratuitous insult to C programmers?
--thelma
who struggles along in both languages.
: Dave...
brian d foy
<the...@alpha2.csd.uwm.edu> wrote:
> In comp.lang.perl.misc Dave Cross <da...@dave.org.uk> wrote:
> : The length of a string and the number of elemetns in an array really
> : aren't the same thing at all, so it makes sense to me that I find them
> : in different ways. The same goes for substrings and array slices.
>
> : Thinking of these concepts as similar seems to meto be a hangover from
> : C, where strings are arrays of characters, but surely we've moved on
> : since then.
>
> : Maybe your boss is a C programmer?
>
> if aray[8] can hold 8 5-character strings (ie aray's
> elements are char*5), a C programmer would say it's a length
> 8 array, not a length 40 array.
it depends on what you mean by length. C programmers typically think
about the actual number of bytes they use, so length could mean a
couple of different things depending on the context.
but that's not what Dave was talking about. in Perl, a string is
not a sequence like it can be in some other languages. it is just
a scalar.
> Why the gratuitous insult to C programmers?
i don't see how "gratuitous" or "insult" have anything to do with
it.
> --thelma
> who struggles along in both languages.
which is perhaps why you missed the point.
--
brian d foy
Perl Mongers <URL:http://www.perl.org>
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
John Roth
Terrence Brannon <bra...@lnc.usc.edu> wrote in message
news:lby9xqj...@lnc.usc.edu...
The trouble with this is trying to figure out why on earth an
array should be conceptually similar to a string. There is a major
ambiguity here in that you either can regard a string as a single
entity, i.e. $String in Perl syntax, or as an array of characters,
i.e. @String. C choses the later mapping, and thus loses the
ability to manipulate strings as first class entities. Perl lost the
ability to resolve the ambiguity when Larry decided to make
$X and @X different variables. In the case of strings, they
clearly should be the same variable, with $X treating the
string as an entity, and @X treating it as an array of characters.
That would get rid of some of the string processing functions.
But that's not the way Perl grew.
Or would you rather have the ability to refer to characters
in a string as if they were mapped into a hash? "1st" -> 1,
"2nd" -> 2, etc. That would be really othogonal.
John Roth
>
Bart Lateur
>One day my boss asked me: "how do you get the length of an array in
>Perl?"
>But of course what irked me is how unintuitive and irregular Perl is
Didn't you even wonder why your boss insists on calling this "length"? I
call it "number of elements", or "count".
A string has a length. A string is not an array.
--
Bart.
Logan Shaw
Bart Lateur <bart....@skynet.be> wrote:
>Didn't you even wonder why your boss insists on calling this "length"? I
>call it "number of elements", or "count".
>
>A string has a length. A string is not an array.
No, but an array is a string. A Perl array may not be the same thing
as a Perl scalar, but that doesn't matter. (Especially since a Perl
scalar isn't really a scalar in the first place. But then again, an
integer in most languages is a bit vector, so they aren't scalars
either...)
- Logan
Ilmari Karonen
>i.e. @String. C choses the later mapping, and thus loses the
>ability to manipulate strings as first class entities. Perl lost the
>ability to resolve the ambiguity when Larry decided to make
>$X and @X different variables. In the case of strings, they
>clearly should be the same variable, with $X treating the
>string as an entity, and @X treating it as an array of characters.
>That would get rid of some of the string processing functions.
Well, you _can_ have it that way, if you want.
http://www.sci.fi/~iltzu/temp/CharArray.pm
Any comments? Should I try submitting it to the CPAN?
[Note followups.]
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental." -- nobull in clpm
David Steuber
' Didn't you even wonder why your boss insists on calling this "length"? I
' call it "number of elements", or "count".
'
' A string has a length. A string is not an array.
How long is a piece of string?
For some reason, it has never bothered me that to get the length of
$string you use a function called length (not unlike the C library
function strlen() and to get the number of elements in an array or
hash you evaluate it in a scaler context or use the scaler function.
The current piece of string that is giving me fits is the one that is
tied. Specifically, the entire tie business that is discussed in the
Camel book after discussing how objects are implimented. I get bless,
sort of. But how is tie different? It looks like two different ways
to do the same or similar thing.
I've also never understood the concept of orthogonality in a
programming language. C++ claims to be full of it. How this relates
to geometry is a complete mystery to me.
No, I am not drunk. I just received a severe blow to the head.
--
David Steuber | Perl apprentice. The axe did not stop the
NRA Member | mops and buckets from flooding my home.
ICQ# 91465842
*** http://www.david-steuber.com/ ***
Michael Carman
>
> [C]onceptually similar operations do not map to the same name
> than the intended replacement to Perl, Ruby, which is in fact highly
Heh. Careful, there! By whom is Ruby intended to be a replacement to
Perl? ;)
Most of the responses have centered on your example, not the subject of
your question. Perl is non-orthogonal by design. From 'perldoc perl'
"The language is intended to be practical (easy to use,
efficient, complete) rather than beautiful (tiny, elegant,
minimal)."
IIRC, Larry Wall has referred to Perl as being a "diagonal" language.
Instead of forcing a rigid method of doing things, Perl provides you
with options and allows you to choose the most natural (i.e. idiomatic)
method. Whether this is a good thing or a bad thing is largely a matter
of preference. If you want a minimal language, then it's awful. But if
you want to be able to write an arbitrary piece of code quickly and
concisely, then it's wonderful.
IMHO, orthogonality is overrated. It sounds nice on the surface, but you
invariably end up with a situation where you have to write some ugly
hack to get around the restrictions of the language.
-mjc
Mark-Jason Dominus
It most certainly is not.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f|ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
mi...@idocs.com
> IIRC, Larry Wall has referred to Perl as being a "diagonal" language.
> Instead of forcing a rigid method of doing things, Perl provides you
> with options and allows you to choose the most natural (i.e.
> idiomatic) method. Whether this is a good thing or a bad thing is
> largely a matter of preference. If you want a minimal language, then
> it's awful. But if you want to be able to write an arbitrary piece of
> code quickly and concisely, then it's wonderful.
Since we're on the topic of public perceptions of Perl, I'd like to
bring up something that's bothered me for quite a while. Why is Perl so
commonly described as "ugly" and "difficult"? When I first needed to
learn Perl I approached it with a sense of foreboding because I had been
told many times about how ugly the language is. One llama book and one
camel book later I still hadn't gotten to the "ugly" part. Four years
later I STILL haven't found the ugly part.
I think a lot of the perception has something to do with regular
expressions. Granted, regexes can get pretty confusing, but only to the
degree that the endeavor itself is confusing, and unlike most
languages, no MORE confusing than the endeavor itself. For example, if I
wanted to crunch down all whitespace to single spaces (as I often do
with web-based data entry), it's certainly simpler to use this code:
$name =~ s/\s+/ /g;
then the character-by-character looping that is necessary in languages
like Visual Basic. (That's not quite true anymore because most
languages help you with string processing with ... regular expressions!)
Furthermore, Perl has a wonderfully short DTHW (Distance To Hello
World). Ever notice that most Java books don't even get to Hello World
until the second chapter? That's because you have to learn all the
concepts before you even get to do something simple. Don't get me wrong,
I love Java, but it's hardly "simpler" than Perl.
OK, I'm done venting. This thread has just brought up the frustration I
sometimes feel when I'm working in other languages and I miss the
simplicity, conciseness and beauty of Perl.
-miko
--
Miko O'Sullivan
Author of The Mikodocs Guide to HTML
http://www.mikodocs.com/tags/
Sent via Deja.com http://www.deja.com/
Before you buy.
Craig Berry
: Most of the responses have centered on your example, not the subject of
: your question. Perl is non-orthogonal by design. From 'perldoc perl'
:
: "The language is intended to be practical (easy to use,
: efficient, complete) rather than beautiful (tiny, elegant,
: minimal)."
The odd thing is that I used to be an orthogonality zealot, but have come
over time to regard Perl as beautiful.
To my way of thinking, Perl is nonorthogonal in many of the same ways and
for the same reasons that human languages are nonorthogonal. If I wish to
tell someone I am happy, I have an infinite number of ways to express
myself, from quasi-synonyms (happy|glad|joyous|pleased|...) to grammatical
arrangements (I am happy|I have been made happy|Happiness fills me). This
allows me to shade meanings and extra intentional layers into what I say.
I would once have been offended that Perl provides a grep built-in which
can be trivially implement in terms of map. Now, I see this as a very
useful semantic-level feature, a way to convey intention (to myself six
months from now, to maintenance programmers) and to express that intention
idiomaticly.
: IMHO, orthogonality is overrated. It sounds nice on the surface, but you
: invariably end up with a situation where you have to write some ugly
: hack to get around the restrictions of the language.
Amen. I'm reminded of a comparison I once heard between APL and LISP:
"APL is a flawless diamond, perfect, symmetrical, an irreducible whole.
But add anything to it, and it's ruined. LISP is a bucket of mud; add
anything to it, and it's still a bucket of mud."
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "The hills are burning, and the wind is raging; and the clock
| strikes midnight in the Garden of Allah." - Don Henley
Craig Berry
: Since we're on the topic of public perceptions of Perl, I'd like to
: bring up something that's bothered me for quite a while. Why is Perl so
: commonly described as "ugly" and "difficult"? When I first needed to
: learn Perl I approached it with a sense of foreboding because I had been
: told many times about how ugly the language is. One llama book and one
: camel book later I still hadn't gotten to the "ugly" part. Four years
: later I STILL haven't found the ugly part.
I just hit the perfect analogy for Perl vs. orthogonal languages. Perl is
a blank canvas, a set of brushes, and a palette of oil paints. Highly
orthogonal languages are an etch-a-sketch.
Consider that an unskilled, esthetically challenged artist will do nothing
but make a mess given the artistic tools to work with. Lines will be
wrong, color choices horrid, forms muddled and warped. Conversely, that
same person can, without any effort or training, use the etch-a-sketch to
produce a perfectly straight, perfectly even line, and with only a little
practice will be able to produce simple but very clean drawings consisting
of vertical and horizontal lines.
Of course, an artist will be horribly constrained by the etch-a-sketch,
and will be able to create beauty using the brushes and paint.
Perl can be quite ugly when misapplied, or profoundly beautiful when
wielded with skill and talent. A 'diagonal language', indeed...
: I think a lot of the perception has something to do with regular
: expressions.
Regexes are a language within the language, of course.
: OK, I'm done venting. This thread has just brought up the frustration I
: sometimes feel when I'm working in other languages and I miss the
: simplicity, conciseness and beauty of Perl.
Language arguments are usually silly. To steal someone's analogy from the
other day, to answer 'which is faster, a porsche or a snowplow?', you need
to know something about the road conditions. :)
Brian Wisti
----- Original Message -----
From: "Craig Berry" <cbe...@cinenet.net>
To: "ruby-talk ML" <ruby...@netlab.co.jp>
Sent: Monday, December 11, 2000 1:40 PM
Subject: [ruby-talk:7056] Re: Why do people think Perl is ugly? (Vent); was:
Why isn't Perl highly orthogonal?
--snipped --
> Of course, an artist will be horribly constrained by the etch-a-sketch,
> and will be able to create beauty using the brushes and paint.
I agree with what you said, but this comment provoked me a little. My
mother always told me "a good artist never blames his tools." I think the
same should be said for programming languages.
Then again, I'm always griping about Java's etch-a-sketch-iness, so never
mind :)
Brian
(two weeks with Ruby, coming in by way of Perl and Python)
Mathieu Bouchard
> can be trivially implement in terms of map. Now, I see this as a very
> useful semantic-level feature,
If you like that kind of "redundancy", Ruby has a lot of it. Oh, by the
way, this is the, hum, Ruby, hum, mailing-list.
> Amen. I'm reminded of a comparison I once heard between APL and LISP:
> "APL is a flawless diamond, perfect, symmetrical, an irreducible whole.
But it is not. Second-order operators can only be passed built-in
first-order operators. You cannot build your own second-order operators.
Then at least you can write your own first-order operators, with dynamic
scoping. The rest is a bunch of gotos.
matju
Tad McClellan
>Terrence Brannon wrote:
>>
>> [C]onceptually similar operations do not map to the same name
>> in Perl. Why does this make Perl a better and not worse language,
>> than the intended replacement to Perl, Ruby, which is in fact highly
>> regular in all places where Perl isn't [...]
>Most of the responses have centered on your example, not the subject of
>your question. Perl is non-orthogonal by design.
[snip man page quote]
Larry writes about the natural language concepts in Perl:
http://www.wall.org/~larry/natural.html
>IIRC, Larry Wall has referred to Perl as being a "diagonal" language.
He also said in a Dr. Dobb's Journal interview, Feb 1998:
Well, there are many different definitions of artistic beauty.
It can be argued that it's symmetry, which in a computer
language might be considered orthogonality. It's also been
argued that broken symmetry is what is considered most
beautiful and most artistic and diverse. Symmetry breaking
is the root of our whole universe according to physicists,
so if God is an artist, then maybe that's his definition
of what beauty is.
>IMHO, orthogonality is overrated.
Sorry I can't find a citation for this (paraphrased) Larry quote:
symmetry is overrated, overrated is symmetry
I think it was on a mailing list where I saw it...
--
Tad McClellan SGML consulting
ta...@metronet.com Perl programming
Fort Worth, Texas
Rafael Garcia-Suarez
>
> Perl is non-orthogonal by design. From 'perldoc perl'
>
> "The language is intended to be practical (easy to use,
> efficient, complete) rather than beautiful (tiny, elegant,
> minimal)."
Moreover, the Perl language has not been designed from the ground up
(like Java, for example); it's a lot simpler to learn if you're already
used to sh, sed, awk and C.
--
# Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
Logan Shaw
Rafael Garcia-Suarez <rgarci...@free.fr> wrote:
>Moreover, the Perl language has not been designed from the ground up
>(like Java, for example); it's a lot simpler to learn if you're already
Java was only designed from the ground up if C++ is the ground.
Note: even though I disagree with your assessment of Java, I do think
that it was a good pun, although it would have been better if you
could have worked the word "beans" in somehow.
- Logan
Jos Backus
> I would once have been offended that Perl provides a grep built-in which
> can be trivially implement in terms of map.
<off-topic>
Isn't it the other way around? You can't make map return a smaller number of
elements than it was called with, unlike grep.
</off-topic>
--
Jos Backus _/ _/_/_/ "Modularity is not a hack."
_/ _/ _/ -- D. J. Bernstein
_/ _/_/_/
_/ _/ _/ _/
jo...@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer;
Ben Tilly
>
>On Tue, Dec 12, 2000 at 05:09:39AM +0900, Craig Berry wrote:
> > I would once have been offended that Perl provides a grep built-in which
> > can be trivially implement in terms of map.
>
><off-topic>
>Isn't it the other way around? You can't make map return a smaller number
>of
>elements than it was called with, unlike grep.
></off-topic>
I suspect that this thread is showing up on the mailing list
from a thread cross-posted to a Perl group. (At least it
started that way.) Wouldn't it make sense to have the mailing
list not get cross-posted threads? (Particularly since our
responses won't be cross-posted.)
Answering the question, in Perl the list of returns to map
is turned into one long list and returned. A sub that
returns the original element or the original element based
on a test would make map() work like grep(). In fact this
is pretty much how grep() is implemented.
In Ruby the two concepts are orthogonal. I don't yet know
if you can have a function that returns different numbers
of elements different times. Certainly the first thing I
tried to do with map was return 2 elements for 1. (Looking
at a case where I know current production versions of Perl
doesn't scale.) I couldn't see how to do it. And grep
itself cannot be used with arbitrary blocks. (Therefore
it is truer to the actual name of the function!)
I have some ideas for extensions to Ruby's map function
which would make it more powerful. Basically have it
send the block arguments in chunks of whatever number of
arguments the block wants, and then have it just push all
of the output into a single return array. I don't know if
this makes any sense/fits in Ruby's semantics though.
Until I finish reading the book take this as an observation
from someone without a good sense for Ruby.
Cheers,
Ben
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
David Alan Black
On Fri, 15 Dec 2000, Ben Tilly wrote:
(map & grep)
> In Ruby the two concepts are orthogonal. I don't yet know
> if you can have a function that returns different numbers
> of elements different times. Certainly the first thing I
> tried to do with map was return 2 elements for 1. (Looking
> at a case where I know current production versions of Perl
> doesn't scale.) I couldn't see how to do it. And grep
> itself cannot be used with arbitrary blocks. (Therefore
> it is truer to the actual name of the function!)
(I remember being relieved when I discovered find_all, after trying
to get grep to act like Perl's grep.)
As for map mapping two(or more)-for-one, I've done it, when needed,
along these lines:
[1,2,3,4,5].map do |e| [e,-e] end .flatten
=> [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
David
--
David Alan Black
home: dbl...@candle.superlink.net
work: blac...@shu.edu
Web: http://pirate.shu.edu/~blackdav
Ben Tilly
>
>Hello --
>
>On Fri, 15 Dec 2000, Ben Tilly wrote:
>
> (map & grep)
> > In Ruby the two concepts are orthogonal. I don't yet know
> > if you can have a function that returns different numbers
> > of elements different times. Certainly the first thing I
> > tried to do with map was return 2 elements for 1. (Looking
> > at a case where I know current production versions of Perl
> > doesn't scale.) I couldn't see how to do it. And grep
> > itself cannot be used with arbitrary blocks. (Therefore
> > it is truer to the actual name of the function!)
>
>(I remember being relieved when I discovered find_all, after trying
>to get grep to act like Perl's grep.)
>
>As for map mapping two(or more)-for-one, I've done it, when needed,
>along these lines:
>
>[1,2,3,4,5].map do |e| [e,-e] end .flatten
> => [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
>
array of arrays, it doesn't work right.
Think for a second of the "array with indices" map that
someone did. That could be as simple as
ary.each_index.map do |i| i, ary[i] end
But my current guess is that Ruby doesn't have the
list-oriented nature of Perl, nor is there an easy way to
make it fit. Which is a feature I will miss, but I have
to admit that simply because it was such an unusual
feature of Perl, it is rarely stressed. Authors of books
don't realize what a unifying concept it is. Students
don't know to look for it. So while I find it useful, I
don't know that it fits with the principle of least
surprise.
(Yeah, I know how to imitate a list-oriented nature by
always working with through an array. But that is a
bad hack.)
David Alan Black
> David Alan Black <dbl...@candle.superlink.net> wrote:
> >
> >As for map mapping two(or more)-for-one, I've done it, when needed,
> >along these lines:
> >
> >[1,2,3,4,5].map do |e| [e,-e] end .flatten
> > => [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
> >
> I thought of that. But if you want your output to be an
> array of arrays, it doesn't work right.
Just don't .flatten it:
[1,2,3,4,5].map do |e| [e,-e] end
=> [[1, -1], [2, -2], [3, -3], [4, -4], [5, -5]]
(I thought the flattened version was more what you'd meant,
but anyway, either is possible.)
> Think for a second of the "array with indices" map that
> someone did.
That was me :-)
> That could be as simple as
>
> ary.each_index.map do |i| i, ary[i] end
You've introduced the list syntax here (and I do understand that it
isn't meant as a working example), but you've also turned each_index
from an iterator into the equivalent of:
(0...ary.size).to_a
Probably not worth it :-) Actually, my quest for map_to_indices
was brought about in part by dislike of the look of this:
(0...ary.size).map do |i| ... end
which was the only way I could think of to iterate through indices and
return a mapping. Anyway, as for the
i, ary[i]
part, I'm not sure why that can't be the return (exit?) value of an
iterator block, as it can for method definitions. Then again... when
you
return a,b
from a method, you are returning [a,b].
Ben Tilly
>
>On Fri, 15 Dec 2000, Ben Tilly wrote:
>
> > David Alan Black <dbl...@candle.superlink.net> wrote:
> > >
> > >As for map mapping two(or more)-for-one, I've done it, when needed,
> > >along these lines:
> > >
> > >[1,2,3,4,5].map do |e| [e,-e] end .flatten
> > > => [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
> > >
> > I thought of that. But if you want your output to be an
> > array of arrays, it doesn't work right.
>
>Just don't .flatten it:
>
>[1,2,3,4,5].map do |e| [e,-e] end
> => [[1, -1], [2, -2], [3, -3], [4, -4], [5, -5]]
>
>(I thought the flattened version was more what you'd meant,
>but anyway, either is possible.)
Um, what if you want to do your array with indices map
on an array like the above? .flatten is recursive, which
means that a list of list of list of lists turns into a
single list!
Anyways, you could do it correctly with the following ugly
method.
Class Array
def flatten_one()
out # Do I need this? Need to check scoping rules
for i in self do
for j in i do
out.push j
end
end
out
end
end
> > Think for a second of the "array with indices" map that
> > someone did.
>
>That was me :-)
Wasn't sure.
> > That could be as simple as
> >
> > ary.each_index.map do |i| i, ary[i] end
>
>You've introduced the list syntax here (and I do understand that it
>isn't meant as a working example), but you've also turned each_index
>from an iterator into the equivalent of:
>
> (0...ary.size).to_a
>
>Probably not worth it :-) Actually, my quest for map_to_indices
>was brought about in part by dislike of the look of this:
>
> (0...ary.size).map do |i| ... end
>
>which was the only way I could think of to iterate through indices and
>return a mapping. Anyway, as for the
>
> i, ary[i]
>
>part, I'm not sure why that can't be the return (exit?) value of an
>iterator block, as it can for method definitions. Then again... when
>you
>
> return a,b
>
>from a method, you are returning [a,b].
>
You answered your own question I think. :-)
I don't think that Ruby is list-oriented or that list-oriented
ways of thinking are a good fit for it. Having lists with
variable numbers of arguments is not part of the basic design
and I don't think should be hacked on top when it doesn't fit
conceptually.
Not a big deal.
David Alan Black
> David Alan Black <dbl...@candle.superlink.net> wrote:
> > > >
> > > >[1,2,3,4,5].map do |e| [e,-e] end .flatten
> > > > => [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
> > > >
> > > I thought of that. But if you want your output to be an
> > > array of arrays, it doesn't work right.
> >
> >Just don't .flatten it:
> >
> >[1,2,3,4,5].map do |e| [e,-e] end
> > => [[1, -1], [2, -2], [3, -3], [4, -4], [5, -5]]
> >
> >(I thought the flattened version was more what you'd meant,
> >but anyway, either is possible.)
>
> Um, what if you want to do your array with indices map
> on an array like the above? .flatten is recursive, which
> means that a list of list of list of lists turns into a
> single list!
I'm not sure what it is you're saying wouldn't work. For example:
a = [1,2,3,4,5]
b = a.map do |e| [e,-e] end
c = b.map_with_indices do |e,i| "element #{i} is #{e.inspect}" end
p c[2] # => "element 2 is [3, -3]"
The .flatten was only to illustrate (one version of) map (with a
little help :-) producing an array with more elements than the input
array. (Are we talking past each other on some aspect of this?)
[...]
> > (0...ary.size).map do |i| ... end
> >
> >which was the only way I could think of to iterate through indices
> >and return a mapping. Anyway, as for the
> >
> > i, ary[i]
> >
> >part, I'm not sure why that can't be the return (exit?) value of an
> >iterator block, as it can for method definitions. Then again...
> >when you
> >
> > return a,b
> >
> >from a method, you are returning [a,b].
> >
> You answered your own question I think. :-)
Yes and no. I probably should have written "In fact" rather than
"Then again", above. My first line of thought was: since the method
syntax turns a,b into [a,b] anyway, it's no big deal that we have to
write [a,b] in the iterator block. But I do wonder now why the same
a,b syntax isn't allowed in such a block (where it would return [a,b])
-- no implications of non-Ruby-esque list behavior).
Ben Tilly
>On Fri, 15 Dec 2000, Ben Tilly wrote:
>
> > David Alan Black <dbl...@candle.superlink.net> wrote:
> > > > >
> > > > >[1,2,3,4,5].map do |e| [e,-e] end .flatten
> > > > > => [1, -1, 2, -2, 3, -3, 4, -4, 5, -5]
> > > > >
> > > > I thought of that. But if you want your output to be an
> > > > array of arrays, it doesn't work right.
> > >
> > >Just don't .flatten it:
> > >
> > >[1,2,3,4,5].map do |e| [e,-e] end
> > > => [[1, -1], [2, -2], [3, -3], [4, -4], [5, -5]]
> > >
> > >(I thought the flattened version was more what you'd meant,
> > >but anyway, either is possible.)
> >
> > Um, what if you want to do your array with indices map
> > on an array like the above? .flatten is recursive, which
> > means that a list of list of list of lists turns into a
> > single list!
>
>I'm not sure what it is you're saying wouldn't work. For example:
>
>a = [1,2,3,4,5]
>b = a.map do |e| [e,-e] end
>c = b.map_with_indices do |e,i| "element #{i} is #{e.inspect}" end
>
>p c[2] # => "element 2 is [3, -3]"
I was thinking of the following:
a = [1, [], [3,4,[]]]
Pass that to flatten and you will get [1,3,4]. which is
likely not what someone with that data structure intended
to do!
>The .flatten was only to illustrate (one version of) map (with a
>little help :-) producing an array with more elements than the input
>array. (Are we talking past each other on some aspect of this?)
I think so. I know how to get an array to wind up with more
elements than it started with. But the flatten method is
unlikely to do what you wanted.
Incidentally I did discover an amusing gotcha in Ruby that
comes from the implicit recursion in a lot of functions.
a = []
a.push a
a <=> a
Having thought about it, I think this is an appropriate
response.
[...]
>Yes and no. I probably should have written "In fact" rather than
>"Then again", above. My first line of thought was: since the method
>syntax turns a,b into [a,b] anyway, it's no big deal that we have to
>write [a,b] in the iterator block. But I do wonder now why the same
>a,b syntax isn't allowed in such a block (where it would return [a,b])
> -- no implications of non-Ruby-esque list behavior).
I don't have enough of a sense yet to even try to say what
Ruby-esque behaviour should be. Sorry.
Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
David Alan Black
On Fri, 15 Dec 2000, Ben Tilly wrote:
> David Alan Black <dbl...@candle.superlink.net> wrote:
> >I'm not sure what it is you're saying wouldn't work. For example:
> >
> >a = [1,2,3,4,5]
> >b = a.map do |e| [e,-e] end
> >c = b.map_with_indices do |e,i| "element #{i} is #{e.inspect}" end
> >
> >p c[2] # => "element 2 is [3, -3]"
>
> I was thinking of the following:
>
> a = [1, [], [3,4,[]]]
>
> Pass that to flatten and you will get [1,3,4]. which is
> likely not what someone with that data structure intended
> to do!
Right. But who's passing anything to flatten? Hmmm.... Maybe you're
still thinking of my original example? But even there, the flattening
affects only the result array, not the input array:
[1, [], [3,4,[]]] .map do |e| [e.inspect, "hello"] end .flatten
=> ["1", "hello", "[]", "hello", "[3, 4, []]", "hello"]
The flattening was just to show that you can get more elements out
than you put in, which I think was what you originally said you'd had
trouble with. If you don't flatten (which is fine with me -- really!
I don't mind! :-) then you get an array of arrays -- which may be what
one wants in a given case, but would not have made the point.
And (just to clarify) my map_with_indices method doesn't flatten
anything. It just, umm, maps with indices:
a = [1, [], [3,4,[]]]
a.map_with_indices do |e,i| puts "element #{i} is #{e.inspect}" end
element 0 is 1
element 1 is []
element 2 is [3, 4, []]
> >Yes and no. I probably should have written "In fact" rather than
> >"Then again", above. My first line of thought was: since the method
> >syntax turns a,b into [a,b] anyway, it's no big deal that we have to
> >write [a,b] in the iterator block. But I do wonder now why the same
> >a,b syntax isn't allowed in such a block (where it would return [a,b])
> > -- no implications of non-Ruby-esque list behavior).
>
> I don't have enough of a sense yet to even try to say what
> Ruby-esque behaviour should be. Sorry.
Don't apologize :-) I just meant that it seemed to me that a,b could
behave in iterator blocks as it does in method definitions -- i.e.,
that the a,b syntax per se did not have to introduce ambiguities or
imply unexpected list behavior. My characterization of it in terms of
Ruby-esque-ness was really just referring back to your earlier
statement:
I don't think that Ruby is list-oriented or that list-oriented ways
of thinking are a good fit for it. Having lists with variable numbers
of arguments is not part of the basic design and I don't think should
be hacked on top when it doesn't fit conceptually.
Now, come on Ben, admit it -- there's just a *little* bit of
willingness to say what is and is not Ruby-esque creeping in around
the edges, isn't there? :-)
Ben Tilly
>
>Hello --
>
>On Fri, 15 Dec 2000, Ben Tilly wrote:
>
> > David Alan Black <dbl...@candle.superlink.net> wrote:
> > >I'm not sure what it is you're saying wouldn't work. For example:
> > >
> > >a = [1,2,3,4,5]
> > >b = a.map do |e| [e,-e] end
> > >c = b.map_with_indices do |e,i| "element #{i} is #{e.inspect}" end
> > >
> > >p c[2] # => "element 2 is [3, -3]"
> >
> > I was thinking of the following:
> >
> > a = [1, [], [3,4,[]]]
> >
> > Pass that to flatten and you will get [1,3,4]. which is
> > likely not what someone with that data structure intended
> > to do!
>
>Right. But who's passing anything to flatten? Hmmm.... Maybe you're
>still thinking of my original example? But even there, the flattening
>affects only the result array, not the input array:
I was talking about your hack to have a map return multiple
values, map to anon arrays then flatten. That hack will
not work on all data structures because flatten is
recursive. Your original map_with_indices didn't have
that problem.
>[1, [], [3,4,[]]] .map do |e| [e.inspect, "hello"] end .flatten
>
> => ["1", "hello", "[]", "hello", "[3, 4, []]", "hello"]
>
>The flattening was just to show that you can get more elements out
>than you put in, which I think was what you originally said you'd had
>trouble with. If you don't flatten (which is fine with me -- really!
>I don't mind! :-) then you get an array of arrays -- which may be what
>one wants in a given case, but would not have made the point.
I had trouble doing a straight map which returned more. When
you flatten or push, that is behaviour I understand. Some
context. In current production versions of Perl:
%some_hash = map {($_, 1)} @some_array;
is slow even though push is fast. I was trying to test that
in Ruby. But since that idiom is not supported directly, there
was nothing to test.
>And (just to clarify) my map_with_indices method doesn't flatten
>anything. It just, umm, maps with indices:
>
I knew that. I was talking about your map then flatten trick
to map an array of one size to one of different size.
[...]
> > I don't have enough of a sense yet to even try to say what
> > Ruby-esque behaviour should be. Sorry.
>
>Don't apologize :-) I just meant that it seemed to me that a,b could
>behave in iterator blocks as it does in method definitions -- i.e.,
>that the a,b syntax per se did not have to introduce ambiguities or
>imply unexpected list behavior. My characterization of it in terms of
>Ruby-esque-ness was really just referring back to your earlier
>statement:
>
> I don't think that Ruby is list-oriented or that list-oriented ways
> of thinking are a good fit for it. Having lists with variable numbers
> of arguments is not part of the basic design and I don't think should
> be hacked on top when it doesn't fit conceptually.
>
>Now, come on Ben, admit it -- there's just a *little* bit of
>willingness to say what is and is not Ruby-esque creeping in around
>the edges, isn't there? :-)
>
Willingness does not equal ability. I was putting out a guess
based on an impression. The fact that you (with more
experience) didn't think my impression was obvious suggests that
I am missing something.
John Small
I have Ruby 1.6.1 built configured for WinNT using VC++.
The config.h file defines HAVE_ALLOCA but not HAVE_ALLOCA_H.
If I use the ALLOCA_N() macro in a C extension I get the warning
alloca not defined, assume returns int, which is probably okay as a pointer?
John
David Alan Black
> David Alan Black <dbl...@candle.superlink.net> wrote:
> >
> I was talking about your hack to have a map return multiple
> values, map to anon arrays then flatten. That hack will
> not work on all data structures because flatten is
> recursive. Your original map_with_indices didn't have
> that problem.
I'm totally lost now. As far as I can tell, this example:
> >[1, [], [3,4,[]]] .map do |e| [e.inspect, "hello"] end .flatten
> >
> > => ["1", "hello", "[]", "hello", "[3, 4, []]", "hello"]
showed that the business of mapping 2-for-one (using the flatten
"hack") *does* work with multidimensional arrays. Can you write
a little example showing a case where things get excessively
flattened?
> > I don't think that Ruby is list-oriented or that list-oriented ways
> > of thinking are a good fit for it. Having lists with variable numbers
> > of arguments is not part of the basic design and I don't think should
> > be hacked on top when it doesn't fit conceptually.
> >
> >Now, come on Ben, admit it -- there's just a *little* bit of
> >willingness to say what is and is not Ruby-esque creeping in around
> >the edges, isn't there? :-)
> >
> Willingness does not equal ability. I was putting out a guess
> based on an impression. The fact that you (with more
> experience) didn't think my impression was obvious suggests that
> I am missing something.
Heavens -- I'm not particularly experienced. I'm a Book Baby (late
October) :-) I'm a bit lost on this part of the thread too. But
it's OK.
David Alan Black
> When you inspect you flatten the data into a string. So you have
> an array of pairs of strings, and flattening doesn't do anything
> surprising. Try this:
>
> a = [1, [], [3,4,[]]] .map do |e| [e, "hello"] end .flatten
> print a.inspect
>
> See the extra flattening now?
Yes. I'd completely not noticed the fact that my version only
"worked" because I was inspecting the block variable, not the
resulting array.
By the way, I think we're setting a record for subject-line
irrelevance in this thread :-) But it's probably played out --
see you in the next one....
Ben Tilly
>
>On Sat, 16 Dec 2000, Ben Tilly wrote:
>
> > David Alan Black <dbl...@candle.superlink.net> wrote:
> > >
> > I was talking about your hack to have a map return multiple
> > values, map to anon arrays then flatten. That hack will
> > not work on all data structures because flatten is
> > recursive. Your original map_with_indices didn't have
> > that problem.
>
>I'm totally lost now. As far as I can tell, this example:
>
> > >[1, [], [3,4,[]]] .map do |e| [e.inspect, "hello"] end .flatten
> > >
> > > => ["1", "hello", "[]", "hello", "[3, 4, []]", "hello"]
>
>showed that the business of mapping 2-for-one (using the flatten
>"hack") *does* work with multidimensional arrays. Can you write
>a little example showing a case where things get excessively
>flattened?
When you inspect you flatten the data into a string. So you have
an array of pairs of strings, and flattening doesn't do anything
surprising. Try this:
a = [1, [], [3,4,[]]] .map do |e| [e, "hello"] end .flatten
print a.inspect
See the extra flattening now?
[...]
> > Willingness does not equal ability. I was putting out a guess
> > based on an impression. The fact that you (with more
> > experience) didn't think my impression was obvious suggests that
> > I am missing something.
>
>Heavens -- I'm not particularly experienced. I'm a Book Baby (late
>October) :-) I'm a bit lost on this part of the thread too. But
>it's OK.
Heh.
Sorry about not getting right back on this. Some personal
stuff came up.
Terrence Brannon
> Terrence Brannon wrote:
> >
> > [C]onceptually similar operations do not map to the same name
> > in Perl. Why does this make Perl a better and not worse language,
> > than the intended replacement to Perl, Ruby, which is in fact highly
> > regular in all places where Perl isn't [...]
>
> Heh. Careful, there! By whom is Ruby intended to be a replacement to
> Perl? ;)
>
> Most of the responses have centered on your example, not the subject of
> your question. Perl is non-orthogonal by design. From 'perldoc perl'
>
> "The language is intended to be practical (easy to use,
> efficient, complete) rather than beautiful (tiny, elegant,
> minimal)."
well, thanks. This clears things up. I do recall reading this many
years ago when first finding Perl.
>
> IIRC, Larry Wall has referred to Perl as being a "diagonal" language.
> Instead of forcing a rigid method of doing things, Perl provides you
> with options and allows you to choose the most natural (i.e. idiomatic)
> method. Whether this is a good thing or a bad thing is largely a matter
> of preference. If you want a minimal language, then it's awful. But if
> you want to be able to write an arbitrary piece of code quickly and
> concisely, then it's wonderful.
You aren't kidding. Everytime I have a text-processing task, my brain
goes into Perl-mode and I rip right through it. Now of course, afer
it's done, I can engage in the armchair philosophy that led to this
question.
> IMHO, orthogonality is overrated. It sounds nice on the surface, but you
> invariably end up with a situation where you have to write some ugly
> hack to get around the restrictions of the language.
Yeah, or you end up doing a whole lot more typing before the task gets
done.
--
Terrence Brannon
Carter's Compass...
I know I'm on the right track when by deleting code I'm adding
functionality.
Mark Slagell
> Michael Carman <mjca...@home.com> writes:
> > ...
> >
> > Heh. Careful, there! By whom is Ruby intended to be a replacement to
> > Perl? ;)
> >
> > Most of the responses have centered on your example, not the subject of
> > your question. Perl is non-orthogonal by design. From 'perldoc perl'
> >
> > "The language is intended to be practical (easy to use,
> > efficient, complete) rather than beautiful (tiny, elegant,
> > minimal)."
While "by whom" may be overstatement, "for whom" is not: "for me", for
one. I could never get comfortable with the Swiss Army Chainsaw way of
thinking, and was amazed and grateful when I ran across Ruby. It is
this very tension between beauty & practicality that Ruby renders moot,
a false dichotomy. Code tends toward compactness and readability at the
same time, expressiveness and simplicity at the same time. It seems
like the tradeoffs were well chosen. Speaking just for myself, I can't
think of a good reason to write Perl anymore except when having to
maintain old code, and even then, at least in a couple of cases where
I've had to do it, it has seemed simpler to translate it.
Yes it's unfair to expect Perl to be something it's expressly not
designed to be. But what Ruby gains in beauty doesn't seem to cost much
in terms of what we think of as Perl's strengths, so there is still
value in the comparison.
-- Mark
(sorry, I know this is the Thread that Won't Die, but I hadn't put my
$0.02 in yet.)
glauber
Mark Slagell <m...@iastate.edu> wrote:
[...]
> While "by whom" may be overstatement, "for whom" is not: "for me", for
> one. I could never get comfortable with the Swiss Army Chainsaw way of
> thinking, and was amazed and grateful when I ran across Ruby. It is
> this very tension between beauty & practicality that Ruby renders moot,
> a false dichotomy. Code tends toward compactness and readability at the
> same time, expressiveness and simplicity at the same time. It seems
Wait until you take a look at Scheme!
glauber (quickly ducking for cover)
--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Mark Slagell
> [...]
> > While "by whom" may be overstatement, "for whom" is not: "for me", for
> > one. I could never get comfortable with the Swiss Army Chainsaw way of
> > thinking, and was amazed and grateful when I ran across Ruby. It is
> > this very tension between beauty & practicality that Ruby renders moot,
> > a false dichotomy. Code tends toward compactness and readability at the
> > same time, expressiveness and simplicity at the same time. It seems
> [...]
>
> Wait until you take a look at Scheme!
>
> glauber (quickly ducking for cover)
(Umm... (been (there. (No (accounting for) (taste, eh.)))))
;-)
mi...@idocs.com
cbe...@cinenet.net (Craig Berry) wrote:
> Of course, an artist will be horribly constrained by the
> etch-a-sketch
I can't help mentioning that I once knew an artist whose medium of
choice actually was the Etch-a-Sketch. He created amazingly detailed
and vivid drawings, mostly of rock stars, then emptied the remaining
sand out, glued the knobs in place, and sold the sketches. I guess you
just never know what medium will turn someone on. If you had told the
13 year old writer/artist that was me that I would one day consider a
computer network as my artistic medium, I would have laughed, but it has
come to pass.
[We now return you to your regularly scheduled Perl discussion, already
in progress...]
-miko
--
Miko O'Sullivan
Author of The Mikodocs Guide to HTML
http://www.mikodocs.com/tags/