"normalized" hash-keys

[Dr.Ruud]

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."

Perl 6 User FAQ (perl.perl6.meta) -- Version: 2006-05-08 (early beta level at present)

[Conrad Schneiker]

 Perl 6 User FAQ (perl.perl6.meta) 

 Version: 2006-05-08 (early beta level at present)

TABLE OF CONTENTS

* About perl.perl6.meta (and this FAQ)
* About Perl 6  # True marketing hype, in both senses.
* General Perl 6 status # On the move!
* Perl 6 info and docs  # A little sparse, but rapidly improving.
* Latest Perl 6 developments
* Where to get Perl 6   # <- "I want it now!!" <-
* Useful Perl 6 modules
* Incremental migration from Perl 5
* Other useful resources
* Glossary
* Copyright and license

=== About perl.perl6.meta (and this FAQ) ===

A major aim of this newsgroup (NG) is to lower the bar a bit for 
early-adapters, and to make it easier for people to effectively 
experiment with Perl 6 without having to search around as much to get 
started, and to help identify and fill in intermediate documentation 
gaps in the process. In other words, share the -Ofun.


Suggested additional content and corrections for this FAQ are always
welcome. Please post them to perl.perl6.meta with the subject line 
"FAQ feedback".


Think of this NG as the prototype for the future comp.lang.perl6.misc
NG. When traffic warrants it, we’ll apply for official Usenet "big 8" 
comp.* status.


You can access this NG several ways:

* Point your newsreader to (nntp.perl.org).
(Need a newsreader? (http://www.mozilla.com/thunderbird/) works for me.)
*Some time soon, you should also be able to find us on Google Groups.
*Subject lines of NG posts with link to each post can be found at this 
archive: (http://www.nntp.perl.org/group/perl.perl6.meta).

* Here's the RSS feed:
(http://www.nntp.perl.org/rss/perl.perl6.meta.rdf).

>


=== About Perl 6 ===

Newbie warning! Perl 6 is still UNDER CONSTRUCTION. Don’t make
important plans that depend on it just yet. Please see sections below
about intermediate Perl6-related solutions you can use now.

What is Perl 6? Perl 6 is an extensively refactored, super-modernized,
and ultra-supercharged derivative of Perl 5. Here is a brief summary 
of some notable features, mostly copied from

(http://dev.perl.org/perl6/faq.html):

* optional explicit strong typing
* proper parameter lists
* active metadata on values, variables, subroutines, and types
* declarative classes with strong encapsulation
* full OO exception handling
* support for the concurrent use of multiple versions of a module
* extensive introspection facilities (including of POD)
* LL and LR grammars (including a built-in grammar for Perl 6 itself)
* subroutine overloading
* multiple dispatch
* named arguments
* a built-in switch statement
* hierarchical construction and destruction
* distributive method dispatch
* method delegation
* named regexes
* overlapping and exhaustive regex matches within a string
* named captures
* parse-tree pruning
* incremental regex matching against input streams
* macros (that are implemented in Perl itself)
* user-definable operators (from the full Unicode set)
* chained comparisons
* a universally accessible aliasing mechanism
* lexical exporting (via a cleaner, declarative syntax)
* multimorphic equality tests
* state variables
* hypothetical variables
* hyperoperators (i.e. vector processing)
* function currying
* junctions (i.e. superpositional values, subroutines, and types)
* coroutines

OK, that's a semi-awesome feature forest of details, but what about a 
high-level big picture overview from 35,000 feet?


First of all, Perl 6 is going to be the heart of a vastly larger 
software super-system, C6PAN (which will subsume Perl 5’s CPAN, an 
already huge and powerful collection of Perl modules).


For convenience here, we'll call Perl 6 + C6PAN "Perl 6++".

When it comes to "embrace and extend", Perl 6++ is exceptionally 
promiscuous: Perl 6++ has (selectively) borrowed widely from our many 
friends, including Ruby, Python, Smalltalk, Lisp, Haskell, and others.


So what roles does all of the above position Perl 6++ for? Here are my 
long-term predictions:


* Perl 6++ is going to be the counterpart of world English (which
exceeds all other languages in importing new concepts).
* Perl 6++ is going to be the software world’s first counterpart of 
the Great Library of Alexandra.
* Perl 6++ is going to be the first "mainstream-strength" 
super-morphic programming system.

* Perl 6++ is going to be the principal collaborative software system
of super-natural intelligence.
* Perl 6++ will carry us to the age of kilo-core, mega-thread
processors and the trillion node internet.

In summary, Perl 6++ is going to be the software launch pad of the
"singularity" age. (By that time, however, it will have evolved into
Perl 7++ or Perl 8++. Perl 6++ will make the development of its 
eventual, inevitable successor very much easier, and it will likewise 
help accelerate the advance of other existing and new languages as well.)


=== General Perl 6 status ===

<>

* Design:

* The major language domains are fairly complete, but many {corn

Parrot Bug Summary

[Parrot Bug Summary]

Parrot Bug Summary

http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon May 8 13:15:03 2006 GMT
---

  * Numbers
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Numbers

Ticket Counts: 87 new + 207 open = 294
Created this week: 15
Closed this week: 8

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
39018  t/pmc/complex failures on Solaris 8/SPARC
39004  [PDD] review pdd25_threads.pod
39003  [PDD] review pdd24_events.pod
39002  [PDD] review pdd23_exceptions.pod
39001  [PDD] review pdd22_io.pod
39000  [PDD] review pdd19_pir.pod
38999  [PDD] review pdd18_security.pod
38998  [PDD] review pdd17_basic_types.pod
38997  [PDD] review pdd16_native_call.pod
38996  [PDD] review pdd15_objects.pod
38995  [PDD] review pdd14_bignum.pod
38994  [PDD] review pdd13_bytecode.pod
38993  [PDD] review pdd12_assembly.pod
38992  [PDD] review pdd11_extending.pod
38991  [PDD] review pdd10_embedding.pod
38990  [PDD] review pdd09_gc.pod
38989  [PDD] review pdd08_keys.pod
38988  [PDD] review pdd07_codingstd.pod
38987  [PDD] review pdd06_pasm.pod
38986  [PDD] review PDD05_opfunc.pod
38985  [PDD] review PDD04_datatypes.pod
38984  [PDD] review pdd02_vtables.pod
38983  [PDD] review PDD01_overview.pod
38976  ResizablePMCArray uses too much memory
38969  parrot source does not conform to standards
38968  Parrot 0.4.4
38967  Parrot 0.5.0
2 - 3 weeks old
38964  .sub names can't be Unicode.
3 - 4 weeks old
4 - 5 weeks old
38887  Result of INFINITY or NAN stringification is platform dependent
5 - 6 weeks old
38823  [BUG] solaris 10 w gcc
6 - 7 weeks old
38788  make test results
7 - 8 weeks old
38764  Test results of parrot on Freebsd
8 - 9 weeks old
38691  OSX bus error in punie-clone
9 - 10 weeks old
10 - 11 weeks old
38594  [BUG] source line numbers
11 - 12 weeks old
12 - 13 weeks old
38469  [BUG] -O1 branch optimization
13 - 14 weeks old
38432  Exception thrown from constructor leads to oddness
14 - 15 weeks old
15 - 16 weeks old
16 - 17 weeks old
17 - 18 weeks old
38131  Configuration system should detect symlinks availability
18 - 19 weeks old
19 - 20 weeks old
20 - 21 weeks old
37949  String PMC get_string Method Doesn't Copy Internal String
---

Overview of Open Issues

Platform   Severity   Tag  Lang
Win32 3abandoned 05005threads   0  BASIC0
sco   0fatal 0notok 0  Zcode0
riscos0High  0ok0  Amber0
qnx   0low   1Patch10  punie1
powerux   0medium1regex 0  bc   0
other 0none  0sendToCPAN0  urm  0
os390 0Normal1Todo177  tcl 27
os2   0unknown   0unknown   0  scheme   0
openbsd   1Wishlist  3utilities 0  ruby 0
next  0  notabug   0  python   0
Solaris   0   library   0  plot 0
sunos 0   install   1  ook  0
svr4  0   bounce0  m4   0
VOS   0   Bug  22  jako 0
vms   0   compiler  0  forth0
uts   0   configure 0  cola 0
unknown   0   core  0  bf   0
unix  0   dailybuild0  befunge  0
unicosmk  0   docs  0  Lisp 0
unicos0   duplicate 0
sysv  0   wontfix   0
svr5  0
netbsd0
mswin32   0
dynixptx  0
dos   0
dgux  0
dec_osf   0
darwin0
cygwin_nt 0
cygwin0
bsdos 0
All   2
freebsd   0
generic   0
gnu   0
MacOS X   0
macos 0
machten   0
mac   0
lynxos0
Linux 0
irix640
irix  0
HPUX  0
aix   0
---

Ticket Status By Version

New or OpenResolved

---

Requestors with most open tickets

Will Coleda   89
jerry gay 38
Joshua Hoblitt29
Leopold Toetsch   25
Matt Diephouse12
Andy Dougherty 9
Patrick R. Michaud 8
Will Coleda8
Bernhard Schmalhofer  

Re: RFC: Community Education Page --> perl.perl6.meta

[Conrad Schneiker]

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

Scans

[Gaal Yahas]

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

[Juerd]

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

[Gaal Yahas]

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: RFC: Community Education Page --> perl.perl6.meta

[Conrad Schneiker]

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

[Conrad Schneiker]

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

[Juerd]

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

[TSa]

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:, 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:. Then the hash
hopefully uses this operator when its key type is CaseInsensitive.
--

W3C validator

[Gabor Szabo]

I must be missing something but I don't understand why is there
no module that would provide the W3C validation without hitting
http://validator.w3.org and without the need to setup a similar web site?

WWW::CheckSite::Validator uses that web site
WebService::Validator::HTML::W3C provides an interface to the W3C web site.

Did I miss the module or is there some difficulty in creating such module,
something I don't see?

As an alternative, is there a downloadable and free command line tool
that would do this job ?

Gabor

Re: "normalized" hash-keys

[Smylers]

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:, 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:. 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 C, 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 C and C
subs.

Smylers

Re: "normalized" hash-keys

[Ruud H.G. van Tol]

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: W3C validator

[Andy Lester]

On May 8, 2006, at 10:53 AM, Gabor Szabo wrote:


I must be missing something but I don't understand why is there
no module that would provide the W3C validation without hitting
http://validator.w3.org and without the need to setup a similar web  
site?


Try my HTML::Tidy.  It's based on libtidy.

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[REPOST] [ANNOUNCE] Test::Group 0.02

[Dominique Quatravaux]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dominique Quatravaux a écrit :

> Dear perl-qa members,
>
> I am pleased to announce the first public release of Test::Group, a
> handy module for grouping batches of tests together.

Due to a hiccup in PAUSE this week-end, my upload is only appearing
now on search.cpan.org. If you were interested the first time around,
now is the time to give it a try!

http://search.cpan.org/search?query=Test%3A%3AGroup

With my apologies for trying your patience.

- --
Dominique QUATRAVAUX   Ingénieur senior
01 44 42 00 08 IDEALX

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEX23UMJAKAU3mjcsRAiJhAJ4qh1FrRd+5GY0LicMA8ockd2KNkwCeMvJq
lRNLtENDup0KPIfbraKejGs=
=BcK8
-END PGP SIGNATURE-

Re: W3C validator

[Andy Lester]

On May 8, 2006, at 11:20 AM, A. Pagaltzis wrote:


* Andy Lester <[EMAIL PROTECTED]> [2006-05-08 18:00]:

Try my HTML::Tidy. It's based on libtidy.


Speaking of which, any chance that’ll get a somewhat usable
interface? Right now, parser options have to be written to a file
and the function that actually cleans the HTML is just documented
as “returns a true value.”


It's very usable!

As long as you don't want to set parser options! :-)

Yeah, it's on the list of stuff to do. :-/

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: W3C validator

[A. Pagaltzis]

* Andy Lester <[EMAIL PROTECTED]> [2006-05-08 18:00]:
> Try my HTML::Tidy. It's based on libtidy.

Speaking of which, any chance that’ll get a somewhat usable
interface? Right now, parser options have to be written to a file
and the function that actually cleans the HTML is just documented
as “returns a true value.”

Regards,
-- 
Aristotle Pagaltzis // 

Re: W3C validator

[Gabor Szabo]

I checked it again, one can download the source code of their service
from here http://validator.w3.org/source/
and it is even packaged in some of the linux distros.

(It is of course slightly outdated on Debian)

Someone might want to write a wrapper around it
or maybe use WebService::Validator::HTML::W3C with a
local URL instead of the real W3C service.

Gabor

Re: "normalized" hash-keys

[Larry Wall]

On Mon, May 08, 2006 at 12:34:26PM +0200, Dr.Ruud wrote:
: What would be the way to define-or-set that a specific hash has
: non-case-sensitive keys?

Use a shaped hash with a key type that defines infix:<===> appropriately,
since object hashes are based on infix:<===> rather than infix:.

: Or broader: that the keys should be normalized (think NFKC()) before
: usage?

I think it would be up to the type to generate, transform to and/or
cache such a canonicalized key.

: Would it be easy to "delegate it to the hash"? (or use a hardly
: noticeable wrapper)

Probably--just give the hash a shape with a key type that is easily
coerced from the input types, I suspect.  Hash keys could probably
afford to do an implicit .as(KeyType) even if the current language
were to disallow implicit conversions in general.

Larry

Re: Scans

[Larry Wall]

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

[larry]

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 C 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 C 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, C is visible to both method-dispatch
 and subroutine-dispatch.  A C 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 I 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 C 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

[larry]

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 C 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 I 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