Re: 12 hackers hacking...
On Thu, Dec 25, 2008 at 9:39 AM, Mark J. Reed markjr...@gmail.com wrote:
On Thu, Dec 25, 2008 at 12:00 PM, Patrick R. Michaud pmich...@pobox.com
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 LS06/Unpacking a Pair 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: 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 Cagainst to invert
the arguments to ~~ versus Cwith.
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
Call(.members »=:=« one(.members))? 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 Iin user code. 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. Cmy $var = undef is redundant, after all -- as is C$var // undef. When used as a value, undef returns Cnil but E::UndefinedValue 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 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 ~~ /Perl6::Grammar::Int/, 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: 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: 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: 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: 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: 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
inferencing; either of those declarations can disregard my potential
for runtime tomfoolery, and abort the compiliation when there's
something illogical.
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: 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: 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: ./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 :voteyea
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: 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 Ireally 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 Ctemp is made to work on lexicals, of course.)
How about 'the'? I don't want to Ipossess 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 docwhy
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 docTemperature in degrees F)
docConvert degress F to degrees C
{...}
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 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 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 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 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 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 Cwhen 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 Clt 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: 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 := $whofunc; # 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: 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 := $whofunc; # 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: S05 question
On Wed, 8 Dec 2004 08:19:17 -0800, Larry Wall [EMAIL PROTECTED] wrote:
/ $bar := [ (?ident) = (\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:
?before ...
?after ...
?ws
?sp
?null
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:
after ... $after$`
before ...$before $'
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 after ... 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 { \d4 }
rule month { \d2 }
rule day { \d2 }
rule hour { \d2 }
rule minute { \d2 }
rule second { \d2 }
rule fraction { \d+ }
rule date { year -? month -? day }
rule time { hour \:? minute \:? second [\. fraction]? }
rule datetime { date T time }
}
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
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)|(34)).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)|(34)).values ~~ (1|3,2|4) # (1,2)|(3,4) I presume ((1|2)|(34)).\values ~~ (1|2, 34) @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: 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
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: 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: 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: 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: 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: 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 Cmy $foo
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 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 Cx Inf? 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: 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;
grin 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 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 Cmy($foo, $bar) = ^new Stuff, can I borrow
Cfor with no iterator for that? After all, Cgiven with no argument
already does what Cfor 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 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: 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
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: 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: 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
Cx Inf?
@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 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
/(?!\w){/).
I would guess:
foo{1} = ${ 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}}, right?
Depends on if .member means {.member()}. I thought .member accesses the
actual data, and .member is the accessor function.
== .proc[$*PID].ps().{RSS}
or .proc().[$*PID].ps().{RSS} via accessor
proc.[$*PID].ps().{RSS};
== {proc().[$*PID].ps().{RSS}}? Or is that '[]' overloaded on a '.'
operator on 'proc'? In either case, we may have to do a sick amount of
look-ahead and guess-work to figure out whether the leading '' is a sigil
or a dereference. Which has higher precedence
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 Celse 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 Celse 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}-{printHello} # - and \s{ are kinda equivalent
if%foo-{key};{printHello}
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 Cgiven caller.topic {} would work as well.
Ashley Winters
