Re: Schwartzian Transform
Simon Cozens [EMAIL PROTECTED] writes:
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)))
)
)
)
So can you write that in perl5 rather than LISP?
If not what does perl6 need so we can write it in perl6.
sub Schwartzian
{
...
}
Do you see any ESP there? Do you see any parsing of arbitrary pieces of
code? No, me neither.
--
Nick Ing-Simmons [EMAIL PROTECTED]
Via, but not speaking for: Texas Instruments Ltd.
Re: Schwartzian Transform
At 07:37 PM 3/26/2001 -0800, Russ Allbery wrote: 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. The counting thing was just an example. The point was that someone could do something with the function calls or FETCHes on tied data. We don't currently have any places where we explicitly won't call a function or FETCH on access. (Or a STORE for that matter, since there are a bunch of places where stores to variables could be otherwise optimized away) It's not that I don't mind saying "sort will memoize and may fetch your data only once", it's just that we have no current precedent. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schwartzian Transform
Dan Sugalski wrote: At 09:50 PM 3/26/2001 -0500, James Mastros wrote: [..] 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. If you figure out how, tell me. I'd like to make arrangements to be there for your Nobel acceptance speech. :) (This is, alas, a variant on the halting problem, unless you're proposing perl do the memoizing *and* still call the functions, and complain if one doesn't match the other) not wanting to collect my nobel prize just yet, but... could you not try a simple test (not guaranteed to be 100% accurate though), by copying the first data element and apply it twice and then check to see that the result of applying it once is the same as applying it twice. Ideally you could do they typical matrix type thing (getting technical again :) I x A = I x A x A A = A^2 So it would be easy if we could have an identity data element on hand, but even if we don't it is pretty unlikely that the data element will special enough to make the above true (substitute the data element for I). just some early morning dribble, peter
Re: Schwartzian Transform
At 09:26 AM 3/27/2001 -0800, Peter Buckingham wrote: Dan Sugalski wrote: At 09:50 PM 3/26/2001 -0500, James Mastros wrote: [..] 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. If you figure out how, tell me. I'd like to make arrangements to be there for your Nobel acceptance speech. :) (This is, alas, a variant on the halting problem, unless you're proposing perl do the memoizing *and* still call the functions, and complain if one doesn't match the other) not wanting to collect my nobel prize just yet, but... could you not try a simple test (not guaranteed to be 100% accurate though), by copying the first data element and apply it twice and then check to see that the result of applying it once is the same as applying it twice. Feels a little too magic to me, and awfully fragile. I'm not comfortable doing that, though arguments to the contrary are welcome. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Schwartzian Transform
could you not try a simple test (not guaranteed to be 100% accurate though), by copying the first data element and apply it twice and then check to see that the result of applying it once is the same as applying it twice. Feels a little too magic to me, and awfully fragile. I'm not comfortable doing that, though arguments to the contrary are welcome. I agree that it isn't great, but I don't agree that it's really fragile (although that may be difficult to prove conclusively). Take an earlier example: (rand($x) = rand($y)) I suspect that the chances of rand($x) == rand(rand($x)) would be less than 1%. I would think that if it is different that you just raise a warning anyway rather than doing anything special. There may actually be a case where someone wants to have the side-effects (not that i can think of a reason immediately off hand). To be even handed an obvious counter-example is if the first data element is say 1: squared(1) == squared(squared(1)) but clearly this is not an idempotent function. but the obvious question is if it isn't an idempotent function what do we do? do we abort? perhaps the real question is not whether we can require idempotency but what are we trying to achieve with it --- there may be another way :) peter
Re: Schwartzian Transform
Peter Buckingham wrote: but the obvious question is if it isn't an idempotent function what do we do? do we abort? perhaps the real question is not whether we can require idempotency but what are we trying to achieve with it --- there may be another way :) It is easy enough to test if the function ever fails idempotency. And it is also easy to decide we'll chuck a warning when it does. The REAL issue is whether we really want to test for idempotency. Sure, it's easy, but it is not cheap. Do we want to pay the cost? It requires caching the values from every call, but STILL calling the function every time. You know, if we're going to cache the result, we may as well use it, i.e. memoize. Unless, of course, the optimizer can't assume the function has no side-effects. -- John Porter Give the braindead no head.
Re: Schwartzian Transform
John Porter wrote: And I don't like the name ":constant", it smacks too much of OO. I'd hope we would come up with a better name. :function ? :pure ? -- John Porter
Re: Schwartzian Transform
James Mastros wrote:
[..]
f("+123,456")=123456
f(f("+123,456))=123456
The functon is not idempotent. Even if you checked f(x)==x (function is the
identity), an input of "123456" would work.
just a comment on this, we are talking about sorting which would generally
mean that the function would have to output a number, which would make the
behaviour of the functions much more maths-like. the above function would
probably not be used in a sort routine i think :)
I agree with john's later message that the real issue is the optimiser which
means that having to run the function is not really an option. so this thread
is kind of irrelevant :) (sorry)
peter
Re: Schwartzian Transform
please ignore my previous message. i think that my mind was trapped in an
alternate dimension :)
peter
Peter Buckingham wrote:
James Mastros wrote:
[..]
f("+123,456")=123456
f(f("+123,456))=123456
The functon is not idempotent. Even if you checked f(x)==x (function is the
identity), an input of "123456" would work.
just a comment on this, we are talking about sorting which would generally
mean that the function would have to output a number, which would make the
behaviour of the functions much more maths-like. the above function would
probably not be used in a sort routine i think :)
I agree with john's later message that the real issue is the optimiser which
means that having to run the function is not really an option. so this thread
is kind of irrelevant :) (sorry)
peter
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. Thank you very much for the CC and including Simon's message at the end. 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! Could you imaging being the leader of a 10 people project where everybody design and codes in their own unique manner? [...] 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. I'm choosing a new language only if is suitable for most of my tasks and these range from the 10 line script up to several million line project. Currently Perl is rather capable for any small scripting task but it's out of questions if there are more than 2 person involved or the line count goes above several hundreds (maybe thousands). And this is only because to much time is lost in understanding what all the other code is doing. 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. I don't want to make Perl into Pascal, I mentioned it only to drastically show the difference in readability. [...] 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 In other words it's the english speaking children's own fault if they have more reading problems than others? Of course there are beautiful poems written in english as well. And I'm definitely not going to say most written english is horrible. No it's not horrible it's only not easy readable. I this respect perl and english are rather equal. 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. It's is not proven but I suspect even russian speaking children have much less problems than english. I wouldn't be surprised if this holds for Japanese as well. [..] 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 I've never said German (or Italian) is the better language than English. I only said English is not as easy readable. And even if there isn't any study it's obvious that Perl is not as easy readable as Pascal. As the facts stands Perl5 is not well suited for medium to large programming tasks. But as much as I understand Larry Wall Perl6 might get into the position of a capable candidate. If it will be, only history will tell us. IMHO Perl lacks readability and IMHO not enough is done during the RFC process. If you really like Perl don't questions this personal opinion, better look for solution in enhancing readability without compromising usability so I might change my mind later on. It's not easy to find the hot spots neither easy to fix them. How about going through the perl mailing lists and look for all the silly novice questions? IMHO Perl lacks modularity or better said a construct similar to a standard library. Besides the missing standard library in Pascal was the reason why Pascal didn't succeed. So it might be necessary to have a separate RFC process on which modules where included an with which interface. Maybe there isn't just one library. IMHO Perl does not lack usability but usability is so important, it always has to be kept in mind. O. Wyss PS. Please don't forget to CC.
Re: Perl culture, perl readabillity
On Tue, Mar 27, 2001 at 11:33:18PM +0200, Otto Wyss wrote: Could you imaging being the leader of a 10 people project where everybody design and codes in their own unique manner? No, which is why in *those* situations, you have house rules. I don't think Perl stops you doing that. It just doesn't enforce them; project managers do that. :) 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 In other words it's the english speaking children's own fault if they have more reading problems than others? I'm not sure how that follows from what I said. All languages have the potential to be used to compose both beautiful and ugly utterances. It's is not proven but I suspect even russian speaking children have much less problems than english. I wouldn't be surprised if this holds for Japanese as well. Yes, true. But until people speak any computer programming languages as a first language, this is completely irrelevant to the discussion in hand. 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 I've never said German (or Italian) is the better language than English. I never said you said that. IMHO Perl lacks readability OK, before this *completely* heads into the direction of advocacy, which it's dangerous close to anyway, you need to qualify that. Are you saying that the Perl code that *I* write lacks readability? I don't think so; I think I write readable code. Do you see the problem? PEOPLE use the language in different ways. Some use it well, some don't. You're saying that a language "lacks readability", but firstly, you're not actually qualifying that in any way. You're not giving any examples of what you mean, and this means we can't make it better. Secondly, "Perl" isn't unreadable. I don't think it even makes sense to say that a language is unreadable. A language generally consists of a grammar, (which is generally not written down) an alphabet, (individual symbols of which might be pretty aesthetically unpleasing, but that's by the by) and some semantic content which isn't written down either. There's nothing "unreadable" about English and there's nothing unreadable about Perl. There's certainly things unreadable (to me at least, because I'm not used to it) about John Milton, and there's certainly things unreadable about Abigail's JAPHs. (to you at least, because you're not used to it.) But Milton isn't the English language any more than a JAPH is the Perl language. Anyway, I'm setting follow-ups to perl-advocacy to try and get this out of here. If you have any positive, practical, real suggestions as to what you think is unreadable *and* how to improve it, feel free to send it back to perl6-language. At present, though, this doesn't belong here. -- About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra
Re: Perl culture, perl readabillity
I think Simon meant '[EMAIL PROTECTED]', but isn't interested enough to correct himself. :)
Re: Schwartzian Transform
Simon Cozens wrote:
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.
All this talk of making the ST accessible to beginners is misguided.
It's not a core capability, it's an
optimization, and one with alternatives. If a beginner lacks the
sophistication to understand map sort
map, then their programs probably don't need anything better than sort {
$a-{'key1'}{'key2'} =
$b-{'key1'}{'key2'} }, or perhaps the orcish manuever if they are
feeling frisky. Sure, you got the
extra dereferences, but for most of programs the novice will write, it's
just one of many suboptimal
constructs they will use.
Re: Perl culture, perl readabillity
OK, before this *completely* heads into the direction of advocacy, which it's dangerous close to anyway, you need to qualify that. Uh, have you followed this thread? It's nothing but another perlbashing session by a verbosity monger who can't handle $.
Re: Perl culture, perl readabillity
Uh, have you followed this thread? It's nothing but another perlbashing session by a verbosity monger who can't handle $. Well, you can bash him back in perl6, or continue the conversation on advocacy. Up to you. Excuse me, but why would you send a perlbasher to the perl advocacy list. I mean, I know Nat tolerates it, but it's completely inappropriate. Just send him back to comp.lang.python OK, Otto, go back to comp.lang.python. Or, discuss your concerns about Perl on [EMAIL PROTECTED], where a few folks might just help you understand the method behind the madness.
