Perl culture, perl readabillity
As a developer since a quarter century but only a few months in Perl I'm closely following the process of creating Perl6. I'm exited and also disappointed what's going on in this process. This morning I read an article which is completely unrelated to Perl but might give some insight why Perl is Perl. A study in Science (291 P.2165) found out that english speaking children has twice as much reading problems as italian speaking children of the same age. And about similar difference towards german and french. This could come from the fact that english has for 40 phonetics over 1100 kinds of writing while italian has for 25 phonetics only 33 kinds of writing (sorry I hope I've translated it into correct terms). Also 9 years old english children produce more reading error than 7 years old austrian children. This is exactly like I feel when I see a Perl script. Lots and lots of special symbols, special cases. And several where it's not easy to understand. This might come from the fact Perl was/is designed by english speaking people. It seems that the complexity of english writing is directly integrated into Perl. On the contrast Pascal was designed by a german speaking person (Wirth). I'm not saying Perl should become Pascal nor Pascal like, I only want to show the difference. While Pascal (at least standard Pascal) was so limited, it's still possible to read 20 years old programs. Well Larry once said "... lots of languages that come out of Europe have this thing of ..." (http://archive.develooper.com/perl6-language%40perl.org/msg05283.html). This also might be related to the language. I have come to Perl6 just about a month ago, so I can't give much advice what should be done. Also I'm not too accustomed to Perl to spot weaknesses. All I can do is give some general advice. - Make readability your main objective. Readability is possibly the weakest part of Perl. - Keep your eyes on modularity. Modularity is by far the best concept where complexity could be hidden. - Don't forget usability. This is after all the point why people use Perl in the first place. O. Wyss PS. Is there anywhere the current status of all the RFC's, (good, badly, ugly)? PPS: Please Cc, I'm not subscribed to the list.
Re: Perl culture, perl readabillity
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote: As a developer since a quarter century but only a few months in Perl I'm closely following the process of creating Perl6. This might come from the fact Perl was/is designed by english speaking people. It seems that the complexity of english writing is directly integrated into Perl. I don't know about the influence of English over other languages, but Larry specifically designed Perl to be more like natural language than most other programming languages. In case you haven't seen it yet: "Natural Language Principles in Perl" http://www.wall.org/~larry/natural.html -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
Re: Perl culture, perl readabillity
On Fri, 23 Mar 2001 23:34:41 +0100, Otto Wyss [EMAIL PROTECTED] wrote:
A study in Science (291 P.2165) found out that english speaking children
has twice as much reading problems as italian speaking children of the
same age. And about similar difference towards german and french. This
could come from the fact that english has for 40 phonetics over 1100
kinds of writing while italian has for 25 phonetics only 33 kinds of
writing (sorry I hope I've translated it into correct terms). Also 9
years old english children produce more reading error than 7 years old
austrian children.
It's also more *fun* to express your thoughts/feelings in English or Perl than
in speech impediments like french, italian or python
I *do* like things like
my $sth = $dbh-prepare ("insert into $table values (@{[('?')x@f]})";
;-)
BTW. I realy like Schwietserdeutch, also more fun than German.
--
H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.005.03, 5.6.0, 5.6.1, 5.7.1 623 on HP-UX 10.20 11.00, AIX 4.2
AIX 4.3, WinNT 4, Win2K pro WinCE 2.11 often with Tk800.022 /| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Schwartzian Transform
On Tue, Mar 20, 2001 at 11:15:51PM -0500, John Porter wrote:
So you think
@s =
map { $_-[0] }
sort { $a-[1] = $b-[1] }
map { [ $_, /num:(\d+)/ ] }
@t;
would be more clearly written as
@s = schwartzian(
{
second_map = sub { $_-[0] },
the_sort= sub { $a-[1] = $b-[1] },
first_map = sub { [ $_, /num:(\d+)/ ] },
},
@t );
Why can't Perl automagically do a Schwartzian when it sees a comparison with
complicated operators or functions on each side of it?
That is, @s = sort { f($a) = f($b) } @t would Do The Right Thing.
--
What happens if a big asteroid hits the Earth? Judging from realistic
simulations involving a sledge hammer and a common laboratory frog, we
can assume it will be pretty bad. - Dave Barry
Re: Schwartzian Transform
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC Why can't Perl automagically do a Schwartzian when it sees a
SC comparison with complicated operators or functions on each side of
SC it? That is, @s = sort { f($a) = f($b) } @t would Do The Right
SC Thing.
because that would require the PSI::ESP module which isn't working
yet. how would perl intuit exactly the relationship between the records
and the keys extraction and comparison? the ST defines that by the first
map and the comparison callback. just providing the comparison would
entail perl parsing an arbitrarily complex piece of code and then
autognerating the map that would produce an anon array that fits it. not
a simple task. if you instead defined a minilanguage that describes the
keys and how to extract them, you could generate the extraction and
comaprison code from that. that is the gist of the (currently shelved)
Sort::Records.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: Schwartzian Transform
At 10:50 AM 3/26/2001 -0500, Uri Guttman wrote:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC Why can't Perl automagically do a Schwartzian when it sees a
SC comparison with complicated operators or functions on each side of
SC it? That is, @s = sort { f($a) = f($b) } @t would Do The Right
SC Thing.
because that would require the PSI::ESP module which isn't working
yet. how would perl intuit exactly the relationship between the records
and the keys extraction and comparison?
I'm kinda puzzled by the focus on Schwartzian when I thought the GRT was
demonstrated to be better. Anyway, all we need is a syntax for specifying
an extraction function and whether the comparison is string or numeric. If
the parser can be persuaded to accept an array ref instead of a block, how
about
sort [ '=' = \f ] @t
doing The Right Thing? I guess you could also pragmatize it if you wanted
a particular transform:
use sort qw(schwartzian);
Someone could probably turn this into "use the schwartz".
Re: Schwartzian Transform
"PS" == Peter Scott [EMAIL PROTECTED] writes: PS I'm kinda puzzled by the focus on Schwartzian when I thought the PS GRT was demonstrated to be better. Anyway, all we need is a PS syntax for specifying an extraction function and whether the PS comparison is string or numeric. If the parser can be persuaded PS to accept an array ref instead of a block, how about PS sort [ '=' = \f ] @t how about multikey support? sort ordering (ascending, descending) which is also per key, etc. you could have a list of those pairs to deal with multikeys, but you need a sort order flag somewhere. but if that is all you have, you could do this with a simple module and it doesn't have to be in the perl language. just loop over the list of pairs (triplets?) and generate a map that calls each function which builds up the list of keys with the original record in [0]. then build up code that does a sequence of compares with $a-[$n], etc for each of the keys. then eval the whole mess and pray. :) and when using the GRT you need to know if the integers are signed/unsigned if you pack them with the 'N' long format. if you use sprintf, you need to know the maximum digit count of all the key values. this is one win of the ST over the GRT, you don't need to know as much about the key as perl will do the comparisons right with just cmp and =. you still need sort order and multikey support. otherwise you don't gain so much. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Distributive - and indirect slices (fwd)
This message pretty much sums up the distributive operator thing. Thought I'd forward it on. I guess any further discussion of this topic ought to be on perl6-language unless some has a better idea or doesn't think this is the right place for it. - D [EMAIL PROTECTED] -- Forwarded message -- Date: Mon, 26 Mar 2001 08:16:24 -0600 (CST) From: David M. Lloyd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Perl 5 Porters [EMAIL PROTECTED] Subject: Re: Distributive - and indirect slices On Mon, 26 Mar 2001 [EMAIL PROTECTED] wrote: My thinking was that not too many people use the current behaviour... maybe for Obfuscated Perl contests, but the operator could be so much more powerful than it is right now. Eh, don't forget it also provides scalar context to 'method' in: $obj - method - other_method; I don't think methods returning objects in scalar context and lists in list context are obfuscated. That's what's wantarray is about, isn't? That behaviour wouldn't change, since the leftmost expression is a scalar. Wait, that doesn't make sense. @a = $obj - method; calls method in list context because of the assignment. Now you are suggesting that it should call method in scalar context because of '$obj'? No, I'm suggesting that the behavior shouldn't change becuase of '$obj'. That is, if the leftmost expression is a scalar, the expression will take the context that it would currently have under our Perl 5 rules. However if the leftmost expression is a list, the whole expression should be in list context because all return items will be flattened into a list, and it just doesn't make sense to me to have these functions be called in scalar context. I mean, there'd be no way to specify what you want. Take these examples: $a = $obj-method; # Clearly scalar context. @a = $obj-method; # Clearly list context. $obj-method; # Clearly void context. $a = $obj-method1-method2; # Both methods in scalar context. @a = $obj-method1-method2; # method1 in scalar context, method2 in list context. $obj-method1-method2; # method1 in scalar context, method2 in void context. @a = ($obj1, $obj2)-method;# Clearly list context. Results of method # calls flattened into a list. $a = ($obj1, $obj2)-method;# Unclear. Calling in scalar context # gives no benefit, since you will # still have 2 return values. Maybe call # methods in list context anyways and # give the length of the return list? # Or else return rightmost value. ($obj1, $obj2)-method; # Same deal. Might as well call in list context. @a = ($obj1, $obj2)-method1-method2; # More complicated. Call method1 in list context on $obj1 and $obj2. # Call method2 in list context on each of method1's return values. # Results flattened into a list, assigned to @a. $a = ($obj1, $obj2)-method1-method2; # Unclear context, might as well be list. Call like above, return list # length or rightmost value, depending on which would be less useless. ($obj1, $obj2)-method1-method2; # Call like above, return value chucked. I hope this clarifies. NOTE: Maybe this discussion should continue on Perl6-language? - D [EMAIL PROTECTED]
Re: Distributive - and indirect slices (fwd)
On Mon, Mar 26, 2001 at 10:02:40AM -0600, David M. Lloyd wrote: $obj-method; # Clearly void context. Unless it's not. For example as the last statement in a subroutine. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Unicode handling
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 05:09 PM 3/23/2001 -0800, Damien Neil wrote: So the results of ord are dependent on a global setting for "current character set" or some such, not on the encoding of the string that is passed to it? Nope, ord is dependent on the string it gets, as those strings know what their encoding is. chr is the one dependent on the current default encoding. Are built-ins like chr going to be nailed to one encoding at compile time, or will we be able to toggle the default encoding setting at runtime? Besides having the ord opcode dispatched by the string tag, will it be possible to have the chr opcode dispatched by the type of return value wanted? $foo:ASCII = chr(65); @foo:ASCII = map chr($_), 80, 69, 82, 76; I assume internals-wise that this is similar to whether a function was called in a scalar, array, or void context... But further raises the spectar of multiple dispatch to include typing. Garrett
RE: Unicode handling
At 11:42 AM 3/26/2001 -0600, Garrett Goebel wrote: From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 05:09 PM 3/23/2001 -0800, Damien Neil wrote: So the results of ord are dependent on a global setting for "current character set" or some such, not on the encoding of the string that is passed to it? Nope, ord is dependent on the string it gets, as those strings know what their encoding is. chr is the one dependent on the current default encoding. Are built-ins like chr going to be nailed to one encoding at compile time, or will we be able to toggle the default encoding setting at runtime? I don't see any reason not to have the encoding lexically scoped and settable via use. Probably either "use encoding qw(EBCDIC);" or "use ebcdic;". The former would be easier to extend, but it's Larry's call. Besides having the ord opcode dispatched by the string tag, will it be possible to have the chr opcode dispatched by the type of return value wanted? $foo:ASCII = chr(65); @foo:ASCII = map chr($_), 80, 69, 82, 76; I assume internals-wise that this is similar to whether a function was called in a scalar, array, or void context... But further raises the spectar of multiple dispatch to include typing. That's an interesting question, and it depends on how the chr operator's defined. If it's done via the variable vtables it's sort of easy (sort of) in some ways, and if not it's sort of easy in others. There's no reason it can't be done, the question is whether it's useful enough to justify the speed penalty. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl culture, perl readabillity
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
- Make readability your main objective. Readability is possibly the
weakest part of Perl.
There's nothing fundamentally about Perl that makes it unreadable. Seriously.
Perl doesn't write unreadable Perl, people do. You can write some beautifully
readable programs in Perl. You can write some horrible programs in Perl too.
Try it. Take an algorithm and write it in as many ways as you can. Try and
make it as ugly or as beautiful as possible - the fact is, you *can* choose
how readable you want it to be.b
Oh, sure. So it has funny symbols. But it's a different language![1] It's just
like reading things written in Cyrillic. That's unreadable if you don't
know any Cyrillic. Well, duh. Once you know the alphabet, it's as clear as
day.
Or shorthand. Think about shorthand - that can look pretty unreadable. But
when you realise that it *is* shorthand and you shouldn't try and read it like
an ordinary text, it's fine. Regular expression syntax is shorthand.
/^.(\d{3})$/ might look daunting to someone who doesn't know the shorthand,
but it's perfectly readable to anyone who does. And to anyone who does,
writing it out longhand seems horrific:
$string-match-beginning-capture("digit", "digit", "digit")-end;
Much of Perl is the same, even though it *does* have considerably more
natural-languagey features than many other languages. Take phrase
construction, for instance. How many other languages let you say "X if Y" as
less as "if Y, X"?
In short, no. Readability isn't the weakest part of Perl; it's the weakest
part of Perl programmers. "You can write FORTRAN in any language". Because
Perl gives people a means to express their thoughts in a manner more compact
than their ordinary natural language, they do.
Oh, and you think Perl is more English than German? Here's someone who doesn't
think so:
``Perl is the successfull attempt to make a braindump directly executable.''
- Lutz Donnerhacke in de.org.ccc
[1] Why do people want programming languages to look like human languages
anyway? We use them for such completely different problem domains...
--
I'm a person, not a piece of property.
Happily, I'm both!
- Lionel and Stephen Harris.
Re: Perl culture, perl readabillity
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
- Make readability your main objective. Readability is possibly the
weakest part of Perl.
There's nothing fundamentally about Perl that makes it unreadable. Seriously.
Perl doesn't write unreadable Perl, people do. You can write some beautifully
readable programs in Perl. You can write some horrible programs in Perl too.
Try it. Take an algorithm and write it in as many ways as you can. Try and
make it as ugly or as beautiful as possible - the fact is, you *can* choose
how readable you want it to be.b
The side effect of flexible op behaviour and some ambiguity in syntax is
the ability to write how you want to write. The interesting part is that
well-written ("readable") Perl would be considered by a non-programmer to
be much more intelligible than, say, what a programmer would call
"readable" C, since they can actually deduct the function without
understanding the language. ("You mean I can write, 'print values %hash',
and it will work?") You *can* write programs in Perl which are
significantly more readable than their equivalents in other languages,
because of this behaviour.
When programmers say "readable", they usually mean to say "statically
consistent", preferring a language with no contextually-conditional
behaviour. The result is an inability to write code that *is*
unreadable, syntax that is not idiomatic, blah blah blah. The result isn't
Perl, or Perl 6.
As for the English influence, you're welcome to identify ways that the
syntax could be extended or tightened to be less so. That's the intent of
the mailing list. But please, no more Latin ... I like positional
dependency. :)
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
SC it? That is, @s = sort { f($a) = f($b) } @t
because that would require the PSI::ESP module which isn't working
yet. how would perl intuit exactly the relationship between the records
and the keys extraction and comparison? the ST defines that by the first
map and the comparison callback. just providing the comparison would
entail perl parsing an arbitrarily complex piece of code and then
autognerating the map that would produce an anon array that fits it. not
a simple task.
No, it wouldn't, don't be silly. The ST can always be generalized to
ST(data, func, compare) =
map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
In fact, you can implement it in LISP just like that:
(defun Schwartzian (list func compare)
(mapcar
(lambda (x) (car x))
(sort
(mapcar
(lambda (x) (cons x (funcall func x)))
list
)
(lambda (x y) (funcall compare (cdr x) (cdr y)))
)
)
)
Do you see any ESP there? Do you see any parsing of arbitrary pieces of
code? No, me neither.
--
SM is fun. ADSM is not.
"Safe, Sane, Consensual"... three words that cannot used to describe
ADSM.
- Graham Reed, sdm.
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 08:25:17AM -0800, Peter Scott wrote: I'm kinda puzzled by the focus on Schwartzian when I thought the GRT was demonstrated to be better. Because the insert name here transform is a specialized case of the schwartzian transform where the default sort is sufficient. Address the issues with the general case, and the specialized case is handled as well. Z.
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC Why can't Perl automagically do a Schwartzian when it sees a
SC comparison with complicated operators or functions on each side of
SC it? That is, @s = sort { f($a) = f($b) } @t would Do The Right
SC Thing.
because that would require the PSI::ESP module which isn't working
yet.
Not at all. Simon's example looks like a simple case of memoization.
The cache only needs to be maintained for the duration of the sort,
and it alleviates the need for complicated map{} operations.
how would perl intuit exactly the relationship between the records
and the keys extraction and comparison?
The key extraction is done with f(), and the comparison is done
with cached values of f().
Z.
Re: Schwartzian Transform
At 03:23 PM 3/26/2001 -0500, Adam Turoff wrote:
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC Why can't Perl automagically do a Schwartzian when it sees a
SC comparison with complicated operators or functions on each side of
SC it? That is, @s = sort { f($a) = f($b) } @t would Do The Right
SC Thing.
because that would require the PSI::ESP module which isn't working
yet.
Not at all. Simon's example looks like a simple case of memoization.
The cache only needs to be maintained for the duration of the sort,
and it alleviates the need for complicated map{} operations.
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5) though I for one
wouldn't mind being able to more aggressively assume that data was
semi-constant... (Imagine returning tied data from a function loaded in via
do(). Imagine the optimizer. Imagine Dan's brain popping out of his head
and hiding behind the bookcase)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Perl culture, perl readabillity
Please CC Otto in all replies concerning this topic. I want to make sure he
reads how wrong he is about Perl and its readability and I think Simon sums it
up perfectly here.
I also want to add that all of those strange looking symbols make Perl the
powerful language it is. I love the freedom Perl gives me to express my
algorithms in my own unique, and hopefully efficient, manner. TMTOWTDI baby!
Without that Perl motto I would be using Python right now (I am not slamming
Python btw) because its author wanted specifically to limit the multitude of
ways you can solve a problem through the syntax and that doesn't work for
everyone. Simon nailed down the whole thing by simply stating that programmers
make Perl unreadable (some of us take pride in it as well) not Perl itself. My
main concern with Perl6 is the exact opposite of Otto's, I do not want to see
all the TMTOWTDI elements disappear from Perl. I want all the symbols to
remain. I want the regex to stay as powerful as it is now and I want the
ability to write my Perl with the amount of readability that is necessary for
the task at hand. Simon also got an Amen from me when he asked why some people
want programming languages to look more like human languages anyway. I do not
want to write a novel, so to speak, every time I need a quick and powerful
program written in Perl. I want, after learning the language well (hint, hint),
the ability to write a few lines of crazy symbols using Perl and have it perform
the task expected and wow my boss with the speed in which I wrote a great and
accurate program.
I did not move to Perl because it had the simplest syntax (that wasn't what I
was looking for anyway) and I personally feel that shouldn't be your main
motivation in choosing a language to begin with. I moved to Perl because it
allowed me to create extremely powerful, portable, and flexible programs faster
than any other language I have currently ever used. Just learn it well, Otto,
and you'll soon appreciate and love Perl's rich syntax.
To all you great programmers working on Perl6, don't make it Pascal (and I know
you won't) make it the better TMTOWTDI Perl I know it can be. Thanks for
listening to my rant.
A Perl advocate and user for life,
Brandon
-Original Message-
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 26, 2001 10:03 AM
To: [EMAIL PROTECTED]
Subject: Re: Perl culture, perl readabillity
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
- Make readability your main objective. Readability is possibly the
weakest part of Perl.
There's nothing fundamentally about Perl that makes it unreadable. Seriously.
Perl doesn't write unreadable Perl, people do. You can write some beautifully
readable programs in Perl. You can write some horrible programs in Perl too.
Try it. Take an algorithm and write it in as many ways as you can. Try and
make it as ugly or as beautiful as possible - the fact is, you *can* choose
how readable you want it to be.b
Oh, sure. So it has funny symbols. But it's a different language![1] It's just
like reading things written in Cyrillic. That's unreadable if you don't
know any Cyrillic. Well, duh. Once you know the alphabet, it's as clear as
day.
Or shorthand. Think about shorthand - that can look pretty unreadable. But
when you realise that it *is* shorthand and you shouldn't try and read it like
an ordinary text, it's fine. Regular expression syntax is shorthand.
/^.(\d{3})$/ might look daunting to someone who doesn't know the shorthand,
but it's perfectly readable to anyone who does. And to anyone who does,
writing it out longhand seems horrific:
$string-match-beginning-capture("digit", "digit", "digit")-end;
Much of Perl is the same, even though it *does* have considerably more
natural-languagey features than many other languages. Take phrase
construction, for instance. How many other languages let you say "X if Y" as
less as "if Y, X"?
In short, no. Readability isn't the weakest part of Perl; it's the weakest
part of Perl programmers. "You can write FORTRAN in any language". Because
Perl gives people a means to express their thoughts in a manner more compact
than their ordinary natural language, they do.
Oh, and you think Perl is more English than German? Here's someone who doesn't
think so:
``Perl is the successfull attempt to make a braindump directly executable.''
- Lutz Donnerhacke in de.org.ccc
[1] Why do people want programming languages to look like human languages
anyway? We use them for such completely different problem domains...
--
I'm a person, not a piece of property.
Happily, I'm both!
- Lionel and Stephen Harris.
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5)
Hm. I don't see a linguistic reason why it isn't with perl5. Unless the
comparisign function as a whole is stable (IE {f(a) = f(b)}, the sort
function is documented as being undefined.
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
though I for one
wouldn't mind being able to more aggressively assume that data was
semi-constant...
Well, you can. Unless it has magic (and more specificly, scalar get magic).
(Imagine returning tied data from a function loaded in via
do(). Imagine the optimizer. Imagine Dan's brain popping out of his head
and hiding behind the bookcase)
That's a really wierd image. Twisted, even.
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Perl culture, perl readabillity
On Mon, Mar 26, 2001 at 01:11:06PM -0700, Dan Brian wrote:
As for the English influence, you're welcome to identify ways that the
syntax could be extended or tightened to be less so. That's the intent of
the mailing list. But please, no more Latin ... I like positional
dependency. :)
Hmm. I just relized what he's talking about. As an example, most nonsimple
statements (IE past-tense, ones with modal and action verbs, etc) end in the
verb. For example, an english-speaker would say:
I must walk the god. (Subject modal-verb action-verb direct-object.)
A german-speaker would say:
I must the god walk. (Subject modal-verb direct-object action-verb.)
(Yes, I am a dislexic, agnostic insomniac.)
This is exactly analgous to the perl form (english-perl):
sort { f(a) = f(b) } @list; (Action-verb subordanate-verb (adverbal form)
direct-object.) OTOH, for a german-speaker, sort @list {f(a) = f(b)}
would be more natural (Action-verb direct-object subordanate-verb
(infinitive form)). (Note, BTW, that gramaticly, perl statements always
have a implied subject of "Intepreter" [0]. (Also note that in english, the
adverbal form of a verb normaly ends with ly, in german it ends with en, and
in perl is surrounded by curly-braces.))
Hmm, in fact, perl statements are always in command form, which means that
in german, they are always non-simple sentances, and the verb is always at
the end.
OTOH, there are cases where perl is more readable for not
matching a natural language structure. For example, hit $ball
$outfield; is a normal structure: verb indir-obj dir-obj. OTOH,
$ball-hit ($outfield) is indir-obj verb dir-obj, which is just screwy from
an english point of view, but perfectly normal from a perl viewpoint.
Then again, if you think of objects (in the OO sense) as doing things, then
they normaly are the subject, and _not_ the indirect-object (in the english
sense).
(Note, BTW, that both my german and my lingustics aren't so hot.)
-=- James Mastros
--
The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science. He to whom this emotion is a stranger,
who can no longer pause to wonder and stand wrapt in awe, is as good as dead.
-=- Albert Einstein
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
Dan Sugalski wrote: The only issue there is whether memoization is appropriate. It could be argued that it isn't (it certainly isn't with perl 5) though I for one wouldn't mind being able to more aggressively assume that data was semi-constant... The :idempotent attribute for subs? -- John Porter Useless use of time in void context.
Re: Schwartzian Transform
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC No, it wouldn't, don't be silly. The ST can always be generalized to
SC ST(data, func, compare) =
SC map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
and i don't see multiple keys or sort order selection per key. and read
my other post about how that could be partly done but it belongs in a
module instead of a builtin.
SC Do you see any ESP there? Do you see any parsing of arbitrary
SC pieces of code? No, me neither.
and even creating a function to extract the key is not for beginners in
many case. most of the time i see issues with the ST is with key
extraction.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote: SC Do you see any ESP there? Do you see any parsing of arbitrary SC pieces of code? No, me neither. and even creating a function to extract the key is not for beginners in many case. most of the time i see issues with the ST is with key extraction. With all due respect, that's not been my experience. Even beginners know how to do things like "length", by far the most common case for the ST. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: Distributive - and indirect slices (fwd)
Paul Johnson wrote: David M. Lloyd wrote: $obj-method; # Clearly void context. Unless it's not. For example as the last statement in a subroutine. Right. Context means context! Just because there's no context- inducing code on this line, doesn't mean there isn't somewhere else. -- John Porter
Re: Distributive - and indirect slices (fwd)
David M. Lloyd wrote: $a = ($obj1, $obj2)-method;# Unclear. Calling in scalar context # gives no benefit, since you will # still have 2 return values. Maybe call # methods in list context anyways and # give the length of the return list? Never! This isn't an array. Only arrays return "length-of" like that. # Or else return rightmost value. Right. But hopefully all this will be mootified by Perl6's support for higher-order functions. -- John Porter
Re: Schwartzian Transform
"SC" == Simon Cozens [EMAIL PROTECTED] writes: SC On Mon, Mar 26, 2001 at 04:36:35PM -0500, Uri Guttman wrote: and even creating a function to extract the key is not for beginners in many case. most of the time i see issues with the ST is with key extraction. SC With all due respect, that's not been my experience. Even SC beginners know how to do things like "length", by far the most SC common case for the ST. well, you must be hanging around smart newbies. :) i can't count the number of times i have seen in c.l.p.misc the question "how can i find the length of a string?" we even have a running gag calling that and similar ones "self answering questions". still, a module which takes the same type of arguments and supports multiple keys would be a better choice than a new builtin IMO. the operator you propose is more complex than almost any other and it just serves to make one algorithmic trick have a better syntax. but a module can do the same thing. larry has the final say here and i feel he won't want to burden the language with this just for a small gain that can be done in a module. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 04:54:51PM -0500, Uri Guttman wrote: well, you must be hanging around smart newbies. :) No, I just learn 'em right. :) -- The Blit is a nice terminal, but it runs emacs.
Re: Schwartzian Transform
Simon Cozens wrote:
With all due respect, that's not been my experience. Even beginners know
how to do things like "length", by far the most common case for the ST.
You must be kidding. Sorting a list of strings by length is more
common that, say, sorting them numerically by some embedded number?
I don't think so.
Besides, simply sorting strings by length doesn't require ST.
The ST applies when you want to sort by one or more embedded "fields".
So, sorting by length of an embedded field is the most common case?
I can honestly say that I have never done this, seen it, recommended
it, or seen it recommended (though I admit it must come up from time
to time):
map { $_-[0] }
sort { $a-[1] = $b-[1] }
map { my($s) = /X(.*?)Y/; [ $_, length($s) ] }
@items
--
John Porter
Useless use of time in void context.
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 05:17:38PM -0500, John Porter wrote: Simon Cozens wrote: With all due respect, that's not been my experience. Even beginners know how to do things like "length", by far the most common case for the ST. You must be kidding. Sorting a list of strings by length is more common that, say, sorting them numerically by some embedded number? I don't think so. Besides, simply sorting strings by length doesn't require ST. The ST applies when you want to sort by one or more embedded "fields". Huh? ST (or GR) applies to any situation where you your sort comparator function isn't directly expressible with (Perl) primitives, and worthwhile it is (like Yoda feel I) when the cost of converting the keys (so that the primitives can again be employed) begins to dominate the overall cost of sort(). -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Schwartzian Transform
Jarkko Hietaniemi wrote:
ST (or GR) applies to any situation where you your sort
comparator function isn't directly expressible with (Perl) primitives,
and worthwhile it is (like Yoda feel I) when the cost of converting
the keys (so that the primitives can again be employed) begins to
dominate the overall cost of sort().
Of course. So how is the ST justified when you simply want to
sort by length? I.e., why is this not sufficient:
sort { length($a) = length($b) } # I see no ST here.
And this was alleged to be the most common case for ST.
--
John Porter
Useless use of time in void context.
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 05:29:24PM -0500, John Porter wrote:
Jarkko Hietaniemi wrote:
ST (or GR) applies to any situation where you your sort
comparator function isn't directly expressible with (Perl) primitives,
and worthwhile it is (like Yoda feel I) when the cost of converting
the keys (so that the primitives can again be employed) begins to
dominate the overall cost of sort().
Of course. So how is the ST justified when you simply want to
sort by length? I.e., why is this not sufficient:
Those of the School of Maniacal Optimization may prefer calling
length() only O(N) times, instead of O(N log N) times. Yeah, a weak
argument, but then again, I didn't claim length() as such being the
prime user of ST. I just jumped at your "fields" description, which
sounded odd to me. There need not be "fields" by any stretch of the
term. It's all about reduction to primitive-comparable and the
relative cost of it.
sort { length($a) = length($b) } # I see no ST here.
And this was alleged to be the most common case for ST.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Perl culture, perl readabillity
Hmm. I just relized what he's talking about. As an example, most nonsimple
statements (IE past-tense, ones with modal and action verbs, etc) end in the
verb. For example, an english-speaker would say:
I must walk the god. (Subject modal-verb action-verb direct-object.)
A german-speaker would say:
I must the god walk. (Subject modal-verb direct-object action-verb.)
(Yes, I am a dislexic, agnostic insomniac.)
"The god I must walk", "walk the god I must", etc. They aren't immediately
familiar, but they are grammatical.
This is exactly analgous to the perl form (english-perl):
sort { f(a) = f(b) } @list; (Action-verb subordanate-verb (adverbal form)
direct-object.) OTOH, for a german-speaker, sort @list {f(a) = f(b)}
would be more natural (Action-verb direct-object subordanate-verb
(infinitive form)). (Note, BTW, that gramaticly, perl statements always
have a implied subject of "Intepreter" [0]. (Also note that in english, the
adverbal form of a verb normaly ends with ly, in german it ends with en, and
in perl is surrounded by curly-braces.))
You're saying that it would be more natural for an English speaker to say,
"Sort numerically this list", as opposed to "sort this list numerically"?
I disagree; the latter is more natural for English speakers. I don't see
this as evidence of "English Perl". You could also analogize your sort
example as:
sort { f(a) = f(b) } @list
"Apply this sort to this list"
The same holds true for at least Spanish and French. I don't know German.
Consider 'print':
print FILEHANDLE data;
This isn't the most intuitive form for English speakers, who would tend to
say:
"Print this data to this filehandle."
Rather than:
"Print to this filehandle this data.
Then again, if you think of objects (in the OO sense) as doing things, then
they normaly are the subject, and _not_ the indirect-object (in the english
sense).
Well, then don't think of them that way. :) Perl objects of the class
variety are direct objects, indirect objects, subjects, and even verbs if
$_[0] is discarded in methods. It's true they are most commonly subjects,
but can be used as most anything. Isn't that great?
Re: Schwartzian Transform
Jarkko Hietaniemi wrote: It's all about reduction to primitive-comparable and the relative cost of it. You're right. Extraction of fields is only one example. (But it's illustrative, no?) -- John Porter Useless use of time in void context.
Re: Schwartzian Transform
At 04:33 PM 3/26/2001 -0500, John Porter wrote: Dan Sugalski wrote: The only issue there is whether memoization is appropriate. It could be argued that it isn't (it certainly isn't with perl 5) though I for one wouldn't mind being able to more aggressively assume that data was semi-constant... The :idempotent attribute for subs? Only trustable if there are no do, eval, or require calls past BEGIN time, and we don't see any redefining subroutines. If we disallow changing the attributes on subs at runtime, or explicitly allow the optimizer to optimize away access to active data, then things are different and we're fine. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schwartzian Transform
At 06:11 PM 3/26/2001 -0500, John Porter wrote:
Trond Michelsen wrote:
I realize that memoization isn't something you want to do on functions
that may return different results with the same input. However I'm a bit
curious of when these functions are useful in sort(),
...
sort {rand($a) = rand($b)} @nums;
Right.
Will the above generate a more random list than this?
No, it will generate a more crashed perl.
I thought we fixed that particular core dump.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Schwartzian Transform
At 04:04 PM 3/26/2001 -0500, James Mastros wrote:
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5)
Hm. I don't see a linguistic reason why it isn't with perl5. Unless the
comparisign function as a whole is stable (IE {f(a) = f(b)}, the sort
function is documented as being undefined.
The only way f(a) can not be stable and f(a) = f(b) can be is somthing of
a corner case. In fact, it's a lot of a corner case.
You're ignoring side-effects. The tied data may well be returned the same
every time it's accessed, but that doesn't mean that things aren't
happening behind the scenes. What if we were tracking the number of times a
scalar/hash/array was accessed? Memoizing would kill that.
Whether this is sufficient argument to not allow it is a separate issue,
but that's not my call. I'd really like it to form an optimizer standpoint,
but it does cut off the possibility for some potentially interesting things
from a programmer standpoint.
though I for one
wouldn't mind being able to more aggressively assume that data was
semi-constant...
Well, you can. Unless it has magic (and more specificly, scalar get magic).
Yeah, but figuring out whether data isn't magic is rather tricky. Once a
little uncertainty comes in (Say, from AUTOLOADed subs, or from subs whose
contents we don't know at compile time because of runtime requires, or
because we really do have magic data and the potential uncertainty from it
flares out quickly) it really cuts down on what the optimizer can do.
Granted, we may just say "don't do that if you want fast code" which is OK,
but I can see the data flow analysis getting really nasty really quickly
for reasonably sized programs.
(Imagine returning tied data from a function loaded in via
do(). Imagine the optimizer. Imagine Dan's brain popping out of his head
and hiding behind the bookcase)
That's a really wierd image. Twisted, even.
Just doing my part to make the world a little more surreal...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Perl culture, perl readabillity
"David Grove" [EMAIL PROTECTED] wrote: "Helton, Brandon" [EMAIL PROTECTED] wrote: Please CC Otto in all replies concerning this topic. I want to make sure he reads how wrong he is about Perl and its readability and I think Simon sums it up perfectly here. Give the braindead no head, Brandon. I've recently come across something HEED. Heed heed heed, not head. Of course, give them no head either... blush p
Re: Schwartzian Transform
Dan Sugalski wrote: John Porter wrote: No, it will generate a more crashed perl. I thought we fixed that particular core dump. Yes; but it's still bad. We just are more stable in the face of this badness. -- John Porter
Re: Perl culture, perl readabillity
The reward? English-speaking children learn what is arguably the most flexible and expressive spoken language in the world. Oh good hell. Yup. Remember, Larry Wall is a linguist by training--he learned in school about human languages. He applied this knowledge to Perl. I wish I had learned about human languages in school. That ape stuff got old real quick. On another note, perhaps we should set up something where longer names for some special variables are built in. How's $}PERLVERSION sound? Yeah, that's a good idea. Not. Perl is hard to compare with any other languages except those it borrowed heavily from or those that borrowed heavily from it. I don't think Perl has borrowed much from Pascal (besides maybe the " : " syntax for attributes) so Perl and Pascal are hard to compare. Uh .. So the basic question is, readability or usability? I say usability. I say ":ability".
Re: Schwartzian Transform
Dan Sugalski wrote: You're ignoring side-effects. The tied data may well be returned the same every time it's accessed, but that doesn't mean that things aren't happening behind the scenes. Like the :constant attribute on object methods in certain other languages. So, we could say, if :constant not on the sub, don't cache. As for :idempotent, I think sort() needs to assume the comparison sub is idempotent, rather than requiring such an attribute explicitly. -- John Porter Give the braindead no head.
Re: Schwartzian Transform
At 07:01 PM 3/26/2001 -0500, John Porter wrote: Dan Sugalski wrote: If we disallow changing the attributes on subs at runtime, Probably a good idea anyway, at least for a subset of attributes, such as :idempotent (or :constant). Oh, it's a fine idea, and I'm personally all for it. Anything that reduces the uncertainty the optimizer sees is fine with me. :) It is, however, Larry's call, though I can certainly rattle off the things I'd like to see as options. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Perl culture, readability, and general crankiness
Folks, this thread has gotten out of hand. Do please stop. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 05:44:43PM -0500, John Porter wrote: Jarkko Hietaniemi wrote: It's all about reduction to primitive-comparable and the relative cost of it. You're right. Extraction of fields is only one example. (But it's illustrative, no?) I like to use sorting filenames based on the file's size as an example. Nothing like throwing some disk accesses into it if slow is what you seek. -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
RE: Perl culture, perl readabillity
-Original Message- From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 15.43 To: Brent Dax Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Perl culture, perl readabillity The reward? English-speaking children learn what is arguably the most flexible and expressive spoken language in the world. Sorry, my bigotry meter just went through the roof, adding this thread to my kill list. Okay. If I offended anyone with that statement (as I appear to have done) I am sorry. I did _not_ mean to say other languages were bad. However, I believe that my statement that English may be the most flexible and expressive language stands--for the same reason that Perl is a flexible language, its redundancy. I never intended that to mean that there's something wrong with other languages, or even that English is 'better' in all ways. (Perl may be more flexible than C or other languages, but that doesn't make it 'better' than C--C is generally quicker to compile and execute.) However, I will not retract my statement, because I believe it and I believe that there are statistics to back it up. If you want to killfile me, fine, that's your choice. I just don't want you to do so because of a misunderstanding. --Brent Dax [EMAIL PROTECTED]
RE: Perl culture, perl readabillity
On Mon, 26 Mar 2001, David Grove wrote: -[chopped]- Python has its place, and I do support it and its growingly cocky users (not that they have much to be cocky about since they're the largest group of lamers this side of VB) and frankly it needs to stay there. Same thing for Java, REBOL, PHP (the nerve of that upstart perl module!) and ColdFusion. -[chopped]- Ruby is coming into its own now, but I won't throttle Ruby because I haven't heard them speak out of bounds yet... -[chopped]- (We also need someone to manage the Advocacy mailing list who will stomp these twerps rather than encourage them.) I'm sorry to drag this thread out any longer, but I thought this should be read: "Be An Advocate Not An Asshole" http://prometheus.frii.com/~gnat/yapc/2000-advocacy/slide1.html .g
Re: Schwartzian Transform
Tad McClellan wrote: Nothing like throwing some disk accesses into it if slow is what you seek. Yeah. Or web fetches! -- John Porter
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 07:31:29PM -0500, Dan Sugalski wrote: At 06:51 PM 3/26/2001 -0500, John Porter wrote: As for :idempotent, I think sort() needs to assume the comparison sub is idempotent, rather than requiring such an attribute explicitly. Assuming idempotency's fine, though I don't know that I'd go so far as to require it. I certainly wouldn't complain, though. I'd think /perl/ should complain if your comparison function isn't idempotent (if warnings on, of course). If nothing else, it's probably an indicator that you should be using that schwartz thang. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 06:31:22PM -0500, Dan Sugalski wrote: At 04:04 PM 3/26/2001 -0500, James Mastros wrote: The only way f(a) can not be stable and f(a) = f(b) can be is somthing of a corner case. In fact, it's a lot of a corner case. You're ignoring side-effects. Damm. I hate it when I miss the obvious. It's still a corner case, but not so ignorable of one. Well, you can. Unless it has magic (and more specificly, scalar get magic). Yeah, but figuring out whether data isn't magic is rather tricky. It shouldn't be, since we have to check for scalar get magic every time we get the value as a scalar anyway. Figuring out whether it is depenedent on some other thing which is magic, on the other hand, is really freeking nasty. Once a little uncertainty comes in (Say, from AUTOLOADed subs, or from subs whose contents we don't know at compile time because of runtime requires, or because we really do have magic data and the potential uncertainty from it flares out quickly) it really cuts down on what the optimizer can do. Youch. I tend to forget how "incestuous" perl is (as another message on a perl6 list said quite some time ago). I'm definatly with the guys who say we should have a :constant and a :idempotent attrib for subs, and make them unremovable. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Schwartzian Transform
Uri Guttman [EMAIL PROTECTED] writes:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC No, it wouldn't, don't be silly. The ST can always be generalized to
SC ST(data, func, compare) =
SC map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
and i don't see multiple keys or sort order selection per key.
Then you need to look at f and compare a little closer, since it's in
there.
and even creating a function to extract the key is not for beginners in
many case.
Without creating a function to extract the key, you can't sort in Perl at
all. sort { $a = $b } contains two functions to extract the keys.
Functions don't have to be complicated, you know.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Schwartzian Transform
Dan Sugalski [EMAIL PROTECTED] writes: You're ignoring side-effects. The tied data may well be returned the same every time it's accessed, but that doesn't mean that things aren't happening behind the scenes. What if we were tracking the number of times a scalar/hash/array was accessed? Memoizing would kill that. Hm. I don't really understand why this would be significant unless you're actually benchmarking Perl's sort. Unless you care about the performance of Perl's sort algorithm, the number of times each element is accessed in a sort is *already* indeterminate, being a function of the (hidden) sort implementation, and will vary a lot depending on how ordered the data already is. Counting on side effects determined by the *number* of times elements are accessed during a sort sounds pretty twisted to me. I can see a few YAPHs with such properties, but I don't think we were guaranteeing that Perl 6 would be YAPH-compatible anyway. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Schwartzian Transform
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Uri Guttman [EMAIL PROTECTED] writes:
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC No, it wouldn't, don't be silly. The ST can always be generalized to
SC ST(data, func, compare) =
SC map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
^^^ ^^^
and i don't see multiple keys or sort order selection per key.
RA Then you need to look at f and compare a little closer, since it's in
RA there.
and there is only extracted key being compared to another at the same
level, not multiple key levels. think about sorting by state and THEN
town. you can't do that with $a and $b and one f(). so you need multiple
compare ops and multiple f()'s. the point is that you have to generate
the ladder compare code as well as the calls to your f()'s.
RA Without creating a function to extract the key, you can't sort in
RA Perl at all. sort { $a = $b } contains two functions to extract
RA the keys.
huh? $a and $b are not functions but aliases the the current pair of
keys (at the primary key level). i don't seen any functions in what you
show there. you don't need a function or even an ST to sort complex
records. as other have stated here, the ST is useful to remove common
key extraction code from the compare callback.
RA Functions don't have to be complicated, you know.
but sorts can be very complex. i think we are having a 'key' meaning
overload. i am using it in form of 'state' being the first key and
'town' being the second when sorting street addresses. $a and $b are
both values from the same key, not the key itself. in the ST $a and $b
are refs to the generated anon arrays being compared. they are not the
keys values, which are in $a-[1], $a-[2], etc., with the original
record being in $a-[0].
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: Schwartzian Transform
Uri Guttman [EMAIL PROTECTED] writes:
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Uri Guttman [EMAIL PROTECTED] writes:
map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
^^^ ^^^
RA Then you need to look at f and compare a little closer, since it's in
RA there.
and there is only extracted key being compared to another at the same
level, not multiple key levels. think about sorting by state and THEN
town. you can't do that with $a and $b and one f().
Yes. You can.
Don't assume $a-[1] is a simple scalar. What prevents f() from returning
an array ref?
so you need multiple compare ops and multiple f()'s.
No, you don't.
the point is that you have to generate the ladder compare code as well
as the calls to your f()'s.
Yes, you have to write the comparison and data manipulation function for
Perl; Perl isn't going to be able to figure it out for itself. But that's
true regardless of the sorting method; you're always going to have to tell
Perl what the keys are and how to compare them.
You have to write slightly more code if you separate the extraction
function f() from the comparison function compare() since if the key
structure is complex, f() has to build a data struction that compare()
takes apart. That makes the memoizing approach superior.
RA Without creating a function to extract the key, you can't sort in
RA Perl at all. sort { $a = $b } contains two functions to extract
RA the keys.
huh? $a and $b are not functions but aliases the the current pair of
keys (at the primary key level).
Is sub { $a } a function? $a is equivalent to that. One way to look at
this is that Perl lets you simplify the function if all you need is the
basic data unit.
i don't seen any functions in what you show there. you don't need a
function or even an ST to sort complex records.
{ $a = $b } is a function. (Well, it's a code block, but the difference
is quibbling.)
My point is that writing functions isn't nearly as complicated as you make
it sound. Almost every time I write a sort, map, or grep in Perl, I write
a function.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Schwartzian Transform
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Uri Guttman [EMAIL PROTECTED] writes:
map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
^^^ ^^^
and there is only extracted key being compared to another at the same
level, not multiple key levels. think about sorting by state and THEN
town. you can't do that with $a and $b and one f().
RA Yes. You can.
RA Don't assume $a-[1] is a simple scalar. What prevents f() from
RA returning an array ref?
i never assumed that. but your ST example above shows it like that. you
still have to do a ladder compare with $a and $b do make the ST work
with multiple keys. each one needs to be given the sort order and
compare op as well.
so you need multiple compare ops and multiple f()'s.
RA No, you don't.
yes you do. unless you use the GRT. an ST can only compare 1 key at a
time without a ladder compare. that is its major weakness.
RA Yes, you have to write the comparison and data manipulation
RA function for Perl; Perl isn't going to be able to figure it out
RA for itself. But that's true regardless of the sorting method;
RA you're always going to have to tell Perl what the keys are and how
RA to compare them.
that is my whole point of why putting this into the language is
silly. it is too open ended for amount of work perl would have to do
vs. the amount of coding you save. you save very little as you are doing
most of the work youself in the f() key extraction subs.
RA You have to write slightly more code if you separate the extraction
RA function f() from the comparison function compare() since if the key
RA structure is complex, f() has to build a data struction that compare()
RA takes apart. That makes the memoizing approach superior.
and how is this ladder compare built? f() can't return it. it has to be
real perl code in the callback block, not lists of things.
RA Without creating a function to extract the key, you can't sort in
RA Perl at all. sort { $a = $b } contains two functions to extract
RA the keys.
huh? $a and $b are not functions but aliases the the current pair of
keys (at the primary key level).
RA Is sub { $a } a function? $a is equivalent to that. One way to look at
RA this is that Perl lets you simplify the function if all you need is the
RA basic data unit.
that still doesn't answer the issue of the ladder compare and who
creates it.
i don't seen any functions in what you show there. you don't need a
function or even an ST to sort complex records.
RA My point is that writing functions isn't nearly as complicated as
RA you make it sound. Almost every time I write a sort, map, or grep
RA in Perl, I write a function.
but you don't autogenerate the code in the block. it is your code. the
supposed goal of this hypothetical builtin ST is to make it easier to
use it. i say it is not worth the effort since you have to do almost as
much work anyway. the key extraction (and possibly the ladder compare)
is still provided by you.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: Schwartzian Transform
map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
Uri Guttman [EMAIL PROTECTED] writes:
i never assumed that. but your ST example above shows it like that. you
still have to do a ladder compare with $a and $b do make the ST work
with multiple keys. each one needs to be given the sort order and
compare op as well.
That's what compare() does. compare() is a Perl function. It can do
anything you want.
that is my whole point of why putting this into the language is
silly. it is too open ended for amount of work perl would have to do
vs. the amount of coding you save. you save very little as you are doing
most of the work youself in the f() key extraction subs.
The purpose served is that it's conceptually simpler to tell Perl "here's
how to extract keys and here's how to compare them; now sort this data
structure" than it is to tell Perl "convert this data structure into a
different one and then extract keys from it like follows and compare them,
then transform the structure back." The first route is closer to the way
that people are intuitively thinking. It doesn't matter to me that the
first isn't going to be that many fewer characters of Perl code than the
second. I *understand* it better.
It is true that it can be done in a module. Most things in Perl can. It
matters very little to me whether it's a standard module or built into the
language; I just think that it should be possible to tell sort to make
this sort of thing easier.
RA You have to write slightly more code if you separate the
RA extraction function f() from the comparison function compare()
RA since if the key structure is complex, f() has to build a data
RA struction that compare() takes apart. That makes the memoizing
RA approach superior.
and how is this ladder compare built?
The programmer writes it.
but you don't autogenerate the code in the block.
I haven't heard anyone talking about autogenerating everything other than
the code that wraps each element of the list in an anonymous array holding
the element and the key(s) and then extracts the key(s) for the comparison
function. That part of the code is identical in every ST that I write.
it is your code. the supposed goal of this hypothetical builtin ST is to
make it easier to use it. i say it is not worth the effort since you
have to do almost as much work anyway.
Less mental effort is the important part, not how many characters have to
be typed. I don't want to be thinking about that extra level of arrays,
and until you've written *lots* of ST's, you can't ignore it.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 03:36:08PM -0500, Dan Sugalski wrote:
because that would require the PSI::ESP module which isn't working
yet.
Not at all. Simon's example looks like a simple case of memoization.
The cache only needs to be maintained for the duration of the sort,
and it alleviates the need for complicated map{} operations.
The only issue there is whether memoization is appropriate. It could be
argued that it isn't (it certainly isn't with perl 5) though I for one
I realize that memoization isn't something you want to do on functions
that may return different results with the same input. However I'm a bit
curious of when these functions are useful in sort(), and in particular
when you _really_ need every comparison to be unmemoized.
sort {rand($a) = rand($b)} @nums;
Is it really desirable to get different results from rand() on every
single comparison?
Will the above generate a more random list than this?
map { $_-[0] }
sort { $a-[1] = $b-[1] }
map { [$_, rand($_)] }
@nums;
--
Trond Michelsen
Re: Schwartzian Transform
Trond Michelsen wrote:
I realize that memoization isn't something you want to do on functions
that may return different results with the same input. However I'm a bit
curious of when these functions are useful in sort(),
...
sort {rand($a) = rand($b)} @nums;
Right.
Will the above generate a more random list than this?
No, it will generate a more crashed perl.
--
John Porter
