Re: Better "sort" spec?
> "TSN" == Timothy S Nelson writes:
TSN> Hi all. I saw the new "sort" idea on the Rakudo blog:
TSN> http://www.rakudo.org/2008/12/its-sort-of-like.html
TSN> ...and wondered if we can get it in the spec, as I haven't
TSN> seen any discussion on it or anything.
well, it is sort (sic) of just like what damian posted almost 5 years
ago. i found this post covers something very similar to the rakudo
implementation. i can't seem to find this proposal in any of the
synopses (at least a quick google search found nothing) so maybe it
needs to be put in the specs/synopses.
http://groups.google.com/group/perl.perl6.language/msg/728e7246c0c6b95f
there was a whole series of threads about sorting at that time.
the end of that post has this:
@sorted = sort {(%M{$^a}//-M $^a) <=> (%M{$^b}//-M $^b)} @unsorted;
@sorted = map $_[1], sort {$^a[0] <=> $^b[0]}, map [-M,$_], @unsorted;
would both become:
@sorted = sort {-M} @unsorted;
Damian
so you can see a similar single extract code for both $^a and $^b. and
this exists in perl5 in Sort::Maker (mine) and i think also in Perl6::Sort
(which is damian's).
so you have not discovered something new in perl or perl6 regarding
sorting. it has been covered and in depth but never properly integrated
into the p6 docs.
thanx,
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Free Perl Training --- http://perlhunter.com/college.html -
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Better "sort" spec?
Hi all. I saw the new "sort" idea on the Rakudo blog: http://www.rakudo.org/2008/12/its-sort-of-like.html ...and wondered if we can get it in the spec, as I haven't seen any discussion on it or anything. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Roles and IO?
Leon Timmermans wrote:
> I assumed a new role makes a new interface. In other words, that a
> type that happens to do Pollable, Mappable, Statable and Ownable
> wouldn't automatically do File in that case. If I was wrong my abuse
> of subset wouldn't be necessary. Otherwise, maybe there should be a
> clean way to do that.
Hmm... true enough.
There was another contributer here who proposed an "is like" modifier
for type matching - I believe that he used £ for the purpose, in that
'File' would mean 'anything that does File', while '£ File' would mean
'anything that can be used in the same sort of ways as File'. That
is, perl 6 uses nominative typing by default, while '£' would cause it
to use structural typing (i.e., "duck-typing") instead.
FWIW, I'd be inclined to have anonymous roles use duck-typing by
default - that is, "$Foo.does role {does Pollable; does Mappable; does
Statable; does Ownable}" would be roughly equivalent to "$Foo.does £
role {does Pollable; does Mappable; does Statable; does Ownable}" -
the theory being that there's no way that a role that you generate on
the fly for testing purposes will ever match any of the roles composed
into a class through nominative typing; so the only way for it to be
at all useful is if it uses structural typing.
(I say "roughly equivalent" because I can see cause for defining "£
Foo" such that it only concerns itself with whether or not the class
being tested has all of the methods that Foo has, whereas the
anonymous "role {does Foo}" would match any role that does Foo. As
such, you could say things like:
role {does Foo; does £ Bar; has $baz}
to test for an object that .does Foo, has all of the methods of Bar,
and has an accessor method for $baz.
--
Jonathan "Dataweaver" Lang
Re: Where does Foo::Bar.EXPORTALL comes from?
On Fri, Dec 12, 2008 at 08:42:05PM -0300, Daniel Ruoso wrote: > [...] > While all the default exportation is done by the population of the > EXPORT inner package, that doesn't happen from the outside, S11 implies > that it happens by the calling of the EXPORTALL routine, it doesn't > really make it clear where it comes from. ...this was also briefly discussed (without definite resolution) on #perl6 back in October: http://irclog.perlgeek.de/perl6/2008-10-11#i_617227 I'm simply providing the reference here -- I haven't looked to see if there was any further resolution on the issue (in either IRC or the Synopses) after that discussion. Pm
Re: List.end - last item and last index mixing
I'd say look at prior art, but "end" in this role isn't very common. It
shows up in AppleScript, where it does double duty: "end" serves as an index
in ranges ("items 3 through end of someList"), but by itself it returns the
last item, not the last index ("end of someList"), and as a lone index it
doesn't work ("item end of someList" is an error).
Most languages that have a named function or method for this sort of access
seem to use a form of "last" instead. And it's almost always the value, not
the index. Maybe P6 could have both .last and .end, where one is the item
and one is the index? But while my intuitive expectation is that "last" is
the item and "end" is the index, it's not very a strong intuition, and I
could easily see someone having the opposite expectation.
One argument for making "end" the index is that the last value is more
easily obtained via other means, but it's really not hard to go either way.
If $list.end is the last index, then $list[$list.end] gets you the last
value, although that would usually be written $list[*-1]. And if $list.end
is the last value, then $list.keys.end is the last index...
Where does Foo::Bar.EXPORTALL comes from?
Hi, I've been thinking about how I would implement module loading in SMOP and reached some points that I think need some clarification. The most important of them being about the EXPORTALL routine. While all the default exportation is done by the population of the EXPORT inner package, that doesn't happen from the outside, S11 implies that it happens by the calling of the EXPORTALL routine, it doesn't really make it clear where it comes from. If it was "Foo::Bar.EXPORTALL" it would mean that this is a method from Object, but I think this is a reminiscence of the old method-to-sub-dispatch-fallback, which would mean that EXPORTALL is a subroutine instead, being called on the package. But does that mean that there's a default EXPORTALL that is installed in every package? Does that mean that in the absense of a custom EXPORTALL, some specific code is called? daniel
Re: List.end - last item and last index mixing
Moritz Lenz wrote: > From S29: > > : =item end > : > : our Any method end (@array: ) is export > : > : Returns the final subscript of the first dimension; for a one-dimensional > : array this simply the index of the final element. For fixed dimensions > : this is the declared maximum subscript. For non-fixed dimensions > (undeclared > : or explicitly declared with C<*>), the actual last element is used. > > > The last sentence seems to suggest that not the index of the last > element is returned, but the element itself. (Which I think is pretty weird) > > > And S02: > > : The C<$#foo> notation is dead. Use C<@foo.end> or C<@foo[*-1]> instead. > : (Or C<@foo.shape[$dimension]> for multidimensional arrays.) > > That doesn't clean it up totally either. > > So what should .end return? 2 or 'c'? > (Currently pugs and elf return 2, rakudo 'c'). @foo[*-1] would return 'c'. @foo[*-1]:k would return 2. So the question is whether @foo.end returns @foo[*-1] or @foo[*-1]:k. You might also allow 'end' to take an adverb the way that 'postfix:[]' does, allowing you to explicitly choose what you want returned; but that still doesn't answer the question of what to return by default. -- Jonathan "Dataweaver" Lang
r24318 - docs/Perl6/Spec
Author: particle
Date: 2008-12-12 22:30:59 +0100 (Fri, 12 Dec 2008)
New Revision: 24318
Added:
docs/Perl6/Spec/S19-commandline.pod
Log:
[spec] first incomplete draft of S19. needs fleshing out in many places, but
it's at the point where more eyes are sorely needed and very welcome.
Added: docs/Perl6/Spec/S19-commandline.pod
===
--- docs/Perl6/Spec/S19-commandline.pod (rev 0)
+++ docs/Perl6/Spec/S19-commandline.pod 2008-12-12 21:30:59 UTC (rev 24318)
@@ -0,0 +1,482 @@
+=encoding utf8
+
+=head1 TITLE
+
+DRAFT: Synopsis 19: Command Line Interface
+
+
+=head1 Author
+
+Jerry Gay
+
+
+=head1 Version
+
+ Maintainer: Jerry Gay
+ Date: 12 Dec 2008
+ Last Modified: 12 Dec 2008
+ Version: 1
+
+This is a draft document. This document describes the command line interface.
+It has changed extensively from previous versions of Perl in order to increase
+clarity, consistency, and extensibility. Many of the syntax revisions are
+extensions, so you'll find that much of the syntax embedded in your muscle
+memory will still work.
+
+This interface to Perl 6 is special in that it occurs at the intersection of
+the compiler and the operating system's command line shell, and thus is not
+accessed via a consistent syntax everywhere. Perl is born of Unix, and as such
+the syntax presented in this document is expected to work in a Unix-style
+shell. To explore the particularities of other operating systems, see
+
+{{ -jg
+need reference to 'porting' chapter or equivalent above
+}}
+
+
+=head1 Command Line Elements
+
+The command line is broken down into two basic elements: a I, and
+I. Each command line element is whitespace separated, so elements
+containing whitespace must be quoted. The I processes the arguments
+and performs the requested actions. It looks something like F,
+F, F, and is followed by zero or more I.
+Perl 6 does not do any processing of the I portion of the command
+line, but it is made available at run-time in the read-only C<$*VM> variable.
+
+Command line I are further broken down into I and
+I. Unlike Perl 5, I and I may be intermixed on the
+command line. This mirrors the Perl 6 argument syntax for Routines, which
+allows named and positional parameters to be intermixed. The recommendation
+for parameter ordering applies here as well, with a slight twist: keep all
+command line options together, even though this is not enforced, in order to
+avoid confusion.
+
+
+=head1 Backward (In)compatibility
+
+Muscles have a long memory. You may find yourself typing your favorite Perl 5
+options, even after Christmas arrives. {{TODO}}
+
+=head2 Unchanged Syntactic Features
+
+{{TODO}}
+
+=head2 Removed Syntactic Features
+
+{{ -jg
+need to tell a story about how perl 6 handles the migration from perl 5.
+for example, if -0 is not a valid perl 6 command line option, how does perl 6
+help the user realize and correct the mistake?
+}}
+
+
+=head1 Options and Values
+
+Command line options are parsed using the following rules:
+
+=over 4
+
+=item *
+
+Options are case sensitive. C<-o> and C<-O> are not the same option.
+
+=item *
+
+Single-letter options must not be clustered. C<-ab> never means C<-a -b>
+
+=item *
+
+Options must begin with the following symbols: C<< < -- - + : > >>
+
+=item *
+
+Option names follow Perl 6 identifier naming convention, but C<'>
+is not allowed.
+
+=item *
+
+Options may be negated with C or C, for example C<:/name>
+
+=item *
+
+The special option C<--> signals the parser to stop option processing,
+everything afterwards is parsed as a value.
+
+=back
+
+
+Delimited options are a special form of option that are specified by
+delimiters on either end, allowing options to be passed through for later
+processing, and are parsed with the following rules:
+
+=over 4
+
+=item *
+
+The opening delimeter begins with C<++>, the closing delimiter with C<-->.
+
+=item *
+
+Opening and closing delimited option names follow option identifier naming
+convention, defined above.
+
+=item *
+
+Delimited options take an optional parameter using the
+C<++option=param ... --option=param> syntax. This both allows disambiguation
+(in the case where the passthru options need to pass C<--option>), but
+may also be used to direct the compiler to pass the options to a particular
+run-time component. For example, C<++RTS=parser ... --RTS=parser> directs
+the delimited options to the parser (see L below).
+
+=item *
+
+When an optional parameter is given, it must be specified on both the opening
+and closing delimited options.
+
+=item *
+
+If the closing delimiter is omitted, the rest of the command line is consumed.
+
+=item *
+
+The C<--> option has no effect within a delimited option.
+
+=item *
+
+Delimited options cannot be negated.
+
+=back
+
+
+Values are parsed with the following rules:
+
+=over 4
+
+=item *
+
+Values containing whitespace must be enclosed in quotes, for example
+C<-O="spacy val">
+
+=
List.end - last item and last index mixing
>From S29: : =item end : : our Any method end (@array: ) is export : : Returns the final subscript of the first dimension; for a one-dimensional : array this simply the index of the final element. For fixed dimensions : this is the declared maximum subscript. For non-fixed dimensions (undeclared : or explicitly declared with C<*>), the actual last element is used. The last sentence seems to suggest that not the index of the last element is returned, but the element itself. (Which I think is pretty weird) And S02: : The C<$#foo> notation is dead. Use C<@foo.end> or C<@foo[*-1]> instead. : (Or C<@foo.shape[$dimension]> for multidimensional arrays.) That doesn't clean it up totally either. So what should .end return? 2 or 'c'? (Currently pugs and elf return 2, rakudo 'c'). Cheers, Moritz
Re: Roles and IO?
HaloO, Leon Timmermans wrote: I assumed a new role makes a new interface. In other words, that a type that happens to do Pollable, Mappable, Statable and Ownable wouldn't automatically do File in that case. I also think that a new role File that does also the four others is a new type on its own, particularly if it has a body that defines additional stuff. If I was wrong my abuse of subset wouldn't be necessary. Otherwise, maybe there should be a clean way to do that. Now I'm thinking of it, wouldn't something like our ::File = Mapable & Pollable & Statable & Ownable; do the trick? IIRC, we deemed junctions as unfit for type constructors. A type constraint that requires all types to match uses juxtaposition and if one interface is enough a non-junctive | is used. So without the ampersands it should be fine. On Fri, Dec 12, 2008 at 9:23 AM, Dmitry Karasik wrote: Wouldn't the proposed solution raise an error if an unsupported role method is tried? It's not that the proposed solution is inappropriate, but the problem that I think you're trying to solve won't be solved by it. In the worst case scenario, you're right. However if you use the roles properly this shouldn't happen because you'd get an error much sooner. If your interface expects a Seekable and you pass it a pipe, it will immediately raise an error, instead of waiting until you try to use it. Yes, I like the idea of a fine-grained set of roles and types composed of it by juxtaposition. This allows signatures to state their requirements clearly and machine enforcable. IOW, your approach precisely solves the problem that fat interfaces can raise errors only lately, that is when a call is attempted. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Roles and IO?
On Fri, Dec 12, 2008 at 3:04 AM, Jon Lang wrote: > One of the things about roles is that once you have composed a bunch > of them into another role, they're considered to be composed into > whatever that role is composed into. So "does File" would be > equivalent to "does Mappable does Pollable does Statable does Ownable" > (barring potential conflicts between Mappable, Pollable, Statable, and > Ownable which File would presumably resolve). I assumed a new role makes a new interface. In other words, that a type that happens to do Pollable, Mappable, Statable and Ownable wouldn't automatically do File in that case. If I was wrong my abuse of subset wouldn't be necessary. Otherwise, maybe there should be a clean way to do that. Now I'm thinking of it, wouldn't something like our ::File = Mapable & Pollable & Statable & Ownable; do the trick? On Fri, Dec 12, 2008 at 3:52 AM, Mark J. Reed wrote: > As Jonathan said, I think composition makes more sense here... but what if > you have an interface that expects an IO object and does nothing with it but > pass it into some other interface? How does it declare that? It seems like > there still needs to be a generic superrole that means "some non-empty but > unspecified subset of these roles" - maybe "Closable" would work, but it's > not real clear. Yeah, I wasn't clear on that, but I agree there should be some base role shared by all these roles, though I'm wondering if that should be shared by all handles or just IO handles. I see no reason why "Closable" should be limited to IO handles, but I do see a use for being able to indicate you're talking about an IO handle. I'd say it makes sense to define IO as Readable | Writable. On Fri, Dec 12, 2008 at 9:23 AM, Dmitry Karasik wrote: > Wouldn't the proposed solution raise an error if an unsupported role > method is tried? It's not that the proposed solution is inappropriate, > but the problem that I think you're trying to solve won't be solved > by it. > In the worst case scenario, you're right. However if you use the roles properly this shouldn't happen because you'd get an error much sooner. If your interface expects a Seekable and you pass it a pipe, it will immediately raise an error, instead of waiting until you try to use it. Regards, Leon
Re: Roles and IO?
Hi Leon! Leon> Perl 5's solution is to use a fat interface, and raise an error if Leon> an unsupported action is tried. Wouldn't the proposed solution raise an error if an unsupported role method is tried? It's not that the proposed solution is inappropriate, but the problem that I think you're trying to solve won't be solved by it. -- Sincerely, Dmitry Karasik
