normalized hash-keys
What would be the way to define-or-set that a specific hash has non-case-sensitive keys? Or broader: that the keys should be normalized (think NFKC()) before usage? Would it be easy to delegate it to the hash? (or use a hardly noticeable wrapper) -- Affijn, Ruud Gewoon is een tijger.
Scans
We have a very nifty reduce metaoperator. Scans are a counterpart of reduce that are very useful -- they are the (preferably lazy) list of consecutive accumulated reductions up to the final result. But I can't think of a convenient way of expressing scans in Perl 6. I'm probably not thinking hard enough, so if anyone can come up with an implementation please give it :) Otherwise, how about we add this to the language? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Scans
Gaal Yahas skribis 2006-05-08 17:30 (+0300):
We have a very nifty reduce metaoperator. Scans are a counterpart of
reduce that are very useful -- they are the (preferably lazy) list of
consecutive accumulated reductions up to the final result. But I can't
think of a convenient way of expressing scans in Perl 6.
To make sure I understand what you mean, not as a proposed
implementation:
my @input = (...);
my @scan = map { [op] @input[0..$_] } [EMAIL PROTECTED];
Is this what you mean?
Hm, could that be written as:
my @scan = [op] @input[ 0 .. ([EMAIL PROTECTED]) ]
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Scans
On Mon, May 08, 2006 at 04:44:51PM +0200, Juerd wrote:
To make sure I understand what you mean, not as a proposed
implementation:
my @input = (...);
my @scan = map { [op] @input[0..$_] } [EMAIL PROTECTED];
Is this what you mean?
Hm, could that be written as:
my @scan = [op] @input[ 0 .. ([EMAIL PROTECTED]) ]
Yes, except that interim results need not be recalculated. (Indeed,
they are not in Haskell; implementing this feature on the .hs pugs
runcore should be straightforward.)
(Is there special sugar to make @input be the last index when used in a
range, or did you mean ..^ ?)
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Scans
Gaal Yahas skribis 2006-05-08 17:58 (+0300): (Is there special sugar to make @input be the last index when used in a range, or did you mean ..^ ?) I meant @input.last, or probably @input.indices (or .keys?) instead of the entire range, and @input.first instead of the first 0. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: normalized hash-keys
HaloO,
Dr.Ruud wrote:
What would be the way to define-or-set that a specific hash has
non-case-sensitive keys?
There are two things in this:
(1) The syntax to type the keys of a hash---too bad that I forgot it
and currently don't find it in the Synopsyses. Pointers welcome!
(2) A way to constrain a string to be case insensitive.
The latter could be nicely stated as
subset CaseInsensitive of Str where { .lc eq .uc }
but it actually is a constraint on the infix:eq, not on
the strings. So I doubt that it works as expected. But then
I'm not sure if one can make subsets of operators at all:
subset CaseInsensitive of eq where { .lc eq .uc }
I guess you have to simply define CaseInsensitive as an alias---that is
an unconstraint subset---and overload infix:eq. Then the hash
hopefully uses this operator when its key type is CaseInsensitive.
--
Re: normalized hash-keys
TSa writes:
Dr.Ruud wrote:
What would be the way to define-or-set that a specific hash has
non-case-sensitive keys?
(2) A way to constrain a string to be case insensitive.
subset CaseInsensitive of Str where { .lc eq .uc }
but it actually is a constraint on the infix:eq, not on
the strings. So I doubt that it works as expected.
That depends on ones expectations! At best I'd expect that to be a set
of digits, symbols, and all the other characters which don't have
distinct upper- and lower-case forms.
But then I'm not sure if one can make subsets of operators at all:
subset CaseInsensitive of eq where { .lc eq .uc }
I wouldn't've thought so.
I guess you have to simply define CaseInsensitive as an alias---that
is an unconstraint subset---and overload infix:eq. Then the hash
hopefully uses this operator when its key type is CaseInsensitive.
But why would a hash be doing equality operations at all? Assuming that
a hash is implemented efficiently, as a hash, then it needs to be able
to map directly from a given key to its corresponding value, not to have
to compare the given key in turn against each of the stored keys to see
if they happen to match under some special meaning of eq.
You snipped Ruud's next bit:
Or broader: that the keys should be normalized (think NFKC()) before
usage?
That seems the obvious way to implement this, that all keys are
normalized (say with Cuc, for this specific example) both on storage
and look-up. Then the main hashy bit doesn't have to change at all.
Many people have implemented such a thing using tied hashes in Perl 5.
So I guess you'd do the equivalent thing in Perl 6, whatever that is --
I've had a quick flick through the synposes and couldn't spot anywhere
that mentioned the obvious hooks for the Perl 5 CFETCH and CRESTORE
subs.
Smylers
Re: normalized hash-keys
TSa schreef: Dr.Ruud: What would be the way to define-or-set that a specific hash has non-case-sensitive keys? There are two things in this: (1) The syntax to type the keys of a hash---too bad that I forgot it and currently don't find it in the Synopsyses. Pointers welcome! (2) A way to constrain a string to be case insensitive. Yes, but also auto-normalization of incoming keys. Maybe like Hash::Case::Preserve (=tie). Yes, maybe by an exception (on the type). -- Groet, Ruud
Re: RFC: Community Education Page -- perl.perl6.meta
David K Storrs wrote: Hmmm...This doesn't seem to have particularly grabbed the popular imagination among the Perl6 crowd. Well, I think it's the Perl5 crowd that is in much more need of having its imagination grabbed. :-) [big snip] Anyway, I very much like your ideas. (And Juerd's suggestion too.) I also think this thread is the sort of thing that would be a suitable topic of discussion on perl.perl6.meta. And some of your content would be useful for the (very preliminary) Perl 6 User FAQ that was recently posted there. At present, I'm getting to perl.perl6.meta through nntp.perl.org, and it will hopefully appear in Google Groups in the not too distant future. Meanwhile, you can see the archives at (http://www.nntp.perl.org/group/perl.perl6.meta). I don't know if mail subscription is working for it. (This follows-up some #perl6 discussions in the preceding week about starting a general Perl 6 discussion NG. The idea is to first resurrect an old pre-existing group for this purpose, hence perl.perl6.meta. I'm about a week behind on reading the other *6* groups and #perl6, so I may have missed more recent discussions. I hope to be caught up by the end of the week.) Anyway, for the time being, I want to encourage you (and anyone else here) to cross-post (or move) discussions pertaining to *use* of Perl 6 (versus to internal stuff of ongoing language design and so on) to perl.perl6.meta. Likewise for other topics, such as marketing/evangelism, discussions of IDE support, brainstorming on how to get ponie funded, and so on. And if the Perl6 community doesn't think it's a good idea, then I won't bother. Have you asked on #perl6? Comments? Just do it. You already know it's a good idea. You're asking people that are already insanely busy and very intensely concentrated on what they are already doing, and who are extremely (development) results-oriented, so it's unlikely you'll get much encouragement under such circumstances. Also, if you consider the Perl 6 community to include everyone who has ever downloaded and run Pugs and plans to use Perl 6, you might only be reaching 1% of that group with this thread. You can mine most of the information you need from archives. If you supplement that with a judicious question or two, every other day or so, on a variety of appropriate forums, you'll have a first class site in a couple of months. Conrad Schneiker
Re: RFC: Community Education Page -- perl.perl6.meta
David K Storrs wrote: Hmmm...This doesn't seem to have particularly grabbed the popular imagination among the Perl6 crowd. Well, I think it's the Perl5 crowd that is in much more need of having its imagination grabbed. :-) [big snip] Anyway, I very much like your ideas. (And Juerd's suggestion too.) I also think this thread is the sort of thing that would be a suitable topic of discussion on perl.perl6.meta. And some of your content would be useful for the (very preliminary) Perl 6 User FAQ that was recently posted there. At present, I'm getting to perl.perl6.meta through nntp.perl.org, and it will hopefully appear in Google Groups in the not too distant future. Meanwhile, you can see the archives at (http://www.nntp.perl.org/group/perl.perl6.meta). I don't know if mail subscription is working for it. (This follows-up some #perl6 discussions in the preceding week about starting a general Perl 6 discussion NG. The idea is to first resurrect an old pre-existing group for this purpose, hence perl.perl6.meta. I'm about a week behind on reading the other *6* groups and #perl6, so I may have missed more recent discussions. I hope to be caught up by the end of the week.) Anyway, for the time being, I want to encourage you (and anyone else here) to cross-post (or move) discussions pertaining to *use* of Perl 6 (versus to internal stuff of ongoing language design and so on) to perl.perl6.meta. Likewise for other topics, such as marketing/evangelism, discussions of IDE support, brainstorming on how to get ponie funded, and so on. And if the Perl6 community doesn't think it's a good idea, then I won't bother. Have you asked on #perl6? Comments? Just do it. You already know it's a good idea. You're asking people that are already insanely busy and very intensely concentrated on what they are already doing, and who are extremely (development) results-oriented, so it's unlikely you'll get much encouragement under such circumstances. Also, if you consider the Perl 6 community to include everyone who has ever downloaded and run Pugs and plans to use Perl 6, you might only be reaching 1% of that group with this thread. You can mine most of the information you need from archives. If you supplement that with a judicious question or two, every other day or so, on a variety of appropriate forums, you'll have a first class site in a couple of months. Conrad Schneiker
Re: RFC: Community Education Page -- perl.perl6.meta
David K Storrs wrote: Hmmm...This doesn't seem to have particularly grabbed the popular imagination among the Perl6 crowd. Well, I think it's the Perl5 crowd that is in much more need of having its imagination grabbed. :-) [big snip] Anyway, I very much like your ideas. (And Juerd's suggestion too.) I also think this thread is the sort of thing that would be a suitable topic of discussion on perl.perl6.meta. And some of your content would be useful for the (very preliminary) Perl 6 User FAQ that was recently posted there. At present, I'm getting to perl.perl6.meta through nntp.perl.org, and it will hopefully appear in Google Groups in the not too distant future. Meanwhile, you can see the archives at (http://www.nntp.perl.org/group/perl.perl6.meta). I don't know if mail subscription is working for it. (This follows-up some #perl6 discussions in the preceding week about starting a general Perl 6 discussion NG. The idea is to first resurrect an old pre-existing group for this purpose, hence perl.perl6.meta. I'm about a week behind on reading the other *6* groups and #perl6, so I may have missed more recent discussions. I hope to be caught up by the end of the week.) Anyway, for the time being, I want to encourage you (and anyone else here) to cross-post (or move) discussions pertaining to *use* of Perl 6 (versus to internal stuff of ongoing language design and so on) to perl.perl6.meta. Likewise for other topics, such as marketing/evangelism, discussions of IDE support, brainstorming on how to get ponie funded, and so on. And if the Perl6 community doesn't think it's a good idea, then I won't bother. Have you asked on #perl6? Comments? Just do it. You already know it's a good idea. You're asking people that are already insanely busy and very intensely concentrated on what they are already doing, and who are extremely (development) results-oriented, so it's unlikely you'll get much encouragement under such circumstances. Also, if you consider the Perl 6 community to include everyone who has ever downloaded and run Pugs and plans to use Perl 6, you might only be reaching 1% of that group with this thread (since most of the extended Perl 6 community may have to concentrate on Perl 5 $work for the time being). You can mine most of the information you need from archives. If you supplement that with a judicious question or two, every other day or so, on a variety of appropriate forums, you'll have a first class site in a couple of months. Conrad Schneiker
Re: Scans
On Mon, May 08, 2006 at 05:30:23PM +0300, Gaal Yahas wrote: : We have a very nifty reduce metaoperator. Scans are a counterpart of : reduce that are very useful -- they are the (preferably lazy) list of : consecutive accumulated reductions up to the final result. But I can't : think of a convenient way of expressing scans in Perl 6. : : I'm probably not thinking hard enough, so if anyone can come up with an : implementation please give it :) Otherwise, how about we add this to : the language? Maybe that's just what reduce operators do in list context. Larry
[svn:perl6-synopsis] r9138 - doc/trunk/design/syn
Author: larry
Date: Mon May 8 16:50:55 2006
New Revision: 9138
Modified:
doc/trunk/design/syn/S12.pod
Log:
Supplied missing specs for tiebreaking semantics of longer names.
As a bonus, supplied conjectural syntax for return type tiebreaking.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podMon May 8 16:50:55 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 30 Apr 2006
+ Last Modified: 8 May 2006
Number: 12
- Version: 14
+ Version: 15
=head1 Overview
@@ -614,7 +614,10 @@
They are sorted into an order according to how close the actual types
of the arguments match up with the declared types of the parameters of
each candidate. The best candidate is called, unless there's a tie,
-in which case only candidates marked with the Cdefault trait are
+in which case the tied candidates are redispatched using any additional
+tiebreaker long names (see below).
+
+If a tie still results, only candidates marked with the Cdefault trait are
considered, and the best matching default routine is used. If there
are no default routines, or if the available defaults are also tied,
a final tie-breaking proto sub is called, if there is one (see above).
@@ -633,9 +636,38 @@
multi sub infix:..(Int $min, Int $max: Int $by = 1) {...}
+The final colon, if any, determines the complete long name of a multi.
+However, a given multi may advertise multiple long names, some
+of which are shorter than the complete long name. This is done by
+putting a colon after each advertised long name (replacing the comma,
+if present). The initial dispatch is always to the shortest advertised
+long name. Since the shorter long name does not guarantee uniqueness,
+if that shorter long name is chosen for dispatch, and a tie would be
+declared for that dispatch, the next longer set of long names may be
+used to break ties, for those candidates that supply longer names.
+(As a limiting case, marking every parameter as the end of a long
+name produces dispatch semantics like Common Lisp.)
+
Within a class, Cmulti submethod is visible to both method-dispatch
and subroutine-dispatch. A Cmulti method never participates in the
-subroutine-dispatch process.
+subroutine-dispatch process. It is dispatched just like a normal
+method, then the tie-breaking rules of the previous paragraph are applied.
+That is, the shortest long name of a multi method includes Ionly the
+single invocant, and any additional colons may only indicate long names
+to be used as tiebreakers.
+
+Conjecture: In order to specify dispatch that includes the return
+type context, it is necessary to place a colon after the return type:
+
+multi infix:..(Int $min, Int $max: Int $by = 1 -- Iterator:) {...}
+multi infix:..(Int $min, Int $max: Int $by = 1 -- Selector:) {...}
+
+Note that such a declaration might have to delay dispatch until the
+actual desired type is known! (Generally, you might just consider
+returning a flexible CRange object instead of an anonymous partial
+dispatch that may or may not be resolved at compile time via type
+inferencing. Therefore return-type tiebreaking need not be supported
+in 6.0.0 unless some enterprising soul decides to make it work.)
=head2 Method call vs. Subroutine call
[svn:perl6-synopsis] r9139 - doc/trunk/design/syn
Author: larry Date: Mon May 8 17:26:05 2006 New Revision: 9139 Modified: doc/trunk/design/syn/S02.pod Log: Clarification of the 0,1,Inf parsing policy. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon May 8 17:26:05 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 6 May 2006 + Last Modified: 8 May 2006 Number: 2 - Version: 38 + Version: 39 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1615,9 +1615,9 @@ visible at the point of the controlling Cproto declaration. Parsing of a bareword function as a provisional call is always done -the same way list operators are treated. If a postdeclaration bends -the syntax to be inconsistent with that, it is an error of the -inconsistent signature variety. +the same way list operators are treated. If a postdeclaration +bends the syntax to be inconsistent with that, it is an error of +the inconsistent signature variety. If the unrecognized subroutine name is followed by C postcircumfix:( ) , it is compiled as a provisional function call of the parenthesized form. @@ -1628,6 +1628,31 @@ arguments, whereas anything following whitespace will be interpreted as an argument list if possible. +Based on the signature of the subroutine declaration, there are only +four ways that an argument list can be parsed: + +Signature # of expected args +() 0 +($x) 1 +($x?) 0..1 +(anything else)0..Inf + +That is, a standard subroutine call may be parsed only as a 0-arg term +(or function call), a 1-mandatory-arg prefix operator (or function +call), a 1-optional-arg term or prefix operator (or function call), or +an infinite-arg list operator (or function call). A given signature +might only accept 2 arguments, but the only number distinctions the +parser is allowed to make is between void, singular and plural; +checking that number of arguments supplied matches some number +larger than one must be done as a separate semantic constraint, not +as a syntactic constraint. Perl functions never take N arguments +off of a list and leave the rest for someone else, except for small +values of N, where small is defined as not more than 1. You can get +fancier using macros, but macros Ialways require predeclaration. +Since the non-infinite-list forms are essentially behaving as macros, +those forms also require predeclaration. Only the infinite-list form +may be postdeclared (and hence used provisionally). + It is illegal for a provisional subroutine call to be followed by a colon postfix, since such a colon is allowed only on an indirect object, or a method call in dot form. (It is also allowed on a label when a
