Re: "temp" vs "my"
What you want is OUTER ...
my $v = "original";
> {
> my $v = OUTER::<$v>;
> say $v;
> $v = "new one";
> say $v;
> }
> say $v;
It's how you access the outer scope from an inner scope.
-Scott
On Wed, Oct 3, 2018 at 1:10 AM yary wrote:
> Reading and playing with https://docs.perl6.org/routine/temp
>
> There's an example showing how temp is "dynamic" - that any jump outside a
> block restores the value. All well and good.
>
> Then I thought, what if I want a lexical temporary value- then use "my"-
> and this is all well and good:
>
> my $v = "original";
> {
> my $v = "new one";
> start {
> say "[PROMISE] Value before block is left: `$v`";
> sleep 1;
> say "[PROMISE] Block was left while we slept; value is still `$v`";
> }
> sleep ½;
> say "About to leave the block; value is `$v`";
> }
> say "Left the block; value is now `$v`";
> sleep 2;
>
> Then I thought, well, what if I want to initialize the inner $v with the
> outer $v.
>
> my $v = "original";
> {
> my $v = $v; # "SORRY! Cannot use variable $v in declaration to
> initialize itself"
> say "inner value is $v";
> $v= "new one";
> ...
>
> Gentle reader, how would you succinctly solve this contrived example?
> Anything you like better than this?
>
> my $v = "original";
> given $v -> $v is copy {
> say "inner value is $v"; # "original", good
> $v= "new one";
>
>
> -y
>
Re: r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.
On Sun, Jul 11, 2010 at 12:56 PM, pugs-comm...@feather.perl6.nl wrote: Author: Kodi Date: 2010-07-11 19:56:33 +0200 (Sun, 11 Jul 2010) New Revision: 31627 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:09:44 UTC (rev 31626) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:56:33 UTC (rev 31627) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 8 Apr 2010 -Version: 7 +Last Modified: 11 July 2010 +Version: 8 The document is a draft. @@ -88,11 +88,12 @@ All four of the aforementioned forms of Cnew accept two additional named arguments. C:formatter is a callable object that takes a CDateTime and returns a string. The default formatter creates an ISO 8601 timestamp (see -below). C:timezone is a callable object that takes a CDateTime and -returns a two-element list giving the difference from UTC in (possibly both -negative, but not of opposite signs) hours and minutes. Alternatively, -C:timezone can be a two-element list, which is interpreted as a static -offset from UTC. The default time zone is C(0, 0) (i.e., UTC). +below). C:timezone is a callable object that takes a CDateTime to +convert and a CBool that specifies the direction of the conversion: to +UTC if true, from UTC if false. Perhaps it's just me, but a boolean value to specify the direction of conversion seems wrong-ish. An enum with two values TO_UTC and FROM_UTC would be a little more self-documenting. -Scott
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. As another data point ... me too. I'd prefer to see hyphens than underscores. -Scott They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak cma...@gmail.com wrote: John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including Cday_of_week. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl -- Mark J. Reed markjr...@gmail.com
Re: Custom errors on subsets?
On Tue, Jan 5, 2010 at 1:07 AM, Ovid
publiustemp-perl6langua...@yahoo.comwrote:
--- On Mon, 4/1/10, yary not@gmail.com wrote:
From: yary not@gmail.com
How about
multi sub foo(Any $name) { die Houston, we have a major
malfunction.}
Looks like tha would work, but it forces the developer to remember to write
this extra code every time they may have a constraint failure, if they
forget, we're back to the old, cryptic message. It would be much nicer to
be able to do this (psuedo-code, obviouly):
subset Filename of Str where { $_ ~~ :f }
:OnFail { No such file: '$_' }
subset Celsius of Num where { $_ = -273.15 }
:OnFail { Celsius temperature should be a Num = -273.15, not '$_' }
With something akin to that, developers won't have to write extra
boilerplate every time a constraint fails. Plus, the code is friendlier :)
I'd imagine that the functionality will fall out of the ability to have
nice failures because surely something like the following works now:
subset Filename of Str where { $_ ~~ :f or fail No such file: '$_' }
Perhaps s/fail/die/, but that seems like a means to your desired end.
-Scott
--
Jonathan Scott Duff
perlpi...@gmail.com
Rakudo Perl 6 development release #22 (Thousand Oaks)
Announce: Rakudo Perl 6 development release #22 (Thousand Oaks) On behalf of the Rakudo development team, I'm pleased to announce the October 2009 development release of Rakudo Perl #22 Thousand Oaks. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine (see http://www.parrot.org). The tarball for the October 2009 release is available from http://github.com/rakudo/rakudo/downloads Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo. Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. The October 2009 is code named Thousand Oaks for their amazing Perl 6 hackathon, their report at http://www.lowlevelmanager.com/2009/09/perl-6-hackathon.html, and just because I like the name :-) Since the 2009-08 release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This means that, unlike previous versions of Rakudo Perl, the perl6 (or perl6.exe) executables only work when invoked from the Rakudo root directory until a make install is performed. Running make install will install Rakudo and its libraries into the Parrot installation that was used to build it, and then the executables will work when invoked from any directory. This release of Rakudo requires Parrot 1.7.0. For the latest information on building and using Rakudo Perl, see the readme file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Some of the specific changes and improvements occuring with this release include: * Rakudo is now passing 32,582 spectests, an increase of 17,085 passing tests since the September 2009 release. With this release Rakudo is now passing 85.0% of the available spectest suite. * We have a huge increase in the number of spectests relating to the Complex and Rat numeric types. * Complex numbers are now implemented as a Perl 6 class, and supports all trigonometric functions from the specification. * Rakudo has a new signature binder which makes calling routines and operators much faster, and allows binding of positional arguments by name. * Rakudo has improved signature introspection, better errors relating to signatures and signature literals are now supported. * Rakudo now supports accessing outer lexical variables from classes and packages. * Some new variants of the series operator are now implemented. * When configuring Rakudo with --gen-parrot, the --optimize flag is now passed to Parrot's Configure.pl The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#23) is scheduled for November 19, 2009. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: Re-thinking file test operations
On Thu, Jul 9, 2009 at 7:50 PM, Aristotle Pagaltzis pagalt...@gmx.dewrote: * Moritz Lenz mor...@faui2k3.org [2009-07-10 00:25]: stat($str, :e)# let multi dispatch handle it for us This gets my vote. Me too. -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: New CPAN
On Thu, May 28, 2009 at 11:07 AM, Daniel Carrera daniel.carr...@theingots.org wrote: Mark Overmeer wrote: The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? See http://perlcabal.org/syn/S11.html#Versioning -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: Unexpected behaviour with @foo.elems
On Tue, May 26, 2009 at 9:03 PM, Patrick R. Michaud pmich...@pobox.comwrote:
On Tue, May 26, 2009 at 06:43:40PM -0500, John M. Dlugosz wrote:
Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote:
The following construction doesn't do what a user might expect:
for 0...@foo.elems - $k { do_something($k,@foo[$k]) }
Write ^...@foo.elems as a shortcut of 0...@foo.elems, which is the
variation to exclude that endpoint if you would rather not write
0...@foo.elems-1.
An even cleaner shortcut might be to use ^...@foo instead of ^...@foo.elems:
for ^...@foo - $k { do_something($k, @foo[$k]) }
Somewhat clearer could be:
for @foo.keys - $k { do_something($k, @foo[$k]) }
And some may prefer:
for @foo.kv - $k, $v { do_something($k, $v) }
I think the anti-pattern of 0...@foo.elems (or its incorrect
form 0...@foo.elems) should probably disappear in favor of
the above forms instead.
Or perhaps
for 0...@foo.end - $k { ... }
@foo.keys may not be what the user wanted if @foo is a sparse array.
-Scott
--
Jonathan Scott Duff
perlpi...@gmail.com
Re: Programmatic REPL history/result access?
On Wed, Feb 04, 2009 at 01:52:17PM -0500, Mark J. Reed wrote: In csh-influenced shells, you have access to the command history in a way that lets you say insert the third argument from the fourth previous command here. In Lisp, you have the * variables with the result of recent exppressions I think both of these capabilities are very valuable in an interactive programming environment. Anything like that planned for Perl6? I'm envisioning a global variable like @HISTORY, where either @HISTORY[0] or @HISTORY[*] would be the most recent command, @HISTORY[1] or @HISTORY[*-1] the next, etc, and each entry would be an object containing both the expression evaluated and the result of that expression... Without bikeshedding the details, does this seem like something worth including in the language, or something that would better be provided by a tool external to the language itself? Sounds usefulish for the perl 6 REPL. But not so much for ordinary programming. So, given that, I'd say an external tool (module) is the way to go. -Scott -- Jonathan Scott Duff d...@lighthouse.tamucc.edu
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang datawea...@gmail.com wrote: Forgive my ignorance, but what is a Prelude? -- Jonathan Dataweaver Lang The stuff you load (and execute) to bootstrap the language into utility on each invocation. Usually it's written in terms of the language you're trying to bootstrap as much as possible with just a few primitives to get things started. -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:01 AM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. If I were going to have ltrim() and rtrim(), I'd implement them in terms of trim() rather than the other way around. -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: Regex - Accessing captured subrules could be problematic
On Wed, Dec 3, 2008 at 6:19 PM, GW [EMAIL PROTECTED] wrote:
Hi,
I found something that could be problematic (haven't yet found out if it
should be a special case) in Synopsis 5. More precisely it is under the
chapter Accessing captured subrules in the test case
t/regex/from_perl6_rules/capture.t lines 67–71:
ok(eval(' bookkeeper ~~ m/single ($/single)/ '), 'Named backref',
:todofeature);
How can the parser know what you mean by $/single? Maybe you want $/
followed by single or maybe $/single?
If you wanted $/ followed by single then you would introduce some
intervening whitespace.
This is just like interpolation into double quoted strings. When you say
my @what = some example string;
my $str = This is a @what[2];
you always get the 3rd item from the @what array interpolated, not the
string '@what[2]'. If you want the latter, you have to use some other
technique (concatenation, single quotes, etc.)
A rewrite of this to $single would solve this specific problem, but
not situations like: $/singlesth. Variants like $/.single are also
ambiguous.
Same for these.
And if you're doing this in a context where whitespace has meaning (e.g.
:sigspace is in effect), but you don't want the significant whitespace, you
can turn that off temporarily (or again, use some other technique).
HTH,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Split with negative limits, and other weirdnesses
On Tue, Sep 23, 2008 at 9:38 AM, TSa [EMAIL PROTECTED] wrote:
HaloO,
Moritz Lenz wrote:
In Perl 5 a negative limit means unlimited, which we don't have to do
because we have the Whatever star.
I like the notion of negative numbers as the other end of infinity.
Where infinity here is the length of the split list which can be
infinite if split is called on a file handle. So a negative number
could be the number of splits to skip from the front of the list.
And limits of the form '*-5' would deliver the five last splits.
As another data point, this is the first thing I thought of when I read the
email regarding negative limits. But then I thought we're trying to get
away from so much implicit magic. And I'm not sure the failure mode is loud
enough when the skip-from-the-front semantics /aren't/ what you want (e.g.,
when the limit parameter is variable-ish)
A limit of 0 is basically ignored.
Here are a few solution I could think of
1) A limit of 0 returns the empty list (you want zero items, you get them)
I think this is a nice degenerate case.
Me too.
2) A limit of 0 fail()s
This is a bit too drastic.
Indeed.
3) non-positive $limit arguments are rejected by the signature (Int
where { $_ 0 })
I think that documents and enforces the common case best. But I would
include zero and use a name like UInt that has other uses as well. Are
there pragmas that turn signature failures into undef return values?
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
my two cents,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: muse on Compact Structs, pack/unpack
Or you could setup pmwiki as a nod to our perl6 compiler pumpking :-) In any case, pmwiki is simpler to setup than twiki. cheers, -Scott On Wed, Apr 2, 2008 at 7:45 PM, Larry Wall [EMAIL PROTECTED] wrote: On Wed, Apr 02, 2008 at 07:03:46PM -0500, John M. Dlugosz wrote: During ANSI/ISO standardization, they basically took every phrase and made it more and more exact. It went from understandable to leagaleze over a period of years, with sentences growing more and more detail. I could still follow it having come to it gradually. Hypertext could remedy that. All problems in computer science can be solved by another level of indirection. -- Butler Lampson ...except the problem of too many levels of indirection. -- Larry's Amendment to Lampson's Law But yes, it might be about time for hypertexting it. All but S03 have never really undergone a major reorg, and most of them could use it. Maybe it's time to set up Twiki on my home machine... Larry -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6::Doc # Hail to the new pharao
You have my permission as well. -Scott On Dec 29, 2007 7:04 AM, herbert breunung [EMAIL PROTECTED] wrote: thanks to chromatic, so i have ask Jonathan Scott Duff, Phil Crow and wait for /Adrianos answer. what i yesterday also forgot to mention is that rumor says that the emerald tables are designed to can provide answer for people on over 100 different levels of consciousness. to teach the newbeees the simpel stuff and simultaniously the Damians , last bits is what really describes the goal of my perl tables / On Friday 28 December 2007 17:04:40 herbert breunung wrote: I have also plans to add my perl article (once they transelated) for $foo perl magazine and maybe some perl.com articles, if chomatic allowes. It's fine with O'Reilly, as long as the authors of the articles agree (they hold the copyright). Where I'm the author, you have my permission. O'Reilly generally asks that you include a link to the original article as published on our site, but that's a request and not a requirement. -- c -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Concerns about {...code...}
On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
I think the issue is that bare vars don't interpolate anymore, but
they still have sigils of their own, so adding to the default interp
syntax is too noisy: ${$var} is not really much improvement over
${\(expr)}.
That's not quite accurate. Scalars interpolate as they always have, but
aggregates need to be followed their respective bracketing construct
(e.g., My array contains these items: @array[])
The only issues that I see from the original email are:
1. interpolating scalars but not code
2. having to be more careful about what type of string you're using
Adriano answered #1 I think: $yaml = Q:!c{ $key: 42 };
For the second one, if you're really just worried about how prevalent {}
appear in double-quotish strings, perhaps @Larry could be persuaded to
make them non-interpolative by default. (i.e., the adverb would be
required to make them interpolate)
-Scott
--
Jonathan Scott Duff [EMAIL PROTECTED]
Re: Concerns about {...code...}
On Thu, Dec 20, 2007 at 11:23:05AM -0600, Jonathan Scott Duff wrote:
Adriano answered #1 I think: $yaml = Q:!c{ $key: 42 };
Er, I just looked over the spec again and realized that Q does
absolutely no interpolation, so it would be more like this:
$yaml = Q:qq:!c{ $key: 42 };
or perhaps
$yaml = qq:!c{ $key: 42 };
-Scott
--
Jonathan Scott Duff [EMAIL PROTECTED]
Re: parentheses and context (was Re: state and START)
On Nov 14, 2007 2:47 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Sat, Sep 08, 2007 at 01:48:39PM +0100, Nicholas Clark wrote: Have I got this correct? state @a = foo(); # Implicit START block around call and initialisation state (@a) = foo(); # Implicit START block around call and initialisation (state @a) = foo(); # foo() called every time, assignment every time Um. That seemed to scare everyone away. If it's rephrased like this: my @a = foo(); # What context is foo called in? my (@a) = foo();# What context is foo called in? Is it the same? (my @a) = foo();# What context is foo called in? Is it the same? Are the three calls in the same context? Or two (or even three) different contexts? My two cents: foo() looks like it's always in list context, but as far as START goes, I'd think the first two call foo() only once while the third calls it every time (just as you have it written). Now, someone tell me if I'm right or wrong and why :-) Nicholas Clark -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
, , and backtracking.
How do C and C differ with respect to backtracking? For instance, foobar ~~ / [a..z]+ [ ... ] /; Both sides of the C happen in parallel, so I would guess that they both match foo then stop. Please correct me if that's wrong. Were we using the procedural conjunction: foobar ~~ / [a..z]+ [ ... ] /; I would guess that the LHS matches as much as it can (foobar), then the RHS matches foo. Since foobar ne foo, the regex engine backtracks on the LHS matching fooba and then the RHS matches foo again. Again, since fooba ne foo, the regex engine backtracks as before and this behavior continues until both sides match foo (or, in the general case, it can determine that the conjunctions can't match the same portion of the string) Or it's much simpler than that and both of the regexes above just fail because of the greediness of C+ and there is no intra-conjunction backtracking. So ... anyone care to enlighten me on how this is supposed to work? Thanks, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On Sat, Jun 16, 2007 at 12:33:58PM +0200, Mark Overmeer wrote: * Smylers ([EMAIL PROTECTED]) [070616 09:09]: * Damian Conway ([EMAIL PROTECTED]) [070615 00:17]: * Pod 6 is both a structural and a semantic scheme; you can specify both the structure of a document, and the meaning of its various components Yes, and that is one of the things which worries me most *You can*. It's full freedom, You're concerned that an aspect of Perl 6 might have too much freedom? Isn't Perl all about giving users freedom to choose their own way of doing something? Why treat documentation as a second-class citizen all the time? Why have a standard syntax for regexes, and not for docs? Aren't you glad that at last we get a standard for OO programming and named parameters? The boundary between freedom and anacharchy is faint. The docs *do* have a standard syntax. I think you've been arguing for a more *specific* standard syntax and semantics. You mention OOP. For Perl 5 we have a standard, if very general, syntax and open semantics that have allowed people to implement OOP in a variety of ways. This was all well and good for a while until we realized that there should be some more reasonable defaults (in both syntax and semantics) for common operations in OOP. I think it's the same thing with POD6. It's open enough that many documentation systems can be built from it (man pages, books, magazines, wikis, etc.) For some of those documentation systems we'll have nice conventions and other conventions will grow as needed. If we find that convention isn't enough in specific areas, we'll start to grow requirements for those cases. Requirements will be enforced by the tools we use, not by the documentation specification (that way we can use the same source document for multiple purposes with different requirements). Also, I don't think that documentation is being treated as second-class at all. It's being treated as first-class but different. To form a poor analogy, imagine threads woven together to make a tapestry. The blue threads are just as important as the red threads, but they each may have different purposes in the overall design. my two cents, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Is Perl 6 too late?
On 5/14/07, Thomas Wittek [EMAIL PROTECTED] wrote: Moritz Lenz schrieb: What makes Perl hard to read is the excessive use of special characters (/\W/). I disagree: The make it look ugly, but not hard to read. Even if it's only ugly: To what advantage? I don't think ugliness is a good characteristic of a programming language. Some people consider mathematics ugly too, but expressivity for mathematicians is valued more over general readability. So too in perl. (This is related to learn once, use often) Additionally I'm not a friend of sigils: Then you shouldn't program in perl. Really. Reason? I still haven't seen a good justification for sigils. Whether you like it or not, sigils are a part of Perl's personality that aren't going away any time soon. If you don't like them, then you shouldn't use perl. All those people claiming that Perl 6 isn't Perl would be on the money if Perl 6 didn't have sigils. To allow arrays and scalars and subs to have the same name (besides the sigil) although they have different content? No good idea I think. I also can't remember that I ever named a variable like a reserved word or operator. And even if I could, I'd consider it to be bad style. I think of it more like hungarian notation. The sigils enable a default set of expectations. Oh, I see an @, so this thing must be an array. Perl 6 has changed the meaning behind the notation ever so slightly, but the utility is still there. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Working on punie + rindolf (the implementation) Reloaded
On 4/10/07, Shlomi Fish [EMAIL PROTECTED] wrote: On Monday 02 April 2007, Marc Lehmann wrote: On Sat, Mar 31, 2007 at 05:06:34AM +0300, Shlomi Fish [EMAIL PROTECTED] wrote: Hi Marc! May I forward my reply to the list? Yes, you may. Sorry for replying probably too late, thanks for asking first! OK. Replying to two different list (which I'm not subscribed to). Well, to me, that very much sounds like we do not openly admit it, but we want to have Perl 5+1 working now, not whatever the Perl 6 people claim they will deliver 5 years ago. Heh. Well, I don't expect to be able to duplicate the Pugs functionality in a short time. :-). However, if you look at: http://www.shlomifish.org/rindolf/ I wasn't clear then. Many peopel do not want a completely different-in-spirit language called Perl6, but many people atcually want a language very much in spirit as Perl 5, just with a few important changes done. Sorry, but the phrase different-in-spirit rankled me a little bit. Perl 6 is definitely NOT different in spirit. In fact, Perl 6 is all about the spirit of Perl but changing some of the details that have held it back. All of the spirity things of Perl 5 are still present in Perl 6: TMTOWTDI, easy things easy, hard things possible, etc. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl 6 Microgrants. Now accepting proposals.
On 3/22/07, Tim Bunce [EMAIL PROTECTED] wrote: I'd like to suggest an idea for *someone else* to submit a proposal for: Heh, hoping for someone with tuits to bite, eh? :-) As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). I notice that this file (and all of the others I looked at) say at the top: // DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*- So, perhaps it's not the .h files we should be parsing, but whatever source files were used to generate them. Though, of course, some C++-to-Perl6 tool would be a good thing too. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Negative array subscripts
On 2/6/07, Smylers [EMAIL PROTECTED] wrote:
Jonathan Scott Duff writes:
... I can see the need for a pragma to help out the Pascal or Fortran
programmers start all of their arrays at something other than 0.
Those sort of crutches in programming languages (let's help folk who
know some other language -- meaning they end up programming in some
hybrid of the two languages) often turn out to be a mistake. Think of
Pascal programmers #define-ing begin and end as { and } in C, or
WordBasic being 'localized' into French, or Cuse English in Perl 5.
Sure, but I wouldn't kick out another man's crutches just because I
think he doesn't need them. Nor would I deny a man some crutches
because I have a philosophical objection to his limp.
Part of this is cos they are mostly unnecessary: there are so many
fundamental and much deeper differences between Pascal and Perl that any
Pascal programmer who's managed to learn about and cope with all the
weird and wonderful things that Perl offers isn't going to struggle with
the relatively superficial difference in array subscripts.
If you say so. I've seen code that uses perl to get it's job done but is
clearly written in a very C-ish way. Not *needing* to learn about and cope
with all the weird and wonderful things that Perl offers is one of its
strengths IMHO.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Negative array subscripts
On 2/6/07, Smylers [EMAIL PROTECTED] wrote: Blair Sutton writes: David Green wrote: In some ways, I like not having a [0] index at all: programmers may be used to counting from zero, but normal humans start with first, second, third, ... third last, second last,... My feelings are Perl 6 should stick to 0 being the index of the first element of a list. Otherwise we might alienate programmers from P5 and nearly every other language. Couldn't the first array index be adjusted by adding a user defined Parrot grammar definition that applies the transformation +1 inside [] operators instead; maybe this could be accessible via a Perl use pragma. Hmmm, a pragma's a bit heavyweight for this; how about being able to set this with a special global variable -- that sure sounds handy ... I can't quite tell how serious you are :-) I can't see Perl 6 changing the default starting index of arrays to be anything other than 0 because that meme is so pervasive (look at where substr() starts, and how we now have $0, etc.). But I can see the need for a pragma to help out the Pascal or Fortran programmers start all of their arrays at something other than 0. And I can see the need for a modifier so that an individual array can start at an index other that 0. just registering my tuppence, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Numeric Semantics
On 1/22/07, Doug McNutt [EMAIL PROTECTED] wrote: At 00:32 + 1/23/07, Smylers wrote: % perl -wle 'print 99 / 2' 49.5 I would expect the line to return 49 because you surely meant integer division. Perl 5 just doesn't have a user-available type integer. That doesn't mean that I surely meant integer division. Being used to how Perl 5 (and many other languages) do things, I would expect floating point division (though if it's not floating point beneath the covers that's fine with me as long as I can still get 49.5 out). % perl -wle 'print 99.0 / 2.0' OR % perl -wle 'print 99.0 / 2' would return 49.5 because a coercion was required and float is the default for such things. But that may be the mathematician in me. I don't see why the mathematician in you doesn't expect regular mathematical behavior from Perl. Perhaps it's that you've been using computers too long and have become used to the limitations of digital media. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Fwd: Numeric Semantics
I accidently sent this just to Darren ...
-Scott
-- Forwarded message --
From: Jonathan Scott Duff [EMAIL PROTECTED]
Date: Jan 22, 2007 6:23 PM
Subject: Re: Numeric Semantics
To: Darren Duncan [EMAIL PROTECTED]
On 1/22/07, Darren Duncan [EMAIL PROTECTED] wrote:.
I think that 1 should be an Int and 1.0 should be a Num. That makes
things very predictable for users, as well as easy to parse ... the
visible radix point indicates that you are usually measuring to
fractions of an integer, even if you aren't in that exact case. Also
importantly, it makes it easy for users to choose what they want.
For round-trip consistency, a generic non-formatted
num-to-char-string operation should include a .0 as appropriate if it
is converting from a Num, whereas when converting from an Int it
would not.
Furthermore, my preference is for Int and Num to be completely
disjoint types, meaning that 1 === 1.0 will return False. However,
every Int value can be mapped to a Num value, and so 1 == 1.0 will
return True as expected, because == casts both sides as Num.
While I'm in general agreement with everything you've said it makes me a
tad nervous to hinge so much on the difference of one character. Can you
imagine trying to track down the bug where
if ($alpha === $beta) { ... }
really should have been
if ($alpha == $beta) { ... }
Anyway, it's not like this problem wasn't already there, it's just that your
email made it stand out to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Fwd: Numeric Semantics
On 1/23/07, Paul Seamons [EMAIL PROTECTED] wrote:
While I'm in general agreement with everything you've said it makes me a
tad nervous to hinge so much on the difference of one character. Can
you
imagine trying to track down the bug where
if ($alpha === $beta) { ... }
really should have been
if ($alpha == $beta) { ... }
Anyway, it's not like this problem wasn't already there, it's just that
your email made it stand out to me.
I'm not adding support to either side of the issue. I just wanted to
point
out that with Perl 5 and other current languages I occasionally have to
search for that bug right now. Except it is spelled a little different
with
if ($alpha = $beta) { ... }
When I really meant:
if ($alpha == $beta) { ... }
It is rare though. I think the == vs === will be rare also.
Perhaps.
To me, finding the = vs. == bug is a bit easier due to the large conceptual
difference between the operators. (or maybe I'm just used to looking for it
after 20+ years of coding in languages that have = and ==) But for == vs.
===, they are both comparators and that tends to muddy the waters a bit when
it comes to your brain helping you find the bug. (at least it does for me)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: beginner's question
On Mon, Oct 30, 2006 at 08:09:56AM -0800, Richard Liu wrote: I am new to the Perl language. As a university student, I want to use perl to build some codes to work as tracing and automatic analysing tool with my data file in Linux environment. Could you kindly teach me which IDE tools should I use (freeware and shareware better :-) ) and what kind of debugger tools should I go through. Any comments are truly appreciated. Thanks in advance! Hi Richard! This mailing list is for discussion and development of the Perl6 language. Since this language is still being designed, you probably want to know about Perl5 resources. A good place to start would be http://learn.perl.org/. Also, you might want to try on IRC. There's #perl on the freenode network and #perlhelp on efnet. hope this helps, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Automatic coercion and context
On Sat, Sep 30, 2006 at 11:48:04AM -0700, Joshua Choi wrote: How does automatic coercion work? [ deletia ] 1. Csum() automatically coerces its CStr arguments into CNum parameters because CStr.does: Num. 2. Csay() then automatically coerces its CNum arguments into CStr parameters because CNum.does: Str. ...Or am I completely off the mark?) I hope you're way off the mark. Automatic coercion was one of the annoyances I remember from C++. Debugging becomes more difficult when you have to not only chase down things that are a Foo, but anything you've compiled that might know how to turn itself into a Foo. I'm of the opinion that if you need a routine to handle multiple types then you should define it such that it is sufficiently general enough to do so without the benefit of added behind the scenes magic. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: renaming grep to where
On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term grep in perl and it would be a shame to toss that away without some serious thought. That said, I'm in favor of the term filter because, as Damian mentioned, that term is used in several other languages. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Sure, but all's fair if you predeclare. Aliases imposed on us all may cause confusion, but presumably, if an individual has asked for an alias, they are willing to risk the potential confusion. For me personally, I can live with filter as an alias for grep. But that's just me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: -X file test operators
On Fri, Sep 15, 2006 at 11:28:18PM +0200, Juerd wrote: Larry Wall skribis 2006-09-15 14:03 (-0700): To which I already responded with 5: To write any prefix op as postfix, you should put it in quotes, which gives us .'-e' and .'@' and the like. (And also giving us a general way of isolating the method name from the .* variants, not to mention generating method names by interpolation without needing a temp variable.) First impressions: Ugly, hard to type, not a solution for -e, weird syntax. How is it not a solution for -e ? I thought it a perfectly good response to the problem. And, in fact, it solves a more general problem than just the -X ops. Also, presumably -e is shorthand for File.exists or some such, so that avenue still remains for the postfixification of the -X ops. TMTOWTDI after all :) Or maybe -e and friends are just macros and there are no postfix forms. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
dashed identifiers (was Re: -X file test operators)
On Fri, Sep 15, 2006 at 10:47:45PM +0200, Juerd wrote: So, we discussed making -e a real method, which would imply that identifiers can begin with -. As a bit of a tangent, occasionally I wish that we could use - in identifiers instead of _. I'd rather type $some-long-name than $some_long_name if only to not touch the shift key :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: META vs meta
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote: Larry Wall wrote: : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta. .META is more correct at the moment. Does making it all upper caps really help? It's still a pollution of the method space, any way that you look at it... Yeah but perl has already has a cultural claim on ALLCAPS thingys. So, yes, it does help. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Implicit current-index variable, scoped inside for-loops
Having read this thread, I tend to think you're insane for bringing it
up again :-)
That said, I'll entertain the discussion for a bit ...
On Tue, Aug 29, 2006 at 08:33:20AM +0200, Carl Mäsak wrote:
Questions:
- Is the itch big enough for this? The more I look at the first piece
of code, the more I'm thinking that's not so bad, really. (Though
opinions differed on the IRC channel.) Is there a situation I'm not
thinking of where the first piece of code would suck, and the second
piece of code would rock? Or is this a case of oversugaring?
I think this is a case of too much sugar. I also think making the
variable *explicit* rather than implicit is a good thing.
Pointy blocks and .kv are simple and general and can be combined
in different ways for different contexts. A special index into the
iterator thingy doesn't sound that general. Just an observation.
- I feel there's a trend of moving away from line-noise variables. I'd
hate to be one to propose adding a new one to the language. Is there a
better syntax than $.?
Okay, stepping into the madness ...
If each iteratorish construct kept the iterator around in some easily
accessible way, then you could call methods on it. There is a trend
away from line-noisy variables, but given our iterator looks like =,
maybe the variable should be $= (hey, formats don't need it any more
;-)
for @array {
say The value $=.value is at index $=.index;
say The value $_ is at index $=.index;
}
I'd far and away rather say:
for @array.kv - $i, $v {
say The value $v is at index $i;
}
though.
Hmm. Now that I think about it a little more, $= will surely be
conflated with the PODish variables in some way. But, I don't have a
better alternative. (It's at this point that I wish there was a
double-underscore glyph on my keyboard just to have an alternative ;)
- How would this work with non-array data? Specifically, what happens
with next, redo etc on a filehandle, for example?
I would expect the index to track the iterator on next/redo. That is, if
you've read line 5, then the index will be 5ish (I'm hand waving 0- vs
1-based counting). On redo it would continue to be 5, and on next it
will be 6.
But what should happen when you're reading from multiple filehandles
or multiple arrays? Should it reset at the start of a new file/array
or continue counting? And how do you get the other behavior?
With the simple primitives we have now we can easily create whichever
behavior we desire. So, I think the extra sugar for some implicit
index will do more harm than good.
Here's one useful semantic I can think of WRT $= ... if it's a true
global (yes, I know we're supposed to be shy of those too, but I'm brain
storming here) then its scope lasts beyond the bounds of the block in
which it's executing so that things like
for @array { ... last if ...; }
say Stopped processing at $=.index;
work.
But, again, we have other ways of making this work that don't involve
introducing some implicit thing.
-Scott (PerlJam)
--
Jonathan Scott Duff [EMAIL PROTECTED]
Re: clarify: does Dog is Mammal load Mammal for you?
On Mon, Aug 21, 2006 at 11:25:26PM -0500, Mark Stosberg wrote: In S12, we see a number examples of: class Dog is Mammal http://dev.perl.org/perl6/doc/design/syn/S12.html However, it's not clear if it is necessary to preload Mammal for Dog to function properly here, or what that syntax would be. I've been under the impression that Mammal wouldn't have to be preloaded, but it would have to be sufficiently defined before the end of compilation. Whether that comes in the form of Cuse Mammal or some other construct, I don't know. As far as Cis Mammal autoloading, right now, I'm of the opinion that the programmer should be explicit about loading the code that defines Mammal but I don't have a strong argument for that position. But, assuming for the moment that Cis Mammal autoloads CMammal.pm, does that mean that class Dog is Mammal-4.5 is valid? This seems like something we shouldn't encourage as it tends toward tight coupling of implementations where it should be tight coupling of abstractions. I don't know ... someone argue my brain into a new position :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: NEXT and the general loop statement
On Thu, Aug 17, 2006 at 11:45:06PM -0400, Joe Gottman wrote:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 8:44 PM
To: Perl6 Language List
Wasn't NEXT supposed to do something tricky, such as being mutually
exclusive with LAST? I remember a debate some time ago where some
complained but that would be hard to implement, and the solution
being mostly correct but failing in this case.
I seem to recall NEXT being created in order to do things like this:
for @objs {
.print;
NEXT { print , }
LAST { print \n }
}
We also might consider using perl6's hypothetical features to
implement NEXT correctly in all cases (except for those cases where
the loop update condition cannot be hypotheticalized).
Is this even possible? This would require Perl to know which iteration is
going to be the last one. In many cases there is no way to know this:
repeat {
$num = rand;
print $num;
NEXT {print ',';}
LAST {print \n;}
} while $num 0.9;
If rand is a true random-number generator it would take a time machine to
determine whether to call NEXT or LAST.
(Sorry for the double post.)
Depends on when it fires I guess. Your example might be equivalent to
this perl5ish:
while (1) {
$num = rand;
print $num;
last if $num 0.9;
print ,; # NEXT
}
print \n; # LAST
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Curious corner cases concerning closure cloning
On Mon, Aug 14, 2006 at 04:01:47PM +, Luke Palmer wrote:
What do these do?
for 1,2 {
my $code = {
my $x;
BEGIN { $x = 42 }
$x;
};
say $code();
}
Assuming that variables are available immediately as
they are parsed and that BEGIN blocks disappear as soon as they
execute, I'd expect that the first $code would be equivalent to
my $code = { my $x = 42; $x; };
and the second code would be equivalent to
my $code = { my $x ; $x; };
So, I guess the output would be
42
# this line intentionally left blank :-)
for 1,2 {
my $code = {
state $x;
BEGIN { $x = 42 } # mind you, not FIRST
$x++;
};
say $code();
say $code();
}
Same thing here, except because it's a state variable, it keeps it's
value between invocations, so the output would be:
42
43
# again, blank on purpose
1
for 1,2 - $x {
END { say $x }
}
For this one I'd guess that a solitary 2 is output. The END block
closed over the $x and the last value that $x obtained was 2.
my humble guesses,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Module/Class Authoritys
On Thu, Aug 10, 2006 at 10:25:24PM -0700, Darren Duncan wrote:
At 12:35 AM -0400 8/11/06, Stevan Little wrote:
Quick question for the group.
Can there be more than one authority?
module Foo-0.0.1-cpan:JRANDOM-http://www.foo.org-mailto:[EMAIL PROTECTED]
S11 would seem to indicate no (it states that names are made up of 3
parts), but I guess I am wondering if one of those parts can have
multiple sub-parts in it?
Thanks,
- Stevan
Perhaps something like what is done with versions; eg:
Foo-0.0.1-(cpan:JRANDOM|http://www.foo.org|mailto:[EMAIL PROTECTED])
What does it *mean*? In a module declaration it seems out of place. And
this is something that can be solved culturally (the CPAN could provide
a name that aliases multiple authorities, for instance), so you really
only need one authority in a declaration.
In a use, it would seem that you're saying use any one of these,
they are equivalent for my purposes when you say
use Foo-0.0.1-(X|Y);
Though could you imagine tracking down the bug when they *aren't*
equivalent? Seems like a bad idea.
I can see some use for this though:
use Foo-0.0.1-{X,Y};
if it means try Foo-0.0.1-X and then, if that fails, try Foo-0.0.1-Y
But that's just moving some information from the normally invisible
@INC into the module name.
And what do we do with the combinatorial explosion of this?
use Foo-(1.2 .. 3.3)-(X|Y|Z);
Suddenly it seems like a really good idea to only have one authority.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: S04 - forbidden coding-style
On Thu, Jul 20, 2006 at 10:18:57AM -0700, Larry Wall wrote:
It ain't easy. Maybe we should just make statement modifiers uppercase
and burn out everyone's eye sockets. :)
Or just give them some sort of syntactic marker ... I know!
loop {
...
}
:while $loopy;
eat :if $hungry;
go_postal :when $aggravation 10;
.sleep :until .rested;
*Everybody* wants the colon! ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: ===, =:=, ~~, eq and == revisited (blame ajs!)
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2 ], 3 ); @bar = ( [ 1, 2 ], 3 );
op(@foo, @bar)?
Is it going to be easy to make the newbies use that when they mean it's the
same, like they currently expect == and eq to work on simple values?
Isn't that ~~?
Per S03:
Array Array arrays are comparablematch if $_ »~~« $x
~~ is really the all-purpose, bake-your-bread, clean-your-floors,
wax-your-cat operator that you're looking for.
Granted, ~~ will return true in that case. I think the main problem
is Yuval wants a guarantee that it will return true if and only if
the things on either side have the same deep structure and values.
Currently, ~~ will also return true for structures where this does
not hold. For example:
@a = ( [ 1, 2] , 3 );
@b = ( sub { return 1 }, sub { return 1 } );
@a ~~ @b; # true
Why is that true? By the rules of hyper-operation, it turns into
this:
[1,2] ~~ sub { return 1 }
3 ~~ sub { return 1 }
which is true if these return true values:
sub { return 1 }-([1,2])
sub { return 1 }-(3)
Which they do.
So, smart-match fails as a deep equality operator precisely
because it's so smart.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Why does p6 always quote non-terminals?
On Tue, Jun 27, 2006 at 09:04:27PM -0700, Dave Whipp wrote:
I was reading the slides from PM's YAPC::NA, and a thought drifted into
my mind (more of a gentle alarm, actually). One of the examples struck me:
rule parameter_list { parameter [ , parameter]* }
Its seems common in the higher layers of a grammar that there are more
non-terminal than terminals in each rule, so maybe the current rule
isn't properly huffmanized (also, the comma seemed some-how out of place
-- most symbols will need to be quoted if used in similar context). A
more traditional YACC/YAPP coding of the
rule would be:
rule parameter_list { parameter [ , parameter ]* }
Is there a strong reason (ambiguity) why every nonterminal needs to be
quoted (or could we at least have a form ( C rule:y {...} ) where
they are not)? I see this as increasingly important when rules are used
to process non-textual streams. In these cases every token will need to
be quoted using angle brackets, which at that point might become little
more than line noise.
If we flipped the idea of meta such that only literals needed
quoting for rules, I'd expect that for consistency sake we'd need to
do the same for the other regexy things. For non-grammatical regexes,
that would start to grate real quick I think. But maybe that's a good
dividing line--for m//, s///, and rx// you don't quote your literals,
and to match a rule, you use the regular assertion syntax. But
*within* a regex, token, or rule you need to quote your literals
because all non-quoted, wordish text is assumed to be an assertion.
Nah, that's as far as I'll entertain the thought because there is a
major show stopper--rules may be parameterized. In the universe of
undelimited assertions, how are you to pass parameters to the assertion?
Use parens as in a subroutine call? (rules are special subs after
all) Sounds like it invites confusion. Or would you mandate that to
get the effect of parameterized rules, you should really be using a
closure anyway?
So, I guess that answers your question ...
If not, I'm sure someone else will come along and give something more
definitive :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Can foo(123) dispatch to foo(Int) (was: Mutil Method Questions)
On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
And what about other types?
e.g. if String can't ever be best candidate for Int, then does that
mean that neither can Int ever be best candidate for Num, because
they are different types?
Well, I think Num and Int *aren't* different types because as far as
duck typing goes, Num does Int. I wouldn't expect that String does
Int though (at least not without some help :).
The way I see it, the types specified in the signature are like
constraints. When you say
sub foo (Num) { ... }
the signature says that only an item that can perform the Num role may
fit in this slot. When perl tries to match Capture to Signature,
it checks the type of each argument in the Capture against the
does list for each parameter in the Signature. If the argument type
appears in the does list of the Signature, then it's a match and all
is well. Otherwise it's an error. Since Num does Int, a call such
as Cfoo(10); succeeds.
At least that's my vague interpretation of this aspect of perl6 at
this moment. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: lvalue functions and lvalue parameters
I don't have any real answers, but I'll weigh in with my opinion
anyway :-)
On Tue, Jun 20, 2006 at 10:59:01AM +0100, Daniel Hulme wrote:
I've just thought of an interesting interaction with lvalue functions
and call by foo. What if I want to write, say, an lvalue ?? !! function
thus
sub cond(Bool $c, $a, $b) is rw {
if $c return $a else return $b;
}
Will this fail because $a and $b are not rw? If so, will it fail at run-
or compile-time? What about this:
That looks like it should be a compile-time failure to me.
sub cond(Bool $c, $a is copy, $b is copy) is rw {
if $c return $a else return $b;
}
Is it allowed, and if so is the behaviour to return a writeable copy of
$a or $b? I imagine that in any case
I'd expect a compile-time failure here too, or at the very least a
warning. Besides, returning a local copy each time hardly seems
useful, except perhaps as a way to leak memory.
sub cond(Bool $c, $a is rw, $b is rw) is rw {
if $c return $a else return $b;
}
will do what I want.
That is what I would expect too.
my Int $a is constant = 0;
my Int $b is constant = 0;
(cond(True, $a,$b))++;
We have a constant declarator now, so that would be
constant Int $a = 0;
constant Int $b = 0;
(cond(True, $a,$b))++;
and that should fail at compile time because the compiler knows that
$a and $b are constant and can't be rw.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Concurrency: hypothetical variables and atomic blocks
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote: Larry Wall wrote: The way I see it, the fundamental difference is that with ordinary locking, you're locking in real time, whereas with STM you potentially have the ability to virtualize time to see if there's a way to order the locks in virtual time such that they still make sense. Then you just pretend that things happened in that order. Forgive this ignorant soul; but what is STM? Software Transaction Memory -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: A rule by any other name...
On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote: rule: - Has :ratchet and :skip turned on by default - May only be used inside a grammar Should that be - Must be declared as part of a grammar or role ??? The verb used doesn't make much sense to me there. I use a rule when I'm applying it as a pattern to a string. The situation where rules can be defined anywhere but must only be used in a grammar doesn't make sense to me, so I assume that you meant that rules must belong to a grammar. (btw, I also assumed that may only really meant must) And if we're keeping the correspondence between classes+methods and grammars+rules, then surely grammars are composable entities just like classes. Seeking clarification, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: A rule by any other name...
On Thu, May 11, 2006 at 12:19:21PM -0700, Allison Randal wrote:
Jonathan Scott Duff wrote:
On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote:
rule:
- Has :ratchet and :skip turned on by default
- May only be used inside a grammar
Should that be
- Must be declared as part of a grammar or role
???
It is:
- The 'rule' keyword may only be used inside a grammar
So, just to be clear, does that mean that the following holds:
# assume no surrounding grammar-context
rule foo { ... } # compile-time error, no grammar
my $ar = rule { ... } # compile-time error, no grammar
grammar Foo;
rule bar { ... } # legal, Foo::bar rule
my $ar = rule { ... } # legal, Foo::ANON rule
# assume no surrounding grammar-context
rule Foo::bar { ... } # legal, Foo::bar rule
my $ar = grammar Foo { rule { ... } } # legal, Foo::ANON rule
And the way to get a grammarless rule is to use either rx or regex with
the appropriate modifiers.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Scans
On Tue, May 09, 2006 at 06:07:26PM +0300, Markus Laire wrote: ps. Should first element of scan be 0-argument or 1-argument case. i.e. should list([+] 1) return (0, 1) or (1) I noticed this in earlier posts and thought it odd that anyone would want to get an extra zero arg that they didn't specify. My vote would be that list([+] 1) == (1) just like [+] 1 == 1 -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: S5 - Question about repetition qualifier
On Tue, Apr 25, 2006 at 09:57:58PM -0400, Joe Gottman wrote:
According to Synopsis 5, the repetition qualifier is now **{.} where the .
must correspond to either an Int or a Range. This seems rather restrictive.
Why are we not allowed a junction of Ints, for instance
m/^ a**{1|3|5} $/ ; # Match 1,3, or 5 a's.
m/^ a**{1..5:by(2)} $/; # Match 1, 3 or 5 a
This does not seem noticeably more difficult than a range.
Also, I don't know exactly what the syntax looks like, but I can imagine
using a repetition qualifier that takes a closure of some sort, for instance
to match an odd number of repetitions
m/^ a**{($_ % 2 == 0)} $/; #I'm not sure about the syntax for the code.
m/^ a**{1..*:by(2)} $/; # match an odd number of a
:-)
I get your point though. There's no easy way to say match 1, 7, 12, or
19 with this particular syntax.
How often does that come up in practice though? I don't think I've
ever wanted something like that.
If we allow Junction of Int that also gets us Set of Int as
Junctions are just funny Sets. Why not Array of Int too?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: S05: Interpolated hashes?
On Mon, Apr 24, 2006 at 04:50:43PM +0300, Markus Laire wrote: In Synopsis 5 (version 22), Under Variable (non-)interpolation it's said that quote An interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches. (A key will match anywhere, provided no longer key matches.) /quote And under Extensible metasyntax (...) it's said that quote With both bare hash and hash in angles, the key is counted as matched immediately; that is, the current match position is set to after the key token before calling any subrule in the value. That subrule may, however, magically access the key anyway as if the subrule had started before the key and matched with KEY assertion. That is, $KEY will contain the keyword or token that this subrule was looked up under, and that value will be returned by the current match object even if you do nothing special with it within the match. /quote I don't quite understand how these relate to each other. First text is clear enough, but second seems to be something totally different. Indeed, they are saying different things about what happens when you match a hash against a string. Could someone give an example of what difference there's between interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches. and the key is counted as matched immediately; that is, the current match position is set to after the key token before calling any subrule in the value. ... I don't quite understand if the key is matched in the second version or if it's just counted as matched, whatever that means, and why the description is so dis-similar to the first quote. What those two passages are saying is that when you match with a hash, the longest key that matches will trigger the value portion of the hash to execute (what execute means depends on the nature of the value. See S05 for more details) Given, for example, the following: my %hash = ( 'foo'= ..., 'food' = ..., ); I need some food for breakfast ~~ /%hash/; That first passage says that food must match since it's the longest key that matches, so whatever the ... for the food key is will execute. The second passage says that the match cursor is placed just after the key that matched. So any subsequent matches to that string that do not reset the cursor will start just after the word food. But what if your subrule needs to know exactly which key matched or needs to match the key again for some reason? The second passage says that you may access they actual text that matched with $KEY and you may again match the actual key that matched with the KEY assertion. In my example, $KEY will contain the text food . Also, by using the KEY assertion, you can start matching at the beginning of the key (rather than just after it) and again match the same key of the hash that caused the match to succeed in the first place. speculation Why would you need to match the key again? Maybe your subrule needs to know what came before the key in order to perform some action: req() if m:c/ after need .*? KEY / # require des() if m:c/ after want .*? KEY / # desire I assume that KEY is somehow magically anchored to the spot where the key actually matched. /speculation -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r8899 - doc/trunk/design/syn
On Fri, Apr 21, 2006 at 01:12:35PM -0400, Uri Guttman wrote: a == autrijus [EMAIL PROTECTED] writes: a * S05: Oops, turns out I entirely read perlop.pod incorrectly; a it matches once only means it matches successfully once only, a not it performs the match once only. Sorry, TimToady++'s a original example of: a (state $x) ||= / pattern /; a was correct. a +To reset the pattern, simply say C$x = 0. i did a fresh read of S05 due to all the recent activity (i will post some edits and questions soonish), but that example baffles me. how does it emulate the (never used by me) // of p5? my take would be that the rx would be or-assigned to $x and it would remain set through repeated calls to the outer sub (assuming a sub). what is the context that makes it match against $_ vs returning an rx. According to S05, a /.../ matches immediately in a value context (void, Boolean, string, or numeric) and since (state $x) ||= / pattern /; is very much the same as state $x; $x = $x || /pattern/; I'd say that's a boolean context and thus matches against $_ instead of assigning the Regex object to $x. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r8899 - doc/trunk/design/syn
On Fri, Apr 21, 2006 at 11:06:20AM -0700, Larry Wall wrote: On Fri, Apr 21, 2006 at 12:45:13PM -0500, Jonathan Scott Duff wrote: : According to S05, a /.../ matches immediately in a value context : (void, Boolean, string, or numeric) and since : : (state $x) ||= / pattern /; : : is very much the same as : : state $x; $x = $x || /pattern/; : : I'd say that's a boolean context and thus matches against $_ instead : of assigning the Regex object to $x. Except the right side of || isn't in boolean context till you evaluate $x that way, so it probably wants to be written with m//: I almost added a little bit of text to the end of that other message but didn't. I think it's most appropriate now: I must say that I have trouble distinguishing when using // gives you a Regex object and when it actually does pattern matching, so I intend on always using m// when I want a match, and some form of rx// when I want an object. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [svn:perl6-synopsis] r8569 - doc/trunk/design/syn
On Wed, Apr 05, 2006 at 07:24:30PM -0700, Rutger Vos wrote: Subversion logging messages like the one below seem to be flooding this list right now. May I ask if that's what this list is for? Well, it gets the people interested in the language design first cut at the changes being made to the design docs. Which is, IMHO, part of what this list is for. That way the group can fix typoes or if there's some weird semantic, the group can send a whoa there! message. How else are we to keep abreast of changes in the design docs? Repeated reading of the website and hoping we notice when things change? Sending the log + diff gives an easy way to brain-filter the messages too. I can look at the log and decide if I really care about the minute changes to twigils enough to read through all of the places where it makes a difference. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 05:26:48PM +0200, Yuval Kogman wrote:
Hi,
my $x = 5;
{
temp $x;
# is $x 5 or undef?
}
# $x is definately 10
How did $x become 10?!?!? :-)
I think it should be 5 inside, because it makes it easy to write
things like:
I think that if Ctemp is the new Clocal, then immediately after the
Ctemp $x line, $x should hold whatever flavor of undef is appropriate.
my $x = 5;
{
temp $x++;
# $x is 6
}
# $x is 5 again
and otherwise pretty much DWIMs, except from a historical
perspective.
Is there some reason we're huffmannizing
my $x = 5;
{
temp $x = $MY::x + 1;# or whatever the proper syntax is
# $x is 6
}
$x = 5;
??
Can you elaborate an example that would show this to be a boon?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: 'temp $x;' with no assignment
On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote: On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: I think that if Ctemp is the new Clocal, then immediately after the Ctemp $x line, $x should hold whatever flavor of undef is appropriate. snip Is there some reason we're huffmannizing snip Because 90% of the code that people use local for in perl 5 is for counting levels and automatically unwrapping them. The other 10% are for more complex values. Make me believe your 90/10 numbers. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Is S05 correct?
On Mon, Feb 06, 2006 at 08:29:54PM -0500, Joe Gottman wrote: This may be a stupid question, but where can I view the fixed Synopsis? I don't think it's a stupid question at all. Larry could have meant it's fixed in my working copy when he said fixed! and there would be no possibility for you to view the fixed version until he commits his changes. When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that the modification date is November 16, 2005. Is this the most up-to- date version? I believe the html representations of these documents are generated directly from the pod source in the subversion repository. Though I don't know the particulars of how this happens. For S05, if you look at http://svn.perl.org/perl6/doc/trunk/design/syn/S05.pod you'll see the most up-to-date version. But, as pmichaud says, it doesn't differ substantially from what you've already seen. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ff and fff [Was: till (the flipflop operator, formerly ..)]
On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote: I've changed the flipflop operator/macro to ff, short for flipflop. Two questions: 1) Will ff (and fff) require whitespace around them? 2) Do we get a more punctuationish unicode equivalent? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl 6's bless is (seriously) broken
On Thu, Jan 19, 2006 at 11:07:49PM +0100, Juerd wrote: Stevan Little skribis 2006-01-19 16:59 (-0500): 2) what if the role conflicts with other roles being does-ed by Foo? Debugging hell there. Very good point. Aren't role conflicts resolved at composition time (possibly by failure)? That doesn't sound like debugging hell to me, but rather clear indication of a problem and the location of that problem. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: split on empty string
On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote:
On 2006-01-17 12:24 PM, Gaal Yahas [EMAIL PROTECTED] wrote:
While cleaning up tests for release:
.split(':')=
()# Perl 5
(,) # pugs
Which is correct? It doesn's seem to be specced yet.
I would prefer the current pugs behavior; it's consistent with the general
case, in which a string which does not match the splitting regex results in
a single-item list containing the original string. This is the Python
behavior.
I find the Perl5 (and, surprisingly, Ruby) behavior rather counterintuitive.
FWIW, I agree with Mark.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Array/list transformations.
On Thu, Dec 22, 2005 at 04:47:21PM +0100, Michele Dondi wrote: This is not a substantial issue regarding Perl 6, but is more a minor feature curiosity/meditation. It was inspired some time ago by this PM node: http://perlmonks.org/?node_id=509310 I was wondering if in addition to push(), pop() etc. there could be be rot() and roll() methods that would act upon lists (not modifying them) like thus: (qw/aa bb cc dd ee/).rot(2) # qw/cc dd ee aa bb/ (qw/aa bb cc dd ee/).rot()# qw/bb cc dd ee aa/ = same as .rot(1) (qw/aa bb cc dd ee/).roll(2) # qw/dd ee aa bb cc/ = same as .rot(-2) (qw/aa bb cc dd ee/).roll() # qw/ee aa bb cc dd/ = same as .roll(1) rot doesn't conjur the right stuff for me, sorry. Since we already have shifting operators, why not just (re)use them? If + is numeric left shift, maybe @ is array left shift. Of course, then you'd have to figure how to vary the wrapping semantics. my @a = qw/aa bb cc dd ee/; @a = @a @ 2; # or @a @= 2; my @b = @a @ 4; Okay, I'm already not liking that syntax, but the idea is the same: we have shifting ops, let capitalize on that meme. ... etc. Also I wonder if one will be able to push(), pop(), etc. array slices as well whole arrays. A' la my @a=qw/aa bb cc dd ee/; my $s=pop @a[0..2]; # or [0,2] or just [0] for that matters! # $s='cc'; # @a=qw/aa bb dd ee/; = same as what I can do with slice() Not terribly necessary, but indeed consistent IMHO. Not quite sure why you'd want this, but if we have something like this: my @a = qw/aa bb cc dd ee/; my @slice := @a[0..2]; my $s = pop @slice; (where @slice is a reference to part of @a) You get what you want and more. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl grammar for Perl5 - Perl6
On Thu, Dec 08, 2005 at 01:46:51PM -0500, Rob Kinyon wrote: As for the original question, I think that the Perl 6 grammar will be a much better example for how to parse other languages than a Perl 5 grammar would be, since one of the underlying design currents from the beginning has been that Perl 6 had to be a language that was amenable to parsing by Perl 6 rules (with a little help from a bottom-up operator-precedence expression parser.) Once Patrick is done with PGE, will it be able to parse Perl5? If so, why aren't we focusing on that? PGE isn't much of a parser; it's more like a framework for bulding parsers. So, once PGE is done, to parse perl5, you'll still have to write a grammar-ish thing that includes all of the maze of twisty executions that perl currently goes through to parse perl. The same holds for parsing perl6 only the twisty maze isn't there (or is at least much much smaller) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: scalar/array contexts in perl5 vs. perl6
On Sun, Dec 04, 2005 at 01:10:44PM -0500, Mike Li wrote: what is a good translation of the following C into perl6? [snip] in perl5, i would've written something like: code my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print @y\n /code but in perl6, the '@' sigil always means list context, Um ... do you mean s/perl6/perl5/ above? In perl6 the @ sigil does not always mean list context; it just means that you're dealing with an array somehow. Your code above is practically perl6 already. The only problem with it that I see is that you need to use @y[] to interpolate an array into a string: my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print @y[]\n -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Mon, Nov 07, 2005 at 04:46:06PM -0500, Andrew Rodland wrote: Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What I meant wasn't signatures are too much complexity -- they're not; they're simply doing something useful -- but rather too much complexity is getting thrown into signatures to the point where the gain isn't so much, but the complexity starts creeping in, and you need a book just for everyday tasks. Combined with what seems to me like a thoroughly unreadable syntax, function signatures are starting to look like a brand new version of the regex mess that p6 ditched in favor of the more consistent, more readable patterns. Well, just to point out that we didn't know a priori that the regexp syntax was a mess until we got extensive experience with it and with what we wanted from it. In the early 1990s, perl and its regular expressions were the coolest stuff ever. :-) I think the same holds for signature syntax. @Larry are doing the best juggling act they can to get it worked out such that once it's set in stone, the signature syntax will be intuitive, sensible, unobtrusive, etc. There may be complexity, but most times you shouldn't see it unless you want to do something strange and wonderous and magical. The only reason it looks like there's complexity now is because we're pushing and prodding the signature syntax to see what works and what doesn't. (At this point, I'm *really* glad the language design is taking years) Because of this there will be times when all of the guts are exposed, but I don't think that it'll always be that way. By the time perl 6.0.0 rolls around, the guts should be tucked away nicely. my two cents, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a conflict:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
In the first case, the question is how we define the set of available
methods: do we make the full hierarchy of ancestors available to the
role, or do we say that only the immediate parents are available?
People keep using the word hierarchy when talking about roles and I
keep thinking that it is the one word that definitely does NOT apply.
Heirarchies are for classes and inheritance relationships, not roles
and composition.
In my world view, a role that is composed of two other roles has full
view of the methods/attributes defined in the roles that compose it
because the landscape is quite flat. There are no hills and valleys.
When it finally comes down to composing into a class, the class sees
all of the methods/attributes provided by each and every role even the
role inside a role inside a roles.
Another way to put this would be: should the DOESA list be treated
as public or private? (My preference: the DOESA list should be
private. You don't lose any capabilities by doing so, other than the
capability to access stuff not explicitly declared - a capability that
roles don't need, and probably shouldn't have.) If DOESA is
private, then d won't have access to anything from a or b without
explicitly including them in its own DOESA list. This seems to be
restrictive, and it is - but only in the same way that making an
attribute private is restrictive.
When you say:
role A { ... }
role B { ... }
role C does A does B { ... }
role D does C { ... }
roles A and B are composed into C at compile time. If both A and B
define a method foo(), then there is a conflict (immediately, at
compile time) unless you've somehow told perl that it should defer
composition until it's actually composing classes.
What's really at question I think is whether the _default_ is to compose
immediately or to postpone composition until there's a class to compose
into. If you have roles that are never composed into classes, then it
won't matter if there's a conflict as you can't instantiate a role (not
without first turning it into a class). So, on one hand it does make
sense to defer composition until there's a class to compose into. But
it also makes sense to deal with composition conflicts incrementally
too (as roles are composed into other roles).
The second case is pretty straightforward.
And isomorphic to the first case as it is the resolution to the first
case.
In the third case, I'd be inclined to say that passing the buck is
equivalent to creating an undefined version of your own - that is, not
addressing a conflict involving method x is equivalent to saying
method x ($arg) { ... }. IOW, a class that does a role that passed
the buck is faced with an undefined method complaint if it doesn't
do something about it, not an unresolved conflict complaint.
Nah, the third case is ye olde standard conflict, just perhaps occurring
at a different space+time than had the roles been composed immediately.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we will use this later :)
}
role Bar {
method foo { ... }
}
role FooBar {
does Foo;
does Bar;
}
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do not throw an error until a
role is composed into a class. This means that when I do this:
If we say that the roles Foo and Bar are composed into the role
FooBar and that method conflicts trigger an exception at composition
time (whether composed into a role or class), then your above
declaration of FooBar will trigger an exception and force the user to
resolve the conflict.
class MyClass does FooBar {}
an exception is thrown. Unless of course MyClass has a foo method,
which will disambiguate the conflict. My question then is, can FooBar
(the role) disambiguate the foo conflict?
role FooBar {
does Foo;
does Bar;
method foo { ... }
}
Now, on the surface this seems obvious, of course the FooBar role
should be able to disambiguate.
I agree. Methods declared explicitly in FooBar should trump methods that
have been composed into FooBar (just as it would if FooBar were a class)
However, when we expand the example
other issues show up.
role Baz {
does Foo;
}
class MyClass2 does FooBar does Baz {} # Will this die?
I think yes. FooBar has a method foo() and so does Baz. They may be the
same foo() underneath because that's how the FooBar role decided to
resolve the method conflict, but Baz doesn't know that. Though, the perl
compiler needs to keep track of the composition history of classes/roles
to provide useful error messages.
Now, since MyClass2 actually does Foo twice, does that mean bar
creates a conflcit? Since bar would be found through FooBar and Baz.
I would think the answer here would be no, and that we would build
some kind of unique list of roles so as to avoid repeated consumption
like this.
In my world view it doesn't to Foo twice, it does FooBar (which is a
composed of Foo and Bar, but MyClass doesn't know the origin of the
methods) and it does Baz. Since the Baz role and the FooBar role have
the same methods because they were both composed of Foo, the perl
compiler will spit out some messages letting you know that
you've built a class from a doubly composed role.
But if you happen to do
class Foo does Bar does Bar { ... }
perl should be nice enough not to yell at you for doing the Bar role
twice.
In the case where really do want the added bits of the Baz role along
with the added bits of the FooBar role (including that disambiguation),
but perl is carping because most of the methods are the same (having
both been composed from Foo), then 1) it's probably a sign that you need
to refactor and 2) you can always use delegation to get the desired
behavior (assuming I'm correct in that you can delegate to specific
roles at composition time as a mechanism for disambiguation).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
If, OTOH we have a diamond inheritence:
You mean composition. There is no role inheritance :)
role A { method foo { ... } }
role B does A {};
role C does A {};
class D does A does B { };
I'm assuming you meant
class D does B does C { ... }
I'm not sure we need to resolve the conflict.
It depends on when composition happens. If A is composed immediately
into B and C as soon as the role is processed, then when D is being
composed, all it sees are a foo method from the B role and a foo method
from the C role.
If, however, roles aren't composed into other roles but only into
classes, then I think that
class D does B does C { ... }
would be equivalent to
class D does A does B does C { ... }
since the roles B and C would carry the uncomposed A role along with
them.
Now, since MyClass2 actually does Foo twice, does that mean bar creates a
conflcit? Since bar would be
found through FooBar and Baz. I would think the answer here would be no,
and that we would build some
kind of unique list of roles so as to avoid repeated consumption like this.
No conflict - an assimilated role is identicle to itself even
through different paths since it doesn't get access to private or
protected member data of it's consuming roles.
If, on the other hand, we have
role X trusts Foo does Foo {
has $:foo;
}
Quoth A12:
It's not clear whether roles should be allowed to grant trust. In
the absence of evidence to the contrary, I'm inclined to say not. We
can always relax that later if, after many large, longitudinal, double-
blind studies, it turns out to be both safe and effective.
Has that changed?
Also, I don't think that role is something that can be trusted :)
A12/S12 only talk about trusting classes.
role Y trusts Foo does Foo {
has $:foo;
}
role Foo {
method foo {
$:foo++;
}
}
class C does X does Y { }
there is a conflict, because Foo is reaching into either X's private
member $:foo or Y's private member $:foo (btw, they should never
conflict with each other).
Er, there is only one $:foo. X doesn't have any private members, nor
does Y (because they're roles). Only C has private members. So,
modulo the multiple composition of Foo, I don't think there's a
conflict.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
I should be allowed to create a role with all sorts of conflicts which
I leave for the classes to deal with.
Er, why? I've read this sentence several times and I'm really having
trouble grasping why anyone would deliberately create a conflicted role
and want to postpone the conflict resolution until later. It seems to me
that conflicts should be resolved sooner rather than later. Especially
in the light of run-time composition:
role A { method foo { ... } ... }
role B { method foo { ... } ... }
role C does B does A { ... }
my Dog $spot;
...
$spot does C;
Would you rather wait until perl is actually executing that last line
of code before finding out there's a conflict or would you rather know
there's a conflict at compile-time (when C is immediately composed of
A and B)?
Yes, I realize that Perl6 already has the problem that run-time
composition could cause conflicts, but I want to have a slightly
smaller chance of running into it :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Fri, Oct 28, 2005 at 06:23:28PM +0200, Yuval Kogman wrote:
On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
Er, there is only one $:foo. X doesn't have any private members, nor
does Y (because they're roles). Only C has private members. So,
modulo the multiple composition of Foo, I don't think there's a
conflict.
Really? I didn't know that... In that case roles are broken... They
will need instance data (that doesn't conflict when it's private) to
support the methods they give their consumers.
Is there any good reason to not allow roles to introduce member data
into a class?
Roles can hold instance data that will be composed into a class. What
I'm saying is that if you have two roles:
role X { has $:foo; }
role Y { has $:foo; }
And a class that's composed of them:
class Xy does X does Y { ... }
That there will not be two slots for $:foo in Xy, but only one.
But, I'm probably wrong about this as the X role may have methods that
use $:foo in one way and the Y role may have methods that use $:foo in
some other, incompatible way, so perhaps there will be a conflict just
as when there are 2 methods of the same name.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Ways to add behavior
On Wed, Oct 26, 2005 at 09:05:22AM -0700, Larry Wall wrote: Of course, there are other words that are somewhat synonymous with class, Unfortunately sort is already hosed. Maybe kind. Maybe we could go with something Linnaean like family or genus even though their relation to class isn't quite the same. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new sigil
On Tue, Oct 25, 2005 at 12:18:41PM -0600, Luke Palmer wrote:
I like that symmetry between foo and ¢foo. So to get the behavior
that an outer type variable applies to an inner sub, could I do this:
# a complicated identity function :-)
sub foo (¢T $x -- ¢T) {
my sub bar (T $z -- T) {
$z;
}
bar $x;
}
Because omitting the ¢ would not bind T.
You can even do
sub foo (¢T $x -- T) {
my sub bar (T $z -- T) {
$z;
}
bar $x;
}
I do believe.
Whereas if I wrote:
sub foo (¢T $x -- ¢T) {
my sub bar (¢T $z -- T) {
$z;
}
bar $x;
}
It would be semantically the same as above. (just like Cmy $x; my $x
would only declare one C$x, so too C¢T $x ... ¢T $y should only
bind one type to T (or ¢T) for the duration of the scope.
It would be a totally new variable in both spots in the inner sub, and
if I wrote:
sub foo (¢T $x -- ¢T) {
my sub bar (T $z -- ¢T) {
$z;
}
bar $x;
}
It would be equivalent to:
sub foo (¢T $x -- ¢T) {
my sub bar (T $z -- ¢U) {
$z;
}
bar $x;
}
I don't think so. In the first example all the T (or ¢T) are the same
type after the first ¢T (where the type is bound). In the second one
you'd get two separate types ¢T and ¢U. But ¢U would probably get bound
to the same type as ¢T as that's the type of thing that it returns
(assuming perl can figure that out).
That's if I understand Larry correctly.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: new sigil
On Thu, Oct 20, 2005 at 08:55:46AM -0700, Larry Wall wrote:
On Thu, Oct 20, 2005 at 05:53:00PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-20 8:46 (-0700):
: On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote:
: : I'm sure ¢ will have its equivalent too.
: c| or C| maybe.
:
: But
:
: sub c { ... }
: sub d { ... }
:
: if $foo eq c|d { ... }
Other suggestions welcome.
I don't know ... since we're still using ::T for classy things, I'd
kind of like to see something with a : in it. I also get the feeling
that these are type/class placeholders, so I wouldn't mind a ^ either.
Here are some suggestions:
:$T
:^T
^^T
:T
$::T
$:T
[T] # these next 3 don't evoke variable as much as
T # parametric type (ala C++)
(T)
And yes, I know several of those are already taken. I'm suggesting
that we at least think about reassigning them.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 05:12:32PM -0700, Nate Wiger wrote: Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. This quibbling over $0 and $1 seems like rampant bikeshedding to me. Given that @Larry has said that $0, $1, etc. correspond to $/[0], $/[1], etc, if you want to keep $1 as the first parenthesized part, then come up with a compelling, concrete proposal for what to do with $/[0] (and $0) keeping in mind that @array = /(foo)(bar)(baz)/; has to do the right thing. That's not my wish; just that it's time to take another look at the list of changes to see where the real-world benefit is. IMHO, self consistency is far and away more important than consistency with perl5. If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. This may mean some things that aren't quite perfect still don't get changed. (It also means lots of new stuff can still be added - I'm just talking change.) I don't understand this. Change the fewest key things relative to what? Perl5? If so, why? Is it not enough that perl5 programs will still compile and run under perl6? Just food for thought... maybe I'm wrong... I don't know about wrong, but you're certainly entering the game a little late. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote: However, this brings up an issue I was thinking about. Take this code for instance: use Cat-0.0.1; use PetStore; my Cat $kitty .= new(); --- in PetStore.pm --- use Dog; use Cat-0.0.5; Which Cat is used? I can see several options: 1) Cat-0.0.1 is used since it is in the local scope, so clearly the users choice. 2) Cat-0.0.5 is used since it is loaded after Cat-0.0.1. 3) An Ambiguity error is thrown because Cat is not specific enough. I would be _highly_ surprised if my $kitty wasn't a Cat-0.0.1 (assuming these auto aliases happen). Which Cat is available to the programmer is a lexical property that shouldn't be invalidated because some other module decided to use a different Cat. That would *so* be action at a distance. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: zip: stop when and where?
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
If we make zip return a list of tuples rather than an interleaved
list, we could eliminate the final 1/3 of those errors above using the
typechecker. That would make the for look like this:
for @a Y @b - ($a, $b) {...}
I like it (I think). I'm not sure about the syntax though. Is this one
of those places where round brackets are equivalent to square brackets?
I.e., would this be the same:
for @a ¥ @b - [$a,$b] { ... }
?
Also, it seems like this syntax would almost always require the brackets
to be correct. Most of the time people will see and expect for loops
that look like this:
for MUMBLE - $a, $b { ... }
Except now they've probably got a semantic error when MUMBLE contains ¥
or is prefixed by zip. This type of error mayn't be so easy to detect
depending on what they're mumbling about.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: zip: stop when and where?
On Tue, Oct 04, 2005 at 09:00:15PM +0200, Juerd wrote:
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... - $foo, $i { ... }
Pugs currently does b.
(a) and (d) are certainly wrong IMHO.
Surely zip could get a modifier to vary the behavior as desired?
for @foo ¥ 0... :greedy- $foo, $i { ... } # (b)
for @foo ¥ 0... :conservative - $foo, $i { ... } # (c)
Didn't we go over this a while back?
Anyway, I agree that (c) is probably the sanest default behavior.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
On Thu, Sep 29, 2005 at 11:21:20PM -0600, Luke Palmer wrote:
[ discussion on undefs elided ]
Since we can annotate our undefs now, perhaps undefs that would be
generated because there are no previous or next elements get tagged
as such. Something like:
# assuming $b and $a are before and after elements
for @list - ?$b, $c, $?a {
given $b {
when undef but generated { say a fake undef!; }
when undef { say a real undef!; }
}
}
Oh, right, and as for my favorite actual usage of for:
for @list, :lookbehind(2) :lookahead(1)
- $behind1, $behind2, $value, $ahead {
...
}
Hmm. Something like:
for @list - $c :behind($b1,$b2) :ahead($a1) { ... }
would seem to make a more direct connection between the variables and
what they are aliased to (if only there wasn't that use/mention problem
with the variables).
I think there needs to be something that clearly and unambiguously says
that C$c is the value being iterated over and clearly makes a
correspondence between the other variables and their position relative
to C$c even with whatever other syntactic mumbling may be necessary.
(And maybe the proposed use of ? is it, but it feels wrong to me)
But, don't we have something like
for @list.kv - $i,$x { ... }
and even if I'm misremembering @Larry's blessing on that particular
construct, we certainly have this:
for zip([EMAIL PROTECTED](),@list) - $i,$x { ... }
And then getting the values fore and aft of the current value is just a
matter of indexing into @list. This seems clearer to me than virtual
parameters that exist on either side of the sliding window of the real
parameters.
Also, since for seems to be some kind of non-consumptive iterator, maybe
we can get at it with some magical $?ITERATOR variable if we need to:
for @list - $x {
my ($b1,$b2) = $?ITERATOR.prev(2);
my ($a) = $?ITERATOR.next;# defaults to next(1)
}
Though that's far more syntax than using zip, but has the advantage
that it would work when @list really is a list rather than an array.
I still like using zip() or .kv and indexing the array directly. Putting
the values in an Array-like thingy seems to be a smallish price to pay
for easily getting at some number of elements before or after the
current element.
Rambling in a pre-caffienated way,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: \(...)?
On Mon, Sep 19, 2005 at 02:21:43PM +, Ingo Blechschmidt wrote: So...: [EMAIL PROTECTED]; # Reference to array, of course \(@array); # same \(((@array))); # same \(1,2,3);# Reference to a list promoted to an array (!) \(((1,2,3)));# same [EMAIL PROTECTED];# List of references to @array's elements \*(((@array))); # same \*(1,2,3); # List of references to @array's elements \*(((1,2,3))); # same Opinions? Off the cuff, I'd say that works for me. Also, wouldn't we have this? \list 1,2,3 # reference to a list promoted to an array -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: ./method defunct
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote: On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. What are the salient characteristics of looks like a method call? Is it no intervening characters between the . and the name of the method? Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Um ... isn't $?SELF a keyword? :-) Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. I think the difference in how readily understood it is will be infinitesimally small. What's confusing about ./method is shorthand for $?SELF.method? As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. I'll grant you that. But, as punctuation rich as perl is, we should provide a tool (p6doc?) to help with the searching and encourage people to use it. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. I expect that soon after perl6 is released (heck, maybe before it's released) we'll get tools that will translate perl6 to perl6 while performing some syntactic manipulation. For instance, it could explicitize code (replacing ./method with $?SELf.method and .foo with $_.foo and so on) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new mailing list: perl6-general?
On Tue, Jun 14, 2005 at 04:27:20PM +0200, Fagyal Csongor wrote: Just wanted to say the same. All my questions starting as How to... and Is this... are just to trivial to ask here :) - Fagzal I would have some general Perl6 programming questions. Where should I ask them? It's not about language design, not about compiling/compilers and even not related to the internals. Bye, Andras If you're IRC-able, then get on irc.freenode.net and join #perl6. People there are always happy to blather on about perl6 stuff that is related to pugs/perl6 development (including general perl6 programming questions). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: date and time formatting
On Tue, May 31, 2005 at 01:11:21PM -0500, Rod Adams wrote: Nathan Gray wrote: possibly as an strftime() pattern. Can we please make sure that strftime() is _not_ OS dependent like the POSIX version is now? I don't mind an OS dependent strftime() as long as we have some formatter that is OS independent. I expect that strftime() will eventually fall into disuse as people use the newer, better formatters. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: comprehensive list of perl6 rule tokens
On Sat, May 28, 2005 at 12:58:01AM -0400, Jeff 'japhy' Pinyan wrote: [ set notation for character classes ] What say you? Off the top of my head I think using and | within character classes will cause confusion. / (~(X Y) | Z | Q R) M | N / So much for the visual pill of xxx Also, character classes don't currently utilize parentheses for anything. This is a good thing as you don't have to distinguish between which parens are within assertions and which are without. Or do you proposed that even the parens within assertions should capture to $0 and friends? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: hash slice from array items
On Wed, May 25, 2005 at 05:00:39PM +0100, Carl Franks wrote: Is [EMAIL PROTECTED] the correct way to get a hash slice using elements of an array? Yep. (it's giving me a compilation error with pugs) Works just fine for me. What version of pugs are you using? Perhaps you need to upgrade. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl development server
On Tue, May 24, 2005 at 12:12:57PM +0200, Juerd wrote: Unfortunately, onion is already taken by another important Perl server: onion.perl.org. I'm currently considering 'ui', which is Dutch for 'onion'. I bet almost nobody here knows how to pronounce ui ;) What about another herb like garlic? Throw in some meat and vegetables and we've got a good stew going :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl development server
On Tue, May 24, 2005 at 06:16:06PM +0300, wolverian wrote: On Tue, May 24, 2005 at 03:44:43PM +0200, Juerd wrote: But I like the newly suggested feather better, as it can relate to pugs AND parrot. Feather is best one thus far, I think. I like carrot too; it's more playful. I equate Pugs with fun a lot. I think carrot is nice too. Only it makes me wonder where the stick is :) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: comprehensive list of perl6 rule tokens
On Tue, May 24, 2005 at 08:25:03PM -0400, Jeff 'japhy' Pinyan wrote: http://japhy.perlmonk.org/perl6/rules.txt That looks completish to me. (At least I didn't think, hey! where's such and such?) One thing that I noticed and had to look up was -prop X though. Because ... The part which needs a bit of clarification right now, in my opinion, is character classes. From what I can gather, these are character classes: [a-z] +digit +alpha -[aeiouAEIOU] I believe that Larry blessed Pm's idea to allow [a..z]+digit +alpha-[aeiouAEIOU] which implies to me that assertions starting with one of [, - or + should be treated as character classes. This doesn't seem to play well with -prop X. Maybe it does though. Also, I think that it's [a..z] now rather than [a-z] but I'm not entirely sure. At least that's how PGE implements it. but I want to be sure. I'm also curious about whitespace. Is [ one token, or can I write [a-z] and have it be a character class? I think you need to write [ -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Nested captures
On Tue, May 17, 2005 at 03:02:12PM -0400, Mark Reed wrote: On 2005-05-17 14:14, Peter Haworth [EMAIL PROTECTED] wrote:\ Does numbering of captures after an alternation continue as if the alternative with the most captures matched? # $1$1 $2$3, even if (a) matched rx/ [ (a) | (b) (c) ] (d) /; I thought that was still like Perl5: # $1$2 $3$4 rx/ [ (a) | (b) (c) ] (d) /; The *numbering* is based on the regex; the *values* are based on the actual match. Nope. See the section entitled Subpattern numbering in http://groups-beta.google.com/group/perl.perl6.language/msg/2a4b1117301c62b4?hl=en To quote: Specifically, there are significant advantages to numbering the subpatterns in each branch of an alternation (i.e. oneither side of a C|) independently, restarting the numbering at the beginning of each branch. And this is precisely what Perl 6 does: # Perl 6... # $1 $2$3 $4$5 $6 $tune_up6 = rx/ (don't) (ray) (me) (for) (solar tea), (d'oh!) # $1 $2 $3$4$5 | (every) (green) (BEM) (devours) (faces) /; In other words, unlike in Perl 5, in Perl 6 $1 doesn't represent the capture made by the first subpattern that appears in the rule; it represents the capture made by the first subpattern of whichever alternative actually matched. Although last I heard, Larry had agreed to make the first captured paren be $0 rather than $1 so that it could correspond to the indexing of the match object when used as an array. What's changed in the Perl6 design, AIUI, is nested captures. Given this: rx/ (a (b (c d) e) f) / In Perl5, $1 is abcdef, $2 is bcde, and $3 is cd. In the proposed Perl6 model, there is no $2, just $1 (an object which stringifies to abcdef, $1.1 (an object which stringifies to bcde), and $1.1.1 (an object which stringifies to cd. Yep. Assuming the $1.1 syntax works. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Plethora of operators
On Sat, May 14, 2005 at 10:56:29PM +1000, Damian Conway wrote:
3. To drill down a hierarchical data structure, following the path
specified by a list of keys:
$leaf_value = [.{}] %hash, @keys;
I think this one needs to be written as:
$leaf_value = [.{}] \%hash, @keys;
But, assuming the given syntax does the right thing, the description
reads as though this generates something akin to:
$leaf = %hash.{$k1}.{$k2}.{$k3}...{$kN}
Does this really work?
if $sum = [+] 1,2,3,4
is the same as $sum = 1 + 2 + 3 + 4
Then surely $leaf = [.{}] %hash, $k1, $k2, $k3
is the same as $leaf = %hash .{} $k1 .{} $k2 .{} $k3
And %hash .{} $key doesn't make sense to me. What am I missing? It seems
to me that would have to be written as
$leaf_value = [$^a.{$^b}] %hash, @keys;
in order to work properly (still assuming the %hash doesn't need the \
that I think it does)
Personally I think a metaoperator with that many uses is more than
Swiss-Army enough to be in the core of Perl 6.
Indeed! :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Plethora of operators
On Sat, May 14, 2005 at 05:05:10PM +0200, Juerd wrote:
Jonathan Scott Duff skribis 2005-05-14 9:49 (-0500):
Then surely $leaf = [.{}] %hash, $k1, $k2, $k3
is the same as $leaf = %hash .{} $k1 .{} $k2 .{} $k3
Then perhaps the easy way out is to make .{} $key and .[] $index valid
syntax.
Not easy on my eyes or brain :)
$leaf_value = [$^a.{$^b}] %hash, @keys;
Once arbitrary expressions are valid in [], its purpose is lost as a
meta-operator. You can write the above with normal reduce:
Oh I agree. I was just trying to make sense of [.{}] in understandable
terms because I currently just don't understand it :-)
But perhaps the reduce operator is some of that sufficiently advanced
technology that knows how the operator it wraps is slotted and does
something appropriate.
Also, does the reduction operator have the same magic as its alphabetic
twin such that it can pull N things at a time from the list for
operators that require N operands?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Plethora of operators
On Sat, May 14, 2005 at 09:20:21AM -0700, Larry Wall wrote:
On Sat, May 14, 2005 at 10:55:43AM -0500, Jonathan Scott Duff wrote:
: But perhaps the reduce operator is some of that sufficiently advanced
: technology that knows how the operator it wraps is slotted and does
: something appropriate.
Possibly. Or we just define infix .{}. and .[]. variants, or some such.
It's funny what a big difference that extra character makes. As much
as I disliked Juerd's idea to make infix .{} work, I wouldn't mind an
infix .{}. operator.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: junctions vs English negatives.
On Sat, May 14, 2005 at 09:31:29AM -0700, Larry Wall wrote: I don't think we can allow this situation to stand. Either we have to make != and !~ and ne transform themselves via not raising, or we have to disallow negative comparisons on junctions entirely. I'm of the opinion that disallowing negative comparison on junctions is the best way to go. If I were better at this forensics stuff, I'd have a cogent argument to backup my position, but as it is all I can think of right now is this: if we make != comparison illegal on junctions, perl can give the programmer a helpful message when they forget whereas the other way, they just get unexpected behavior if they forget that != does something different than usual. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: split /(..)*/, 1234567890
On Thu, May 12, 2005 at 06:29:49PM +0200, TSa (Thomas Sandlaß) wrote:
Autrijus Tang wrote:
I don't know, I didn't invent that! :-)
$ perl -le 'print join ,, split /(..)/, 123'
,12,3
Hmm,
perl -le 'print join ,, split /(..)/, 112233445566'
,11,,22,,33,,44,,55,,66
For longer strings it makes every other match an empt string.
Not quite. The matching part are the strings 11, 22, 33, etc.
And since what matches is what we're splitting on, we get the empty
string between pairs of characters (including the leading empty
string).The only reason you're getting the string that was matched
in the output is because that's what you've asked split to do by
placing parens around the pattern. (Type perldoc -f split at your
command prompt and read all about it)
To bring this back to perl6, autrijus' original query was regarding
$ pugs -e 'say join ,, split /(..)*/, 1234567890'
which currently generates a list of ('','12','34','56','78','90')
In perl5 it would generate a list of ('','90') because only the last
pair of characters matched is kept (such is the nature of quantifiers
applied to capturing parens). But in perl6 quantified captures put all
of the matches into an array such that abcdef ~~ /(..)*/ will make
$0 = ['ab','cd','ef'].
I think that the above split should generate a list like this:
('', [ '12','34','56','78','90'])
Or, another example:
$ pugs -e 'say join ,, split /([abc])*/, xabxbxbcx'
# ('x', ['a','b'], 'x', ['b'], 'x', ['b','c'], 'x')
But that's just MHO.
With the Positions between chars interpretation the above
string is with '.' indication position:
.1.1.2.2.3.3.4.4.5.5.6.6.
0 1 2 3 4 5 6 7 8 9 1 1 1
0 1 2
There are two matches each at 0, 2, 4, 6, 8 and 10.
The empty match at the end seams to be skipped because
position 12 is after the string?
No, the empty match at the end is skipped because that's the default
behaviour of split. Preserve leading empty fields and discard empty
trailing ones.
And for odd numbers of
chars the before last position doesn't produce an empty
match:
perl -le 'print join ,, split /(..)/, 11223'
,11,,22,3
There's an empty field between the beginning of the string and 11,
there's an empty field between the 11 and the 22, and finally
there's a field at the end containing only 3
Am I the only one who finds that inconsistent?
Probably. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: C:: in rules
On Thu, May 12, 2005 at 12:53:46PM -0400, Aaron Sherman wrote: On Thu, 2005-05-12 at 10:33, Patrick R. Michaud wrote: Next on my list, S05 says It is illegal to use :: outside of an alternation, but A05 has /[:w::foo bar]/ I can't even figure out what that means. :w turns on word mode (lexically scoped per S05) and :: is a group-level commit. What are we committing exactly? Looks like a noop to me, which actually might not be so bad. However, you're right: this is an error as there are no alternations. I think the definition of :: needs to be changed slightly. You even used a phrase that isn't exactly true according to spec but would be if :: meant what I think it should mean. That phrase is :: is a group-level commit. This isn't how I read S05 (and apparently how you and others read it as well, hence your comment to Pm that there are no alternations). S05 says: Backtracking over a double colon causes the surrounding group of alternations to immediately fail: I think it should simply read: Backtracking over a double colon causes the surrounding group to immediately fail: In other words, the phrase of alternations is a red herring. which leads me to believe that :: isn't illegal here even though there's no alternation. I'd like to strike that sentence from S05. I don't think it should be removed. You can always use ::: if that's what you wanted. I too think it should be stricken. /[:w\bfoo bar]/# not exactly the same as above No, I think that's exactly the same. What does \b mean again? I assume it's no longer backspace? So, now then, on to the item that got me here in the first place. The upshot of all of the above is that rx :w /foo bar/ is not equivalent to rx /:w::foo bar/ If we feel strongly, it could be special-cased, but your null solution seems fine to me. If :: were to fail the surrounding group we can say that a rule without [] or () is an implicit group for :: purposes. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: split /(..)*/, 1234567890
On Thu, May 12, 2005 at 01:12:26PM -0400, Uri Guttman wrote:
JSD == Jonathan Scott Duff [EMAIL PROTECTED] writes:
JSD To bring this back to perl6, autrijus' original query was regarding
JSD$ pugs -e 'say join ,, split /(..)*/, 1234567890'
JSD which currently generates a list of ('','12','34','56','78','90')
JSD In perl5 it would generate a list of ('','90') because only the last
JSD pair of characters matched is kept (such is the nature of quantifiers
JSD applied to capturing parens). But in perl6 quantified captures put all
JSD of the matches into an array such that abcdef ~~ /(..)*/ will make
JSD $0 = ['ab','cd','ef'].
JSD I think that the above split should generate a list like this:
JSD('', [ '12','34','56','78','90'])
i disagree. if you want complex tree results, use a rule.
Well ... we *are* using a rule; it just doesn't have a name.
So, would you advocate too that
my @a = foofoofoobarbarbar ~~ /(foo)+ (bar)+/;
should flatten? thus @a = ('foo','foo','foo','bar','bar','bar')
rather than (['foo','foo','foo'],['bar','bar','bar]) ?
This may have even been discussed before but we should probably make
the determination as to whether or not we keep the delimiters be
something other than the presence or absense of parentheses in the
pattern. Perhaps the flattening/non-flattening behavior could be
modulated the same way. Probably as a modifier to split
split is for creating a single list of elements from a string. it is
better keep split simple for it is commonly used in this domain.
I'll wager that splits with non-capturing patterns are far and away the
most common case. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: split /(..)*/, 1234567890
On Thu, May 12, 2005 at 12:01:59PM -0700, Larry Wall wrote:
On Thu, May 12, 2005 at 12:03:55PM -0500, Jonathan Scott Duff wrote:
: I think that the above split should generate a list like this:
:
: ('', [ '12','34','56','78','90'])
Yes, though I would think of it more generally as
('', $0, '', $0, '', $0, ...)
where in this case it just happens to be
('', $0)
and $0 expands to ['12','34','56','78','90'] if you treat it as an array.
Exactly so. Principle of least surprise wins again! ;)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Numification of captured match
On Thu, May 12, 2005 at 02:55:36PM -0500, Patrick R. Michaud wrote:
On Fri, May 13, 2005 at 03:23:20AM +0800, Autrijus Tang wrote:
Is it really intended that we get into habit of writing this?
if 'localhost:80' ~~ /^(.+)\:(\d+)$/ {
my $socket = connect(~$0, +$1);
}
It looks... weird. :)
And it would have to be
if 'localhost:80' ~~ /^(.+)\:(\d+)$/ {
my $socket = connect(~$0, ~$1);
}
because +$1 still evaluates to 1.
That's some subtle evil.
My suggestion is that a match object in numeric context is the
same as evaluating its string value in a numeric context.
While I agree that this would be the right behavior it still feels
special-casey, hackish and wrong.
If, as an optimization, you could tell PGE that you didn't need Match
objects and only cared about the string results of your captures, that
might be better. For instance,
if 'localhost:80' ~~ m:s/^(.+)\:(\d+)$/ {
my $socket = connect($0, $1);
}
:s for :string (assuming that hasn't already been taken)
If
we need a way to find out the number of match repetitions (what
the numeric context was intended to provide), it might be better
done with an explicit C.matchcount method or something like that.
Surely that would just be [EMAIL PROTECTED] Or have I crossed the perl[56]
streams again?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Numification of captured match
On Thu, May 12, 2005 at 08:10:42PM -0700, Larry Wall wrote:
On Thu, May 12, 2005 at 02:55:36PM -0500, Patrick R. Michaud wrote:
: My suggestion is that a match object in numeric context is the
: same as evaluating its string value in a numeric context. If
: we need a way to find out the number of match repetitions (what
: the numeric context was intended to provide), it might be better
: done with an explicit C.matchcount method or something like that.
I think we already said something like that once some number of
months ago. +$1 simply has to be the numeric value of the match.
It's not as much of a problem as a Perl 5 programmer might think,
since ?$1 is still true even if +$1 is 0. Anyway, while we could have
a method for the .matchcount, +$1[] should work fine too. And maybe
even [EMAIL PROTECTED], presuming that a match object can function as an
array
actually means a match object knows when it's being asked to supply
an array reference.
So the counting idiom in S05 becomes one of:
$match_count += @{m:g/pattern/};
$match_count += list m:g/pattern/;
$match_count += m:g/pattern/.matchount;
$match_count += (m:g/pattern/)[]; # maybe
???
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Nested captures
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: Uri Guttman wrote: DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a DC shorthand for $/whatever. but then what about the different index bases for $42 and $/[42]? i don't think that has been resolved (nor has mixing the $1.1 and $1[1] syntaxes). Bear in mind that that reply was posted in haste, late at night, after a long day of teaching. We're lucky it as only off by one! %-) But it does raise an important point: the discrepancy between $42 and $/[41] *is* a great opportunity for off-by-on errors. Indeed. Previously, however, @Larry have tossed back and forth the possibility of using $0 as the first capture variable so that the indices of $/[0], $/[1], $/[2] match up with the names of $0, $1, $2, etc. I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... But that's only the opinion of one(@Larry), not of $Larry. My opinion too. The $digit vars should be zero-based just as the array indices are. (or, if we can come up with a plausible meaning for the zeroth index of our match arrays, keep starting at $1) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Threading in Parrot vs Perl
On Thu, Apr 28, 2005 at 12:46:53PM -0400, Aaron Sherman wrote: On Thu, 2005-04-28 at 10:00, Luke Palmer wrote: Aaron Sherman writes: Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? What? Why will it do that? Why? Well, you can read what Dan wrote, 'cause I'm sure not going to pretend I'm enough of a threads programmer to have an educated opinion: http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source We'd decided that each thread has its own interpreter. Parrot doesn't get any lighter-weight than an interpreter, since trying to have multiple threads of control share an interpreter seems to be a good way to die a horrible death. -Dan Sugalski / 14 Apr 2005 I believe these are two distinct uses of the term threading. Autothreading of junctions is orthogonal to parrot interpreter threads. Junction autothreading does *NOT* require interpreter threads. Junction autothreading just means that routines will be executed for each element of the junction (not necessarily in parallel). Someone correct me if I'm wrong. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
