Re: 12 hackers hacking...
On Thu, Dec 25, 2008 at 9:39 AM, Mark J. Reed wrote: > On Thu, Dec 25, 2008 at 12:00 PM, Patrick R. Michaud > wrote: >> On Thu, Dec 25, 2008 at 12:53:06AM -0500, Mark J. Reed wrote: >>> I also tried this, but it caused Rakudo to throw a StopIteration and >>> then segfault: >>> >>> for [...@gifts[0..$day-1]].pairs.reverse -> $n, $g >> >> The StopIteration occurs when there aren't enough elements in the >> list to supply to the parameters to the body. In the example above, >> it would occur whenever there are an odd number of pairs. > > OK, so that loops through the list in groups of two. So how do I Ioop > through a list of Pairs assigning the key to one var and the value to > another? There's apparently no L section (yet), but by inference from the various argument unpacking syntaxes, I'd predict the syntax should be: for [...@gifts[0..$day-1]] -> $ ($key => $value) { ... } - Ashley Winters
Re: Iterator semantics
On Fri, Sep 12, 2008 at 11:33 AM, Daniel Ruoso <[EMAIL PROTECTED]> wrote: > In SMOP, I'm probably going to presume that everything needs to be lazy, > then even: > > my @o = grep { /\d+/ } =$*IN; > my @a = (1,2,(3,4,@o)); > my @b = (1,2,(3,4,@a)); Can only one array "have" the iterator? If not, that makes for =$*IN { =$*IN if $needs_skipping } look like a forbidden idiom. On the other hand, if it's really really lazy, then I could run the following two statements without reading anything out of the iterator my @digitlike = grep { /\d+/ } =$*IN; my @hexlike = grep { /+/ } =$*IN; But, if the taking of an iterator causes the array to autoactualize (made this word up to parallel autovivify), what happens to the other lazy array? Does the iterator buffer its contents to be served up to other readers, or is the $iterator.next function first-come-first-serve? Or is there some possible "batching" behavior that allows one of the iterators to gobble more than is used? given a non-deterministic iterator which would return <1 2 3 a b c 5 6 7 d e f 8 9 0> say @digitlike[0..4]; say @hexlike[0..4]; # what's this? <1 2 3 a b> or <7 d e f 8> or <> or undefined behavior? In the event you picked <1 2 3 a b>, when did the @hexlike grep block get called? - Ashley Winters
Re: Patterns
On 1/5/07, Larry Wall <[EMAIL PROTECTED]> wrote: Anyway, that gives us: given $pattern { when .accepts(42) {...} } I think this type of usage should be encouraged with a bit more huffmanization. My first thought would be to add C to invert the arguments to ~~ versus C. given @something { when $this { ... }# @something ~~ $this against $that { ... }# $that ~~ @something } That would help keep the ~~ DWIM table from trying to guess on which side you really wanted @something on. - Ashley Winters
Re: Nitpick my Perl6 - parametric roles
On 9/25/06, Miroslav Silovic <[EMAIL PROTECTED]> wrote: TSa wrote: > > > role Set[::T = Item] does Collection[T] where { > > all(.members) =:= one(.members); > > }; > > Nice usage of junctions! > But buggy - one means *exactly* one. So for an array of more than 1 element, all(@array) never equals one(@array) - if they're all the same, it's more than 1, otherwise it's 0. Yeah, that would've been cool. Are we left with asserting C? That'd be pretty close to the original elegance. Ashley Winters
Re: underscores in the core lib
On 8/6/06, Yuval Kogman <[EMAIL PROTECTED]> wrote: Hi, Audrey mentioned that Perl 6 is trying to avoid underscores in the core library. It came up when I asked why "valid" isn't called "value_id" because if ( $user_input.valid ) { } reads fairly confusingly. So, a few questions: 1. what is the "official" naming style for the Pelr 6 standard library (not just functions, but methods for core objects, the MOP, the compiler toolchain, the truely absolutely core modules, etc). 2. What is bad about underscores? From what I know most people tend to think that $object.do_that_action is the clearest way of naming methods, and the technical reasons to avoid these (long symbol names, lots of typing) are no longer really valid nowadays (with editor autocompletion, etc). Nothing is wrong with underscores. In fact, under_scores and camelCase/StudlyCaps should be encouraged I. When you see function_name() or functionName() or _functionname(), it should be obvious to any Perl programmer that it's *not* a standard Perl function -- it's a user/module function. When you see SCARYCAPS, you should expect out-of-band implicit (action-at-a-distance) behaviour from whatever code it in it. Think of underscores and caps as a form of twigil. $scalar, @array, %hash, &sub, &_internal, &userFunction, &user_function, &RefugeeWindowsProgrammer, &Let_There_Be_Poetry, &MAGIC, &UNAUTHORIZED_USER_MAGIC. And, just like $scalars can hold arrays, &somesub could be a standard function or a user function (or a standard function which a user reimplemented -- you never know). - Ashley Winters
Re: Synchronized / Thread syntax in Perl 6
On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote: Though if that works, you could squish this example even more, to class QueueRunner { our sub process_queue(Code @jobs_in) { map { async { &_() } } @jobs_in; } }# end QueueRunner # Elsewhere... my @answer = QueueRunner.process_job_queue( @jobs ); and the issues of serialization are hidden in the map() call. For all that my @answer = map { async { &_() } } @jobs; though that gets away from the point. Someone smack me if I'm drifting too far here? That still seems too explicit. I thought we had hyperoperators to implictly parallelize for us: my @answer = @jobs.»(); Which would run them in parallel automatically, if possible. - Ashley Winters
Re: overloading the variable declaration process
On 2/6/06, Larry Wall <[EMAIL PROTECTED]> wrote: > So the basic answer to you question is, I think, yes. If Dog chooses > to always return true for .defined, then (in Haskell terms) it's more > like a Just type than a Maybe type. Perl 6's objects like to be Maybe > types by default, but you can override it. (I'm using the Haskell > terms loosely here, of course.) But the very concept of definedness > is getting mushy in Perl 6. What we need is more concepts of the > form "Is this *sufficiently* defined for what I want to do with it?" > That's why I proposed "defined according to a particular role" as > one way to ask that sort of question. So, if ^Dog describes a Dog which defines a $dog, do we need an undescribed() function? Just kidding... kinda. Ashley Winters
Re: handling undef better
On 12/17/05, Sebastian <[EMAIL PROTECTED]> wrote: > > Obviously there are mixed opinions of how undef should be treated and > some won't be happy with what becomes final, so implementing some > intelligent defaults and simple pragmas, but not excluding the ability > to *really* control your undefs, sounds like a win-win. If we want to have our cake and eat it too, let's create a new value: nil. my $dog = nil; ok !$dog; ok $dog eq ''; ok $dog ne 'foo'; ok $dog == 0; ok $dog != any(1..100); ok $dog === nil; ok ++$dog == 1; ok not $dog === nil; Explicitly nil values wouldn't warn or fail on activities which undef does. nil is basically a value which is simultaneously '' and 0 and 0.0 and false *and* defined, and allows itself to be coerced with the same rules as perl5 undef, but without an 'uninitialized' warning. Uninitialized variables would remain undef, and would have Larry's unthrown-exception failure rule. The nil value is completely defined as above. And, huffmanly speaking, most people who want to explicitly initialize a variable to an empty state are going to want nil, not undef. C is redundant, after all -- as is C<$var // undef>. When used as a value, undef returns C or something. Thus completes the circle of definedness. Ashley Winters
Ways to add behavior
I'm mentally going over the ways to do it. class Foo; # the perl5 way use base <>; sub new { my $class = shift; my $self = $class.SUPER::new(@_); # syntax? return $self; } sub do_it { my($self, $arg) = @_; say "doing $arg!"; } class Foo is Base { # the perl6 way method do_it(String $arg) { say "doing $arg!"; } } # add behavior through multi-dispatch multi sub do_it(Base $x, String $arg) { say "doing $arg!"; } # behavior via mixin my Base $x does role { method do_it($arg) { say "doing $arg!"; } }; # behavior through prototype -- guessing realistic syntax Base.meta.add_method( do_it => method ($arg) { say "doing $arg!"; }); # or, just add it to a single instance $x.meta.add_method( do_it => method ($arg) { say "doing $arg!"; }); Did I miss any good ones? Or bad ones? :) Ashley Winters
Re: Type annotations
On 10/6/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > So we're in line one of a Perl program, with static typing/inference > disabled (or at least inference *checking* disabled; perl may still > use it for optimization). When do the following die: compile time > (which includes CHECK time), run time, or never? This is just my opinions as a Perl programmer in the trenches. I would expect Typed variables to auto-coerce themselves, but not impose fatality. Predictable auto-coercion would be nifty in quick-and-dirty programs. Ignore my advice at will -- nobody's required to use Types in their own code, so there's no need for them to be universally valuable. However, since I expect builtins and all standard functions to have fully declared Type signatures, consider how these decisions would affect _every_ program, before ordering the summary execution of everyone's poor little Perl script. > my Array $a = 97; # dies eventually, but when? Runtime -- cannot coerce Int value to Array > my Int $b = 3.1415; # dies at all? Doesn't die, $b == 3. Int scalars should coerce anything which can be &prefix:<+>'d. > sub foo (Int $arg) {...} > foo("hello"); # should die at the latest when foo() is called $arg should be undef but Exception::InvalidInteger("Str value 'hello' cannot be coerced to an Int at $?LINE") > sub bar (Int $arg --> Str) {...} > foo(bar(42)); If bar returns a Str ~~ //, it gets coerced; otherwise, undef but Exception > sub static (Code $code, Array $elems --> Array) { > [ $elems.map:{ $code($_) } ] > } > sub dynamic ($code, $elems) { > [ $elems.map:{ $code($_) } ] > } > static({ $_+1 }, dynamic("notcode", [1,2,3,4,5])); die "Str value 'notcode' cannot be called as a Sub reference -- have you asked Larry how to make a symbolic function call, lately?"; > dynamic("notcode", static({ $_+1 }, [1,2,3,4,5])); Same. Just my 2¢ Ashley Winters
Re: numification and stringification of objects
On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote: > Whenever possible, object should have useful numeric and string > representations. These are generally lossy, but this is not a problem, because > a scalar stays a scalar even after being used in a certain context, and the > object isn't lost. Sounds good. Let me summarize what I've gleaned so far, in the context of what I was looking for: Presentation: $object.as(Str, ...) where ... is a format string; perhaps an sprintf format, or something else. Localization occurs here. Formatting occurs here. Timezone/newline-convention/join-character-specification/whatever happens here Representation: ~$object eq $object.as(Str) eq DWIMiest string Presentation Serialization: my Thingy $obj.=thaw($object.freeze) Interpolation: "foo $object" eq "foo " ~ ~$object This makes sense, and I can accept it. I still think the proposed Representation behavior should really be the Interpolation behavior, and Representation should be a lossless but readable version of Serialization, though I'm clearly wrong, since I can't defend it. No worries. I'll come around to see the light. Someday. :) Ashley Winters
Re: Allomopherencing
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > In order to enforce that level of compile-time type safely, you should > > need to declare my Dog $dog, or stick a pragma up top: > > That's the point of my question - why? What do I lose by > inferrencing? Nothing that I see. I recant my arguments when strict inferencing is in place. That's exactly how I'd want it to work when optimization and/or stricture is in place. It'd be a *very* nice compiler feature. Ashley Winters
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On 9/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote: > > We can do better than equivalence testing for colors. Instead, try to > > match. Surely a *smart* match operator really is smart? > > > > $color ~~ '#FF00FF' > >== > > $color ~~ 'magenta' > >== > > $color ~~ [ 255, 0, 255 ] > > Hmm. That violates my proposal that the right side is the thing that > determines how the left side is matched. So there's something wrong > with one of the two... > > If we keep my proposal, then we get: > > $color ~~ color('#FF00FF') > $color ~~ color('magenta') Interesting proposal. Is there any motivation for people not to simply flip the argument-order to take advantage of the right-wise determinism? Or is that actually a benefit? '#F0F' ~~ $color ?? 'yes' !! 'no'; Ashley Winters
Re: Stringification, numification, and booleanification of pairs
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote: > > > The Stringification of a UnixEpochTimestamp should probably be the > > same as its Integerization -- 12345678900. However, the Interpolation > > of it should be the locale-specific POSIX-style datetime string. > > Why? What value does the stringification of a date have as a > stringified integer? If we were to implement such semantics, > wouldn't it be wiser to print "The time in seconds since the epoch > is { +$time }"? That's much more readable, obvious and > nonsurprising, without being overly long or tedious. It's not a Date, it's a UnixEpochTimestamp. I'm choosing my classes for maximum expositive effect, and in this case a UnixEpochTimestamp is explicitly defined as number-of-non-leap-seconds-since-1970. You probably need to either .strftime(), .posix_localtime(), posix_gmtime() or .as(Perl6::Time) to get a proper formatting. > > Here's how I would do it if $Ashley == any(@Larry) > > You mean eqv.. =( Ouch. You're right, but that's a painful adjustment. > > The .as(Str) of an object would be its serialization > > as is formatting, not serialization: > > $time.as('%d'); > > or something... I don't really know how this works > > For serialization you have the .perl method, which is roughly the > same as Data::Dumper (code to be evaled), or some more heavy duty > package (i expect Storable to have a pretty consistent interface). Yes, .perl, .json, .xml, .repr, whatever. > > > my Thingy $foo .=from($thing); > > my Thingy $foo = eval($thing.perl); This should really really really be discouraged and/or prevented. This will be a Perl6 Worst Practice in short order. Please, consider: my Thingy $foo = eval:data $thing.perl or eval:json $thing.json or eval:xml $thig.xml eval() itself feels like the wrong function for doing this. I'm trying to parse(), not eval(). But, I digress... > > The Interpolate role's method would return the pretty-printed, > > possibly LOSSY presentation of the object's information. > > Uhuh, which is a flawed concept, because whose to decide what should > be lost? why does the perl prelude have to decide what's valueable > and what can be lost during *stringification or interpolation* now, > when this language is supposed to live for another 20 years? In Perl5, stringified NVs are only printed to however many digits Perl thinks are worth printing. At the extreme range, it decides to print with scientific notation. That is done for the convenience for interpolation into an output string -- the real decimal representation could be 0.002378462387462341220983458672348961234 I'm not necessarily arguing this is the right or the best dividing line, but I'm saying a line can be drawn if we want. > > For example: > > > > my $color = new HTML::Color("magenta"); > > if $color.as(Str) eq '#FF00FF' and "$color" eq "magenta" { > > $Ashley++; > > } > > $color.hex_triplet; # no alpha > $color.name; # if we have one... or we can try to make one up (#ff0033 is > bluish red ;-) > > I see no reason why these two should behave in anyway, except that > one of them is the canonical format. There is no mnemonic device > whatsoever to link interpolation to color naming, and > stringification to hexadecimal representation. > > Why isn't the str method "(255,0,255)"? Why isn't interpolation more > expressive and "Dwimmy"? I chose this class for expositive purposes as well. It's the canonical representation of a color in HTML -- 6 digit hex. The DWIM factor comes from printing what the object thinks its own value is. A UnixEpochTimestamp thinks of itself as seconds-since-1970. An HTML color thinks of itself as whatever you passed to its constructor, whether that was #A4c or MaGeNtA or #ff say "The Unix Epoch Timestamp is $time" --> The Unix Epoch Timestamp is 1234567890 say "The HTML Color is $color" --> The HTML Color is magenta > > So, to summarize, I want .as(Str) to be the lossless canonical > > representation, as well as the basis for the default .hash method, > > while Interpolate would be the pretty-printed localized lossy > > presentation Role. > > For localization we need another thing. I propose a new prefix > operator, with some funny char we haven't used yet. It would be a > part of the Localizable role, and it would return a Str. I'm not attached to the name or the function. I want something for presentation that's different from representation that's different from serialization and I want them to be easy and safe, and I want to know which one will be used to hash my object by default. :) Ashley Winters
Re: Allomopherencing
On 9/25/05, Ashley Winters <[EMAIL PROTECTED]> wrote: > On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > Under strict type inferrencing, i'd expect this to be a compile time > > error: I quoted but didn't read close enough. You DID say strict type inferencing. Never mind. :) Ashley Winters
Re: Allomopherencing
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > Hmm... Making up these subjects is fun =) Very interesting. :) > Under strict type inferrencing, i'd expect this to be a compile time > error: > > my $dog = Dog.new; > > if ($condition) { > my Cat $c = $dog; > } else { > ... > } > > since it's guaranteed to be a runtime error if $condition is ever > true. I can't accept that. While you can infer that $dog will be a Dog at that line of code, it isn't being enforced, which means no compile-time error. $dog is allowed to store any kind of data, and you only know what methods exist in Dog at compile-time. After all, I was planning to add a &Dog::as(Cat) method at runtime. Yes, I'm a mad scientist. Muahahaha!!! In order to enforce that level of compile-time type safely, you should need to declare my Dog $dog, or stick a pragma up top: use sadistic ; either of those declarations can disregard my potential for runtime tomfoolery, and abort the compiliation when there's something illogical. Ashley Winters
Re: Stringification, numification, and booleanification of pairs
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote: > > Damian Conway skribis 2005-09-24 8:31 (+1000): > > > >In my opinion, making the string value in interpolation different from > > > >the value in Str context is madness. > > > It's dwimmery. > > > > It's dwymmery, or dwdmmery indeed. Not at all what I mean, am likely to > > mean, or will ever mean. > > > > > Which often looks like madness until you realize that it's just a > > > reflection of how most hackers think. ;-) > > > > This calls for a poll, because I believe nothing of this "most". > > > > Hackers on this list, what do you think? > > [...snip...] > > On top of that there is the fact that perl 5 people come to expect > that ("$foo") means ("".$foo), except that the first version is > easier to read. Yes, that's how I explain it to anyone who really needs to know, which is usually to someone asking about overloading. However, I see a useful difference between Str[ingification] and 'does Interpolate' or whatever that role might be. However, the names might want to change to protect the innocent. The Stringification of a UnixEpochTimestamp should probably be the same as its Integerization -- 12345678900. However, the Interpolation of it should be the locale-specific POSIX-style datetime string. Here's how I would do it if $Ashley == any(@Larry) The .as(Str) of an object would be its serialization -- what you would spit out for the Perl6 version of pickle/Storable/whatnot. Ideally, the Str representation would be lossless, informationally, so you could call the deserialize/unpickle (.from?) method using its return-value: my Thingy $foo .=from($thing); The Interpolate role's method would return the pretty-printed, possibly LOSSY presentation of the object's information. For example: my $color = new HTML::Color("magenta"); if $color.as(Str) eq '#FF00FF' and "$color" eq "magenta" { $Ashley++; } So, to summarize, I want .as(Str) to be the lossless canonical representation, as well as the basis for the default .hash method, while Interpolate would be the pretty-printed localized lossy presentation Role. Ashley Winters
Re: Proposal: split ternary ?? :: into binary ?? and //
On 9/5/05, Damian Conway <[EMAIL PROTECTED]> wrote: > Patrick suggested: > > > At OSCON I was also thinking that it'd be really nice to get rid of > > the :: in the ternary and it occurred to me that perhaps we could use > > something like '?:' as the 'else' token instead: > > > >(cond) ?? (if_true) ?: (if_false) > > > > However, I'll freely admit that I hadn't investigated much further > > to see if this might cause other syntax ambiguities. > > I think the main problem there would be the *visual* similarity > between the two. Indeed. The "logical" (bad pun intended) operator to match with ?? is !! (cond) ?? (if_true) !! (if_false) Ashley Winters
Re: @array = $scalar
On 8/31/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote: > Hi, > > @array = $scalar;# really means > @array = ($scalar,); # same as If list construction is via the &infix:<,> operator, does that mean a blasphemous sinner could create &infix:<,=> as a synonym for push? @array ,= $foo ; @array = @array, $foo; Ashley Winters
Re: my $pi is constant = 3;
On 8/11/05, Larry Wall <[EMAIL PROTECTED]> wrote: > So either we have to bifurcate the concept into "temporarily constant" > and "permanently constant", or we force people to distinguish with ::= > (or "is constant('foo')"), or we make some representations about the > requirement for the compiler to optimize the = form to: > > my Str $x is constant('foo'); Why isn't the late binding version my Str $x is ro('foo'); In contrast to the 'is rw' trait? When I say 'is constant', can I be rewarded for all my extra typing with some well-defined compile-time optimization? Ashley Winters
Re: Transparent / Opaque references
On 5/27/05, Juerd <[EMAIL PROTECTED]> wrote: > > There is no way to get an anonymous rw scalar, is there? Can't the [] and {} syntaxes be considered aliases for new Array(...) and new Hash(...)? my $x := new int = 10; # looks like it should work Ashley Winters
Re: junctions vs English negatives.
On 5/15/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > multi sub infix: (Any|Junction $a, Any|Junction $b) { > !($a == $b); > } > > Then it Just Works. Also, that's the right way to provide a working != for any object which defines ==. We all want that, right? Ashley Winters
Re: ./method
On 5/15/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: > On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote: > > I suggest > > ./method > > to mean $?SELF.method Sounds good. > class Person is Mortal { > has Weapon %.weapons; > ... > method battle_choice (Monster $enemy) { > given prompt("Your choice?") { > when %.weapons { > ./attack($enemy, $.weapons{$_}); > } > } Looks good, too. It's convenient enough to encourage me to use it consistently. Even when $_ points at the invocant, I'd be strongly inclined to use ./method for $self.method. After a decade of using unix shells, typing ./ is closer to huffman(1.1) than huffman(2). This is a really clean solution. Ashley Winters :vote
Re: adverbial blocks: description and examples requested
On 5/5/05, Terrence Brannon <[EMAIL PROTECTED]> wrote: > I was looking at a line in the hangman program: > > @letters == @solution.grep:{ $_ ne '' }; > > and was told that I was looking at an adverbial block. > > But I don't understand what that is and could not find a description > and examples in a reverse search on dev and nntp.perl.org. Methods with arguments require parens. However, the block to grep isn't I an argument. It's describing the manner in which the array will be grepped... that's an adverb to grep. So, why are the parens required on methods? Take the following if statements: if @foo.shift { ... } if @foo.grep { ... } # grep doesn't get the block To make things clear, methods without parens are assumed to take no arguments. In order to pass a block to the above grep, you either need to use @foo.grep({ $^a <=> $^b}) or the adverbial colon: if @foo.grep:{$^a <=> $^b} { ... } Ashley Winters
Re: Truely temporary variables
On 4/15/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > Aaron Sherman <[EMAIL PROTECTED]> wrote: > > What I'd really like to say is: > > > > throwawaytmpvar $sql = q{...}; > > throwawaytmpvar $sql = q{...}; > > Anything wrong with: > >my $sql = q{...}; >temp $sql = q{...}; >temp $sql = q{...}; > > (Assuming C is made to work on lexicals, of course.) How about 'the'? I don't want to I the variable, I just want to use it. the $sql = q{...}; the $sth = $dbh.prepare($sql); It could be the same as my(), but without the posessiveness (warning) Ashley Winters
Re: <[]> ugly and hard to type
On 4/15/05, Juerd <[EMAIL PROTECTED]> wrote: > Am I the only one who thinks <[a-z]> is ugly and hard to type because of > the nested brackets? The same goes for <{...}>. The latter can't easily > be fixed, I think, but the former perhaps can. If there are more who > think it needs to, that is. And <{}> is a bit easier to type because all > four are shifted (US QWERTY and US Dvorak), while with <[]> I really > have to think hard about when to press and when to release the shift > key. I never liked character sets. They introduced yet another exception to the parsing rules, and it irked me. If it weren't for the need to optimize character sets, I'd prefer to be Pythonized into using @{'a' .. 'z'} If I read the Apocalypses correctly, I'm allowed to use this bizzare construct: $foo ~~ /@{< [ ] { } < > : ++ $ . ? / +| +& ?| ?& >}/ to match some of my favorite punctuations, right? It allows multi-character alternatives as well as the single-character ones, so it seems preferable to me (assuming it could be optimized happily). Ashley Winters
Re: Documentary annotations: $what doc
Chip Salzenberg writes: > I'd like to annotate Perl 6 parameters and other entities using > traits, since that's the best way (I know of) to have them appear > immediately in the text of the program where they are. > > Supposing I had a "doc" trait, could I say: > > sub f2c (Num $temp doc) > doc > {...} > > Or would I be forced to spell it doc('stuff') ? Perhaps you spell it 'annotated' and add a few shortcuts? Num $temp is annotated('Temperature in degrees F') Num @temp is an('Array of temperatures in degrees F') Dog $spot is a('Good Dog!') Ashley Winters
Perl6 Rule library (was: New S29 draft up)
On Fri, 18 Mar 2005 00:20:57 -0500, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > > LW> oct and hex are arguably misnamed, since most functions are named by > LW> what they produce, not by what they take as input. I don't know what > LW> the replacement should be, though. Maybe it's not worth fixing. > > from_oct, from_hex which state what they do? or a more general > from_base( 16, $hex )? and that could be curried into from_hex(). Isn't that actually part of the Standard Perl6 Rule Library? class Perl6::Rules { our @HexDigits = 0..9, 'a'..'f'; our @OctDigits = 0..7; our @DecimalDigits = 0..9; rule ParseNumber(@digits) returns Int { :i [0x]? [$digit := <@digits> { $0 *= @digits.elems; $0 += @digits.indexof($digit) }]+ } &ParseHex := &ParseNumber.assuming :digits(@HexDigits); } with &*hex being some sort of alias to Perl6::Rules::ParseHex? Umm... can you call a rule as a function? rule foo { .* } $x = foo("I am the very model of a modern irregular expression"); Or do I not want to know the answer to that? Ashley Winters
Re: The S29 Functions Project
On Sun, 13 Mar 2005 23:42:41 -0600, Rod Adams <[EMAIL PROTECTED]> wrote: > Ashley Winters wrote: > >For documentary purposes, can we make that $radians? > > > >multi sub cos (Num +$degrees) returns Num { > >return cos :radians($degrees * PI / 180); > >} > > > >my Num $x = cos :degrees(270); > > > I have changed the trig functions it to have an optional "base" > argument. (I'm option to new names for this term.) > > The problem I see with your proposal is that both versions have the same > MMD long name, which only looks at required parameters. We'd have to > have something like: > > multi sub cos (Num ?$radians = $CALLER:_, Num +$degrees, Num > +$gradians) returns Num This seems like a poor limitation in practice. I wasn't even proposing having that degrees version be in the standard library -- I offered that function as an example implementation to put in my own degree-using programs.. Don't get me wrong, I like having degrees/gradians as an option in the standard language, but how should I do what I proposed in other cases, when the option isn't included in the standard implementation? As for the duplicate long names, don't we have permissive foot-shooting? We get "is default" as a tie-breaker in the end, no? Hell, I seem to recall seeing example functions whose signatures vary by a "where" or "when" or some such clause. multi sub foo (Int $x where { $_ ~~ any(1..10) }) multi sub foo (Int $x where { $_ ~~ any(5..15) }) is default Ashley
Re: The S29 Functions Project
On Sun, 13 Mar 2005 18:03:20 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > On Sun, Mar 13, 2005 at 01:15:52AM -0600, Rod Adams wrote: > > : =item multi sub cos (?Num) returns Num > : > : =item multi method Num::cos () returns Num > > It would be nice if we could just say the first implies the second. > I guess what that effectively means is that even if you take the > default, it's only the value that's optional, not the type. And, > in fact, you'd have to put the ? on the variable, not on the type, > so you might write those > > =item multi sub cos (Num ?$n = $CALLER::_) returns Num > > instead. Shall we settle on $x, $y, $z for standard Num args? In which > case that becomes > > =item multi sub cos (Num ?$x = $CALLER::_) returns Num For documentary purposes, can we make that $radians? multi sub cos (Num +$degrees) returns Num { return cos :radians($degrees * PI / 180); } my Num $x = cos :degrees(270); Ashley Winters
Set sigils (was: Re: Junction Values)
On Sat, 19 Feb 2005 15:20:59 -0600, Rod Adams <[EMAIL PROTECTED]> wrote: > Positions I still stand by: > > - Sets belong in the language, and need more support. This can likely be > done at the module level, but I'd like them better incorporated, > preferably with their own sigil. However, I believe they can peacefully > coexist with Junctions, and one concept does not need to crowd out the > other. Instead of primary sigils, what about secondary sigils on an array to mark it as an unordered set? @|foo = any @&foo = all @^foo = one # can arrays be curried arguments? hmm @!foo = none After all, why should scalars get all the good secondary sigils? :) Ashley Winters
Re: Junction Values
On Fri, 18 Feb 2005 14:35:53 -0800, Ashley Winters <[EMAIL PROTECTED]> wrote: > 1 .. sqrt(10) -> LazyList of (1..3) > 1 .. sqrt(10|20) -> Junction of any(1,2,3, 1,2,3,4) > > LazyList does Iterator, but Junction does not. You'd have to use (1 .. > sqrt(3|6)).values to iterate through the possible values > semi-randomly. Okay, changed my mind again. 1 .. sqrt(10|20) -> Junction of any(1,2,3, 1,2,3,4) therefore, for(1 .. sqrt(10|20)) iterates ONCE, but $_ is a junction. Anything inside the loop which uses $_ would autothread. Anything which doesn't use $_ would only get called once. That's insane, right? for(1 .. sqrt(10|20) { if($_ > 2) {}# uses junctive value say "Here"; # called once bar($_); # calls bar() lots of times } > More likely, I'm nuts. I'm definitely crazy. I give up! I'll stop now, since I clearly don't get it. :) Ashley Winters
Re: Junction Values
On Fri, 18 Feb 2005 23:12:40 +0100, Eirik Berg Hanssen <[EMAIL PROTECTED]> wrote: > Ashley Winters <[EMAIL PROTECTED]> writes: > > > On Fri, 18 Feb 2005 12:47:51 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > >> Run through your mind how this would be done with a junction in $x. > >> Particularly focus on: > >> > >> 2..sqrt($x) > >> > >> What the hell does that mean? Do you get a junction of lists out? Or > >> does sqrt die because it's not expecting a junction? > > > > sqrt() won't die; it gets threaded and returns a Junction, I would > > expect. It's the lack of an &*infix:<..>(Int, Junction) function which > > causes death > > Why does that cause death instead of authothreading? Okay, I changed my mind. I think it does it does work for ~~ matching, but not as an iterator given 2 { when 1 .. sqrt(3|6) { ... }# would work } for(1 .. sqrt(3|6)) { ... } # would fail, since Junction doesn't "do Iterator" or whatever 1 .. sqrt(10) -> LazyList of (1..3) 1 .. sqrt(10|20) -> Junction of any(1,2,3, 1,2,3,4) LazyList does Iterator, but Junction does not. You'd have to use (1 .. sqrt(3|6)).values to iterate through the possible values semi-randomly. More likely, I'm nuts. Ashley
Re: Junction Values
On Fri, 18 Feb 2005 12:47:51 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > Run through your mind how this would be done with a junction in $x. > Particularly focus on: > > 2..sqrt($x) > > What the hell does that mean? Do you get a junction of lists out? Or > does sqrt die because it's not expecting a junction? sqrt() won't die; it gets threaded and returns a Junction, I would expect. It's the lack of an &*infix:<..>(Int, Junction) function which causes death I suppose you could write one which would pick a random value: multi sub *infix:<..>(Int $x, Junction $y) { return $x .. first { .does(Int) } $y.values; } Ashley Winters
Re: Junction Values
On Wed, 16 Feb 2005 14:29:14 -0600, Rod Adams <[EMAIL PROTECTED]> wrote: > Larry Wall wrote: > > >That, and we'd like a novice to be able to write > > > >given $x { > > when 1 | 2 | 3 {...} > > when 4 | 5 | 6 {...} > >} > > > Or just change C to accept a list of things to compare against, > followed by a coderef. Well, I don't think anyone can argue that having ~~ behave properly with junctions is wrong. After all, we can make it do whatever we want. $foo ~~ 1 | 2 | 3 Perhaps we can make ~~ an even more magical comparison operator. $x ~~ $y is a huffmanized version of $x ~==~ $y @x ~<~ $y is a smart-match based on < instead of == Or perhaps you can choose on which side the magic works: @x ~< $y OK, enough craziness for today. $foo ~<~ $bar # uses C for strings, C<+<>for numbers, voodoo for junctions, etc... Ashley
Re: Pop a Hash?
On Thu, 10 Feb 2005 08:59:04 -0800, David Storrs <[EMAIL PROTECTED]> wrote: > On Wed, Feb 09, 2005 at 05:13:56AM -0600, Rod Adams wrote: > > > > Does > > > > ($k, $v) <== pop %hash; > > or > > ($k, $v) <== %hash.pop; > > > > make sense to anyone except me? > > ... the only time it's useful is > if you want to process all the elements in the hash--in which case, > why not just use C< each >? That's true for the PerlHash implementation, but what about OrderedHash? Or LookupQueue? Still seems like a useful trick. Ashley
Re: Junctive puzzles.
On Tue, 8 Feb 2005 11:12:40 +0800, Autrijus Tang <[EMAIL PROTECTED]> wrote: > On Mon, Feb 07, 2005 at 05:33:06PM +0100, Miroslav Silovic wrote: > > my $a = (0 | 6); > > say 4 < $a and $a < 2; > > Yup. My mathematic intuition cannot suffer that: > > 4 < X < 2 > > to be true in any circumstances -- as it violates associativity. > If one wants to violate associativity, one should presumably *not* > use the chained comparison notation! Indeed. It smells like "relational" algebra, so we can confirm this intuition with a rather familiar example: select * from $a cross join $b cross join $c where a < b and b < c Looks right to me! I look forward to the SQL query construction modules in Perl6. :) Ashley
Re: Possible syntax for code as comment
On Sat, 8 Jan 2005 21:05:20 +0100, Stéphane Payrard <[EMAIL PROTECTED]> wrote: > Anyway the particular length of variables names was not the subject of > my mail, but a good syntax for aliasing name in signatures. Hmm... how about abducting the -> operator and using default variable initialization? Perhaps we can borrow a page out of the K&R C book. Lets say I take the -> operator and make it proper in these cases: sub canon( $subjet, $complement) -> $s = $subjet{$*Global}, $c = $complement { my @foo = ...; for @foo -> $bar; $remaining = @foo.elems { # $bar contains an element, $remaining contains the number of elements in @foo # or any expression I want, but it's block-scoped here } } How's that? Ashley
Re: strictness and fully qualified global vars
On Tue, 28 Dec 2004 22:31:47 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > Ashley Winters writes: > > sub foo (Class $who) { > > my $thing := $who<$var>; > > my &func := $who<&func>; # how would I do this otherwise? > > } > > In current Perl 6: > > sub foo (Class $who) { > my $thing := $::($who)::var; > my &func := &::($who)::func; > } Okay, I see. S10 says ::() is the catch-all symbolic naming syntax. However, $who would be a reference to a class object itself. Does it automagically accept hard-references, or would Class objects have to stringify to their global ::*::ClassName? More to the point, is %::(%foo) an identity op? Ashley
Re: strictness and fully qualified global vars
On Wed, 29 Dec 2004 06:55:11 +0300, Alexey Trofimenko <[EMAIL PROTECTED]> wrote: > P.S. I have one (almost unrelated to topic) observation: if sigil is a > part of a variable name, then C< Package::$var > makes more sense than > perl5 C< $Package::var >. (AFAIK, PHP5 works this way) And this requires > less magic from perl. I agree... that's inconsistent. I have another question: Are package/class/grammar namespaces valid objects in Perl6? I would assume yes, so you can call methods on them for meta-purposes. Would there be a default Namespace::postcircumfix:«< >» operator, which would make the above code look like: Package<$var> aka Package.<$var>? This would continue to make sense even when the namespace objects are passed to a function: sub foo (Class $who) { my $thing := $who<$var>; my &func := $who<&func>; # how would I do this otherwise? } I assume the second line can't really be done through stringification due to singletons. Well, on second thought, you could make $foo.meta (or whatever) start answering to CLASS(0xDEADBEEF) style classnames. Those are probably needed for debugging or something anyways. Ashley Winters
Re: S05 question
On Wed, 8 Dec 2004 16:07:43 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > Ashley Winters writes: > > For a grammar, that works perfectly! > > Yep. > > > In a one-liner, I'd rather just use: > > > > $datetime ~~ /$year := (\d+) -? $month := (\d+) -? ./ > > Then go ahead and use that. If you're going to use subrules, you can > either use the form or just the regular old form > and ignore the result. There's nothing forcing you to pay attention to > those. The number variables only get incremented when you use > parentheses. I'd suspect that the return value of a rule only accounts > for parenthecized captures as well. I was working on the (possibly misguided) assumption that there's a cost to capturing, and that perhaps agressive capturing isn't worth having "on" in a one-liner. Some deep part of my mind remembers $` being bad, I think. If there's no consequence to having capture being on, then ignoring it is fine. I don't have a problem with that. As I said before, reads fine to me. I'm still going to prefer using :=, simply as a good programming practice. My mind sees a big difference between building a parse-tree object and just grepping for some word I want in a string. Within a rule{} block, there is no place except the rule object to keep your data (hypothetically -- haha), so it makes sense to have everything capture unless otherwise specified. There's no such limitation in a regular code block, so I don't see the need. I may change my mind after using $/[2] Ashley Winters
Re: S05 question
On Wed, 8 Dec 2004 08:19:17 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > / $ := [ () = (\N+) ]* / You know, to be honest I don't know that I want rules in one-liners to capture by default. I certainly want them to capture in rules, though. > And people would have to get used to seeing ? as non-capturing assertions: > > > > > > > > This has a rather Ruby-esque "I am a boolean" feeling to it. I think > I like it. It's pretty easy to type, at least on my keyboard. I like it. It reads to me as "if before ...", "if null". Sounds good. > I think I'm leaning toward the idea that anything in angles that > begins alpha is a capture to just the alpha part, so the ? prefix is > merely a no-op that happens to make the assertion not start with an > alpha. Interestingly, that gives these implicit bindings: > > $$` > $ $' Again, I don't see the utility of that in a one-liner. In a grammar, you would create a real rule which would assert and capture the result in a reasonable name. > Anyway, that's where I am this week/day/hour/minute/second. I'm thinking capturing rules should be default in rules, where they're downright useful. Your hour/minute/second comment brings up parsing ISO time: grammar ISO8601::DateTime { rule year { \d<4> } rule month { \d<2> } rule day { \d<2> } rule hour { \d<2> } rule minute { \d<2> } rule second { \d<2> } rule fraction { \d+ } rule date { -? -? } rule time { \:? \:? [\. ]? } rule datetime { T } } For a grammar, that works perfectly! In a one-liner, I'd rather just use: $datetime ~~ /$year := (\d+) -? $month := (\d+) -? ./ and specify the vars I want to save directly in my own scope. Ashley Winters
Lexical scope of parametric declaration blocks
In S12, I see examples like: role Pet[Type $petfood = TableScraps] { method feed (::($petfood) $food) {...} } I assume that means lexicals declared as part of a parametric specialization declaration block thingy are only visible within that scope, like a formal subroutine parameter list? If so, are there things allowed (or disallowed) in type parameter lists vs. sub parameter lists? If [] is enforcing long-name generation or something simple like that, could I cheat and make it imply multi on my functions if I use it? sub foo[Int $x: Pair ?$y] {...} sub foo[Pair $x, Pair $y] {...} Would that be valid/mean anything? Okay, that enough curiosity for today. :) Thanks, Ashley Winters
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > Though it's awfully tempting to fill in the holes in the periodic table: > > ($a, $b, $c) = @foo *<< 3; > > And then just say all the corresponding unaries default to 1 (or the arity > of the left): > > $bit = +<< $number; # $number +<< 1 > $graph = ~<< $string; # chip()/chimp() > $whether = ?<< $boolean;# presumably clears $boolean > $elem = *<< $iterator; # shift $iterator Well, that's interesting. > I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries, > if we add 'em at all. I do think > > foo( @bar *<< 3 ) > foo( @bar *>> 3 ) Hrm... if you're thinking of going that way, I'd rather have a lazy-assignment/destructive-pipe operator of some sort: ($a,$b) <== [EMAIL PROTECTED]; # splice(@bar, 0, 2) ($a, $b) ==> [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b) [EMAIL PROTECTED] ==> ($a, $b); # splice(@bar, -2) [EMAIL PROTECTED] <== ($a, $b); # splice(@bar, @bar, 0, $a, $b); Of course, with something indicating the desire to modify the array. I don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an idea. I'd want some way of telling the array to lazily add/remove elements as part of the pipe operator, which would make: foo <== [EMAIL PROTECTED]; # REMOVE however many elements from the front of @bar as foo() wants However, this would lead to me thinking about this sequence: [EMAIL PROTECTED] ==> map ==> grep ==> @whatever; as: while pop @this { ... unshift @that, $_ } Which would be interesting (bad) for performance Ashley
Re: Container method calls
On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote: > : But this convention provides much more accuracy than memorizing a list > : of methods that don't automatically thread, or memorizing a list of > : iterator methods that act on the iterator and not its current value. > > Except that you don't actually have to memorize a list. Methods thread > on their invocant only if their invocant isn't a Junction. Its > mnemonic value is no better or worse than any other MMD distinction. Is this behavior exclusive to methods? Or does something like this: 3.14159 + "1"|2; try to MMD-dispatch to: multi sub *infix:<+> (Num $foo, Str|Int $bar) instead of (or before) threading? Ashley Winters
Container method calls
Howdy, While browsing the updated synopses, I noticed a problem with how scalar container methods are called. Currently, both value methods and container methods are shown in the synopses as being called with C<$foo.bar()>. For several reasons, that doesn't work for me. The method conflict between container methods and value methods should be obvious. What should ((1|2)|(3&4)).values return? The answer is simple enough: for scalar container method calls, use $foo.\bar(), which would be syntactic sugar for (\$foo).bar, and would be the Perl6 equivalent to the Perl5 idiom tied($foo)->bar() That way, we get: ((1|2)|(3&4)).values ~~ (1|3,2|4) # (1,2)|(3,4) I presume ((1|2)|(3&4)).\values ~~ (1|2, 3&4) @foo.\elems would work the same as @foo.elems, since @foo in scalar context *is* the container object in the first place. Comments? Ashley Winters
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 19:10:48 -0800, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > John Siracusa <[EMAIL PROTECTED]> wrote: > > On 11/30/04 9:54 PM, Matt Diephouse wrote: > > > use CGI «:standard»; > > > [...] > > > use CGi <:standard>; > > > > Who is doing this? I'm just saying... > > > >use CGI ':standard'; > > And won't we just be doing: > > use CGI :standard; > > anyway? Indeed. Also, someone *ahem* will make the following work, with or without the C<.> %hash.:foo:bar:baz = 10; Ashley Winters
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
On Tuesday 16 July 2002 01:01 am, Deborah Ariel Pickett wrote: > If %(...) makes a shallow copy of its innards, as Perl5's { ... } does, > then how do you impose hash context onto something without doing the > copy? %{} forces hash context. What else could it do? %{ foo() } calls foo() in hash context, asking it to return a HASH ref, does it not? %( foo() ) would call foo() in list context asking for a list of PAIRs. If foo() returns a hash ref which you want a copy of, you would use %( *foo() ) which would flatten the returning hash ref into a PAIR list, then construct a hash ref from those pairs. My argument is that %{} already represents 'HASH' context, and we don't need %() for that as well. Instead, we need a punctuation-happy hash constructor. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
On Monday 15 July 2002 11:22 pm, Deborah Ariel Pickett wrote: > Besides, does > $hashref = some_function_returning_a_hash() > make $hashref simply refer to the result of the function, or does it > make $hashref refer to a hash containing a *copy* of the result of the > function? If Perl6 is going to do fancy things with functions returning > lvalues, which looks like the case, those two things aren't necessarily > the same thing. I don't think scalar context can ever make copies of aggregate data. Here's a little experiment. sub func { return a => 10; # returns a single pair; not a list or a hash } $foo = func(); # $foo is a PAIR ref, not a hash ref $foo = { func() } # $foo is a CODE ref $foo = { *func() } # $foo is still a CODE ref, I assume? $foo = %{ func() } # die "Not a HASH reference" $foo = hash func(); # This should work > Or, saying the same thing another way, does this: > $href = %hash; > which I presume will be legal Perl6, mean the same as this Perl5: > $href = \%hash;#A It always means A according to some apocalypse. my %hash = (key => "bar"); sub foo { return %hash; } $ref = foo();# $ref = \%hash %copy = foo(); # %copy = { %hash } %alias := foo(); # \%alias == \%hash %$ref = foo(); # ($ref = {}) = %hash > or this Perl5: > $href = { %hash }; #B The ways I can think to do that are: %$href = %hash; # autovivify $href = {}, then copy $href = hash %hash; # Perhaps * flattening is required? > and how would I say each of A and B in Perl6 unambiguously? I don't much like the effects of using %$foo as an lvalue. Having a context sigil clobber the value doesn't seem very perl5ish. Perhaps I have my blinders on and don't see where Perl5 does that. > Automatic referencing and dereferencing is all well and good, and it > appears that it's here to stay in Perl6 (it's been in most Apocalypses), > but I don't think anyone's actually sat down yet to thrash out exactly > under what circumstances it happens. I think the rule of auto-hashifying only when an explicit pair is found is gonna be hard to swallow. I still have my vote on %() as a hash constructor in addition to {}. :) Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Perl6 grammar (take V)
On Monday 15 July 2002 07:52 am, Brent Dax wrote: > Ashley Winters: > # > You've got a point. There's an easy way to say "I want a sub": > # > > # > my $sub = -> { ... } > # > > # > But I can't think of a similarly punctuation-intensive way > # to say "I > # > want a hash." (someone please step in and correct me). > # > # I nominate: > # > # $() == scalar() > # %() == hash() > # @() == array() > # > # For the above function: > # > # $hashref = %(function_returning_list_which_needs_to_be_hashified()); > # > # That would make %() a hash constructor, just like {}. > > IIRC, $() and @() are already being used to denote scalar and array > context. Of course, an array or hash in scalar context would probably > referencify. But we don't need @() for array context, we have @{} for that. @{foo()} would pass foo() a 'want' value of 'ARRAY', would it not? In fact, the block in @{} as a whole has a 'want' value of 'ARRAY', and that wantedness propagates to whatever statements return a value from the block. So, I still want to use @() as a smart array constructor. If you pass an array reference to @(), it would dereference. If you passed a list, it would construct a reference. Perhaps it could even copy an array if it's passed one directly... my @copy = [ *@orig ]; # before my @copy = @( @orig ); # after Or not. That's weird. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Perl6 grammar (take V)
On Monday 15 July 2002 06:57 am, Sean O'Rourke wrote: > On Sun, 14 Jul 2002, Brent Dax wrote: > > Deborah Ariel Pickett: > > # My perl5 sensibilities tell me that that's likely to cause a > > # problem when I want to do something like this: > > # > > # $hashref = { function_returning_hash() }; > > # > > # because I won't get the function's return values put into a > > # hash, because the stuff inside the { ... } isn't a list of > > # pairs. Instead I'll get a (reference to) a closure, not at > > # all the same thing. > > You've got a point. There's an easy way to say "I want a sub": > > my $sub = -> { ... } > > But I can't think of a similarly punctuation-intensive way to say "I want > a hash." (someone please step in and correct me). I nominate: $() == scalar() %() == hash() @() == array() For the above function: $hashref = %(function_returning_list_which_needs_to_be_hashified()); That would make %() a hash constructor, just like {}. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: What's MY.line?
On Thursday 11 July 2002 11:47 am, Chip Salzenberg wrote: > According to Dan Sugalski: > > At 9:50 PM -0400 7/9/02, Chip Salzenberg wrote: > > >3a. If so, how can one distinguish among the e.g. many C > > >variables declared within the current function? > > > > One pad per block, rather than per sub. > > I just remembered why I thought that woundn't work: BEGIN is a block. > >my $x = 1; >BEGIN { %MY::{'$y'} = \$x } >print $y; Even worse, you should be able to modify lexicals even outside your scope. sub violate_me { caller(1).MY{'$y'} := caller(1).MY{'$x'};# hypothetical syntax } { my $x = 1; my $y; # Might be able to BEGIN { violate_me() } instead violate_me(); print $y; } Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: what's new continued
On Sunday 07 July 2002 05:33 pm, Ashley Winters wrote: > my($foo, $bar) = for { $_ = new Stuff } Err, the parser would die if I did that, never mind. Can I have each, perhaps? *@foo = each { undef } I shouldn't be programming on Sunday, Ashley Winters
Re: what's new continued
On Sunday 07 July 2002 04:10 pm, Ashley Winters wrote: > > given my Doberman $sis is female = .dog[0] but pregnant -> $mother { > for my Doberman @puppies = new Doberman x $mother.littersize In hindsight, I probably meant for my Doberman @puppies = ^new Doberman x $mother.littersize It's hard to come up with working code when there's no compiler for it. Then again, that just makes it harder for people to disagree with you. As for the 'bad' semantics of C, can I borrow C with no iterator for that? After all, C with no argument already does what C with no iterator would otherwise do. I think. my($foo, $bar) = for { $_ = new Stuff } It could also work in subs... my($foo, $bar) = read_lines($*STDIN); sub read_lines ($it) { for { $_ = <$it> // last } # last unshifts $_ from the wanted list return;# any return-value is after the final for{} value read } Well, I can wait for whatever apocalypse is going to specify how to return the 'wanted' number of values. I'm just spinning my wheels. :) Ashley Winters
Re: what's new continued
On Sunday 07 July 2002 03:05 pm, Damian Conway wrote: > Ashley Winters wrote: > > How about: > > > > $_ = new Doberman for my Dog ($spot, $rover) is rw; > > I don't think so. > > In Perl 6 you'd just need: > > $_ = new Doberman for $spot, $rover; Hmm, I thought the for topic was made ro at some point. Odd. However, I still expect to be able to use my() in a loop condition/iterator and have it visible to the outer scope! given my Doberman $sis is female = .dog[0] but pregnant -> $mother { for my Doberman @puppies = new Doberman x $mother.littersize -> Doberman $puppy is cute { my @colors := Doberman.colors; $puppy.color = @colors[rand(@colors.end)]; } $mother.labor($_) for @puppies; } $sis.feed(); I gave way too much thought to that. I need to go, now... Ashley Winters
Re: what's new continued
On Sunday 07 July 2002 02:19 pm, Damian Conway wrote: > Ashley Winters asked: > > > It *might* possibly work to hyper the constructor: > > > > > > my ($a, $b) = ^new Foo > > > > Would prefix ^ always return 'wanted' number of repetitions? Like a > > smart C? > > This does bother me about the above proposed syntax/semantics. > Hyperoperations take their "magnitude" from that of their operand(s). > I would have expected the above example needed to be: > >my ($a, $b) = ^new (Foo,Foo); How about: $_ = new Doberman for my Dog ($spot, $rover) is rw; Err, whatever. Ashley Winters
Re: greedy/non-greedy regex assertions
On Thursday 04 July 2002 11:07 am, Ashley Winters wrote: > > I would expect /a<*1..2>?/ to mean /[a<*1..2>]?/ just looking at it. How > can ? ever mean non-greedy unless it follows a metachar <[*+?]>? Perhaps I can respond to my own question. In /.+?/ . is an assertion, + is an assertion, and ? is a modifier. Therefore, it means /<.><1,Inf>:m/ or something close, where :m is mnemonic for minimal. Did apoc 5 ever say . means <.>? Ashley Winters
Re: greedy/non-greedy regex assertions
On Thursday 04 July 2002 10:47 am, Larry Wall wrote: > On Thu, 4 Jul 2002, Ashley Winters wrote: > So I'd guess that we just don't talk about :-1, but rather say that > > <*$min..$max> > > is naturally greedy, and as with any quantifier you write > > <*$min..$max>? > > to get minimal matching. I would expect /a<*1..2>?/ to mean /[a<*1..2>]?/ just looking at it. How can ? ever mean non-greedy unless it follows a metachar <[*+?]>? > But sigh, it would fix so many novice bugs to make minimal matching > the default... I agree wholeheartedly. *sigh* Ashley Winters
greedy/non-greedy regex assertions
I was pondering how to implement the apocalypse 5 stuff (only pondering) and I was wondering if could be legal, indicating a greedy match. * = + = ? = <1,0> *? = <0,Inf> +? = <1,Inf> ?? = <0,1> Speaking of the range assertion, is there anything other than ? There used to be discussion on the list about adding more possibilities, but I didn't follow it. Thanks, Ashley Winters
Re: what's new continued
On Wednesday 03 July 2002 06:39 pm, Larry Wall wrote: > On Wed, 3 Jul 2002, Damian Conway wrote: > : Date: Wed, 03 Jul 2002 19:33:33 -0400 > : From: Damian Conway <[EMAIL PROTECTED]> > : To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > : Subject: Re: what's new continued > : > : Comments (otherwise you have things pretty much right): > > I didn't see the original here. > > : > we can even have hyper-assignment : > : > > : > my ($a, $b) ^= new Foo; > : > : This is unlikely to do what you wanted. It creates a new Foo object and > : then assigns a reference to that one object to both $a and $b. It doesn't > : create two Foo objects. (But maybe one object referenced twice is what > : you wanted). > > It *might* possibly work to hyper the constructor: > > my ($a, $b) = ^new Foo Would prefix ^ always return 'wanted' number of repetitions? Like a smart C? @x = qw(foo bar baz); @y = (one); for @x, ^"unseen"; @y, ^"too high" -> $x; $y { # foo, one # bar, too high # baz, too high } Ashley Winters
Re: Perl 6 Summary
On Wednesday 03 July 2002 12:54 pm, Thom Boyer wrote: > To get a better feel for the weirdness that happens with pass-by-name, > consider this example: > sub check_it_out { > $_[0] = 0; #step 1 > $_[1] = 7; #step 2 > } > > my @a = (0,1,2,3,4); > my $i = 2; > check_it_out($i, $a[$i]); > print join '', @a; > > This prints '01734' under Perl 5, because the arguments ($i and $a[2]) are > passed by reference. > > If the arguments to check_it_out() were passed by name instead, the result > would be '71234', > because step 1 would change $i to have the value 0, and *then* $a[$i] would > be evaluated in > step 2 (using $i's new value), causing the 7 to be assigned to $a[0] (not > $a[2]). Creepy. Here's my creepy thought for the day: is there a possibility for a prototype which would implicitly wrap a sub{} around a passed-in argument? i.e. lazy evaluation via sub prototype? sub check_it_out (&$idx is rw, &$val is rw) { $idx = 0; $val = 7; } check_it_out($i, $a[$i]); # really means: check_it_out(sub is rw { $i }, sub is rw { $a[$i] }); I would guess parser tricks and tied scalars would allow it somehow, if not out of the box. Still creepy. Ashley Winters
Re: Perl 6 Summary
On Tuesday 02 July 2002 11:15 am, [EMAIL PROTECTED] wrote: > On Tue, Jul 02, 2002 at 10:36:45AM -0700, Erik Steven Harrison wrote: > > my $a = 'foo'; > > > > pass_by_name ( sub { print $a} ); > > > > sub pass_by_name { > > my $a = 'bar'; > > &@_[0]; > > } Perhaps a pragma which does: my %MY := caller.{MY}. for instance: pass_by_name { sub { use scope 'caller'; print $a } } Perhaps something simpler which implies the same thing? sub is iterator { print $a } I'm just shooting in the dark, good luck. :) Ashley Winters
Re: Perl 6 grammar progress?
On Monday 01 July 2002 02:30 pm, Uri Guttman wrote: > >>>>> "AW" == Ashley Winters <[EMAIL PROTECTED]> writes: > > AW> Also, where does $() come in? Is statement scalarification ever > AW> useful outside a string? > > it is the same as scalar() in perl5. it provides scalar context if used > outside a string. If the parallel is so close, I assume these 'context' constructs also work? *(squish()) &(@lazy) @x = *(@foo, @bar, @baz) => concatenate @x := &(foo(), @bar, baz()) => very lazy @x = *(*@baz) => squash a 2d array down to 1d? Perhaps it's enough to list these coercive functions/operators? bit($arg) int($arg) num($arg) str($arg) obj($arg), $scalar, %hash, @array, &foo, \$ref scalar($arg), $($arg), $arg list($arg), ($arg) flat(@arg), *(@arg), *@arg lazy(@arg), &(@arg), &@arg That could make sigil handling pretty easy. foo would mean $($($($foo))) and so forth. Perhaps that's too much? Ashley Winters
Re: Perl 6 grammar progress?
On Sunday 30 June 2002 09:09 pm, Sean O'Rourke wrote: > On Sun, 30 Jun 2002, Ashley Winters wrote: > > I don't know how the grammars are going, and I'm not fit to write one > > myself, > > Hey, neither am I, but that hasn't stopped me from taking a stab or two, > figuring that through pain comes fitness. The attempt has certainly given > me a much better understanding of Perl (both 5 and 6) than I had before as > a mere user. If there's anyone else out there with the time for and > interest in working on a Parse::RecDescent grammar, feel free to speak up. I don't want to do it in Parse::RecDescent, I want to do it in Parse::FastDescent! Too bad it's not written yet... Damian? > > Neither am I, but we might as well throw in @{foo}, %{foo}, &{foo}, maybe > even $*{foo} (global symbolic reference?). $*{foo} was in there, at least. I'm still not quite diabolical to come up with the really screw-your-parser-up kind of stuff. ${"}"} and such come to mind, assuming that's legal. Also, where does $() come in? Is statement scalarification ever useful outside a string? > > > # Also, there are globals to consider > > [...] > > And the wonderous *@$*foo (flattened dereferenced global $foo?). I didn't do any sigil stacking at all in there, just context characters. I don't think there will be much sigil stacking, if any, beyond just stacking $'s to dereference scalar refs. > > > # off the subject, but lets make sure $foo.. is parsed correctly > > $foo..1; > > > > $foo..[1]; > > $.foo..{1}; > > Color me slow, but are these even legal? What does an anonymous list > constructor do on the LHS of a range operator? I suppose it could just be > one example of something that is always true, but could it possibly be > useful other than by the perversity of overloading ".."? And would the > second require whitespace before the '{' to be parsed as a closure/block? Well, perhaps PDL will have a reason to overload .. that way. There's no reason for the parser to choke on it by default - the compiler certainly should, though. As for .{}, that's an interesting thing to ponder. From the apocalypse, it says a { found where an operator is expected without preceding whitespace would be considered a subscript. Since '.' or '..' is the operator, the next brace would *normally* start a hash constructor or sub. I would guess '.' forces the next opening brace to start a subscript, but without the whitespace rule. $foo . { $x + 10 }# really means $foo{$x + 10}; Or maybe using binary . in this fashion is Bad? > > @foo{1}; # I ass_u_me {} [] and () can be overloaded? > > Blech! Even if it's legal, this seems like it should be a mandatory smack > upside the head. If we allow this, someone will overload {} to do hash > slices on %foo, and we'll be right back to Perl 5 ;). Well it's unambiguous, so I expect someone out there will try to be funky. > > > @foo(1); > > @foo(); > > Strange overloading again, or am I missing something? If we allow > subscripting and calling to be overloaded on variables with any kind of > sigil, what's the point of having sigils at all? There isn't much of a 'point' anymore except overlapping variable names. I would guess the p52p6 translator could do something silly like this: #!/usr/bin/perl5 @x = (500..800); $y = $x[rand($#x)]; #!/usr/bin/perl6 $x_array := @x_array; @x_array = (500..800); $y_scalar = $x_array[rand($x_array.length)]; The Highlander RFC (009) suggested making @x %x and &x all mean $x, and Larry liked the idea in general, but he wanted to keep them separate because people were used to it that way. Since $foo can be subscripted in all ways, I can see how other people might want to subscript @% as well. If someone were particularly perverted, they could make subscripts on &foo have reflective consequences. *shrug* > > foo{1}; # foo is unary here > > Is this a hash subscript on a no-argument function returning a hash, or a > block passed to foo(&block), or a malformed hash constructor being passed > to foo(%hash)? I vote for the first, because I thought blocks' and > hashes' opening brackets always needed preceding whitespace (or at least > /(? ${ foo() }{1} foo.{1} => ${ foo() }{1} foo {1} => foo(sub {1}); foo {a => 1} => foo(hash(a => 1)); > > foo.(); # Is this &{ foo() }() or foo()? I would vote former > > aka foo()()? Sick... Hey, it has to mean something. > > # As a final sanity check, lets chain these things > > > > @.proc[$*PID].ps.{RSS}; > > == "@{.proc()[$*PID].ps().{RSS}}&qu
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thursday 16 May 2002 01:13 pm, David Whipp wrote: > Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote: > > You might not be able to REASONABLY get a length, so you return > > undef. In your documentation, you advise users not to take the length, > > but just dive right in and fetch the element you want, e.g.: > > > > my $pi2k = @pi_digits[2000]; > > In this case, I'd expect @pi_digits.length == Inf, not undef. I'd agree with that. Perhaps you want *@lazy.length to work? Ashley Winters
Re: Loop controls
- Original Message - From: "David Whipp" <[EMAIL PROTECTED]> > Is this the same as saying that C can be followed by > *any* statement? If not, then we would need user-defined > control statements (a property on a sub?) that can be used > in the "else" context. Perhaps C is a binary operator? condition else expr. Like operator::or, but doesn't try to return a value. die unless foo; foo else die; Ashley Winters
Re: Fisher-Yates shuffle
- Original Message - From: <[EMAIL PROTECTED]> > On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote: > > [EMAIL PROTECTED] writes: > > > > > > Why isn't > > > > > > if %foo {"key"} {print "Hello 1"} > > > > > > equivalent with the perl5 syntax: > > > > > > if (%foo) {"key"} {print "Hello 1"} > > > > > > Which keyword is it expecting? > > > > Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased > > on my part. The closing brace of {"key"} only ends the statement if it > > is followed by /\s*$/, or a semicolon. > > > You've got to be kidding. That makes the whitespace rules even more > insane; your program can behave quite differently wether there's a space, > a newline, or nothing between two tokens. Wonderful! People who tend > to use -e all the time (like me) will love it. (Not!) Pasting code into > IRC will be so much more fun. I don't think it's all that insane, Perl has history with implied semicolons. Perl today: A semicolon is required after every statement, except before a closing curly or end of file. Perl 6: A semicolon is also required after every block, except when the closing curly is on a line of its own, or it precedes another closing curly or end of file. As far as whitespace, you can get around that if%foo{"key"}->{print"Hello"} # -> and \s{ are kinda equivalent if%foo->{"key"};{print"Hello"} Using -> like that would be evil. We should put it in the test suite now... Ashley Winters
Re: How to default? (was Unary dot)
- Original Message - From: "Graham Barr" <[EMAIL PROTECTED]> > Hm, I wonder if > > sub printRec($rec=$_) { ... } > > or someother way to specify that the current topic be used > as a default argument, might be possible Would it would be reasonable to have given default to the caller's topic? sub printRec { given { # $_ is now the caller's topic in this scope } } Perhaps C would work as well. Ashley Winters