Re: handling undef better
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> sorting in p6 is not at all like in p5. instead of coding up an explicit Uri> comparison code block and duplicating all the key access code (for $a Uri> and $b), you will specify how to extract/generate each key for a given Uri> record. this new syntax was posted by damian (who else) and it is very Uri> similar to the api in my p5 module sort::maker (we did discuss this Uri> api). i don't know if any A/E/S doc covers it but it is definitely in Uri> the archives. I hope the old (perl5) way is still available as well. There are times when parts of the comparison should be done lazily. Consider two objects that have a value for a primary sorting order, but only for those which the value is the same, we fall back to a secondary sort key that is expensive to compute (like maybe calling a database). For these scenarios, specifying the sort comparison will be simpler and cheaper than specifying the sort key. So, we need both, but if we get only one, the Perl5 way is superior. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: handling undef better
> "RLS" == Randal L Schwartz writes: > "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> sorting in p6 is not at all like in p5. instead of coding up an explicit Uri> comparison code block and duplicating all the key access code (for $a Uri> and $b), you will specify how to extract/generate each key for a given Uri> record. this new syntax was posted by damian (who else) and it is very Uri> similar to the api in my p5 module sort::maker (we did discuss this Uri> api). i don't know if any A/E/S doc covers it but it is definitely in Uri> the archives. RLS> I hope the old (perl5) way is still available as well. There are times RLS> when parts of the comparison should be done lazily. Consider two RLS> objects that have a value for a primary sorting order, but only RLS> for those which the value is the same, we fall back to a secondary RLS> sort key that is expensive to compute (like maybe calling a database). RLS> For these scenarios, specifying the sort comparison will be simpler RLS> and cheaper than specifying the sort key. RLS> So, we need both, but if we get only one, the Perl5 way is superior. i will let damian handle this one (if he sees it). but an idea would be to allow some form ofkey extraction via a closure with lazy evaluation of the secondary (and slower) key. and if you need that feature then you can't use the standard ST or GRT which preextract the keys. you could mung the ST to do this with lazy eval support but not the GRT since it packs the keys and there is no place to put in code for lazy keys. note that the API damian proposed did not specify an implementation so this could be supported internally at some point. and supporting the old simple p5 sort shouldn't be a problem and is probably a good idea anyhow. but the $a and $b will have to become $^a and $^b and be proper params of a closure. i dunno if that will cause a speed hit as $a/$b we designed to bypass the normal slow arg passing in p5. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> i will let damian handle this one (if he sees it). but an idea would be Uri> to allow some form ofkey extraction via a closure with lazy evaluation Uri> of the secondary (and slower) key. I still don't see that. I understand about the lazy key evaluation. However, the sort block in Perl5 contains more than just two key computations: it also contains the logic to decide *how* to compare the keys, and *when* more information is needed (a secondary key step, for example). Not sure how you're going to replace that with just information about how to compute "a key". I think you've had your head inside GRT for too long. :) So, for the simple case (string sort against some function of each item), I can see the need for a good shortcut. However, the general case (let me tell you how to sort two items), you'll still need a very perl5-ish interface. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: handling undef better
> "RLS" == Randal L Schwartz writes: > "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: Uri> i will let damian handle this one (if he sees it). but an idea would be Uri> to allow some form ofkey extraction via a closure with lazy evaluation Uri> of the secondary (and slower) key. RLS> I still don't see that. I understand about the lazy key RLS> evaluation. However, the sort block in Perl5 contains more than RLS> just two key computations: it also contains the logic to decide RLS> *how* to compare the keys, and *when* more information is needed RLS> (a secondary key step, for example). Not sure how you're going RLS> to replace that with just information about how to compute "a RLS> key". I think you've had your head inside GRT for too long. :) because the key description also specifies the comparison style. and it would even be possible to pass in a closure (with $^a and $^b) to do the actual comparison which gets you the p5 sort style that way. the determination if you need more info would normally be when the previous key sorts the same and that can be handled. the only odd case is when you have a very bizarre set of comparison rules where simple == and cmp don't work for this data. then the custom compare closure can also be used. RLS> So, for the simple case (string sort against some function of each item), RLS> I can see the need for a good shortcut. However, the general case (let RLS> me tell you how to sort two items), you'll still need a very perl5-ish RLS> interface. i don't see why you need that except for the odd cases. but as i said supporting custom compares is fine and can be done in a p6 way with a comparison closure. but even for simple sorting of two items, i would prefer to use a key extraction as that means you don't have redundant code and you describe the comparison as numeric or string which i think it better than cmp or ==. and at least in sort::maker you don't need to do more than say number or string which is simple enough. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef better
On Wed, Dec 21, 2005 at 10:25:09AM -0800, Randal L. Schwartz wrote: > > "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes: > > Uri> i will let damian handle this one (if he sees it). but an idea would be > Uri> to allow some form ofkey extraction via a closure with lazy evaluation > Uri> of the secondary (and slower) key. > > I still don't see that. I understand about the lazy key evaluation. > However, the sort block in Perl5 contains more than just two key > computations: it also contains the logic to decide *how* to compare > the keys, and *when* more information is needed (a secondary key step, > for example). Not sure how you're going to replace that with just > information about how to compute "a key". I think you've had your head > inside GRT for too long. :) > > So, for the simple case (string sort against some function of each item), > I can see the need for a good shortcut. However, the general case (let > me tell you how to sort two items), you'll still need a very perl5-ish > interface. If I understand the p6 way correctly (which is not necessarily true :-) it provides the key computation function in addition to the comparison function. So, the key computation can return a list of keys for each value (possibly in lazy not-yet-evaluated for so that the computation is only incurred the first time that that key component is actually used). The comparison function is often simpler than a p5 comparison function (because of the existance of the key function and because of the smarter match capabilities) but could still be as complicated a a p5 sort comparison function for those rare cases that really need it. --
Problem with dwimmery
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
However, what do we do about:
while $x-- && some_condition($x) {}
Here, while is being passed a hash, not a do-nothing code. Should we
force people to write:
while $x-- && some_condition($x) {;}
Or should we make a counter-special case of some sort? Or should we
take out the {} special case altogether and force people to write
hash()?
Luke
