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: 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 { /hexadecimal+/ } =$*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 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: 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
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
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: 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 KR 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 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
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 ?subrule form or just the regular old subrule 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, ?foo 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 $/URI::URLpath_segment[2]
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: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting certain forms of the opcodes to be slow (that's the pessimization part), but then you're acutally using opcodes that you think can be made faster. This is a classic Knuth example. So the sequence of using classoffset/getattribute is a _feature_ necessary for completeness, rather than a pessimization to compensate for the belief that not explicitly caching would be hopelessly slow? Ahh. I'm learning much. :) 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)|(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: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt
On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
Now, I ask for PMC programmers to take care implementing this! Notice
that, for example in arrays, arrays with the same length but different
elements should return different hash codes (or try). But for the same
elements MUST return the same hash code.
foo = ();
%hash{@foo} = 10;
push foo, 'This would change the hash key for foo?';
print ok 1 if exists %hash{ [] };
print ok 2 if exists %hash{ [10] };
print ok 3 if exists %hash{@foo};
What's going to get printed from that?
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt
On Tuesday 23 July 2002 08:27 am, Ashley Winters wrote:
push foo, 'This would change the hash key for foo?';
print ok 1 if exists %hash{ [] };
print ok 2 if exists %hash{ [10] };
Err, I meant:
print ok 2 if exists %hash{ ['This would change the hash key for foo?'] };
Also, the same question would apply if I simply changed the value of an
element in foo instead of changing the number of elements.
Re: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt
On Tuesday 23 July 2002 08:44 am, Alberto Manuel Brandão Simões wrote:
On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
foo = ();
%hash{@foo} = 10;
push foo, 'This would change the hash key for foo?';
print ok 1 if exists %hash{ [] };
print ok 2 if exists %hash{ ['This would change the hash key for
foo?'] }; print ok 3 if exists %hash{@foo};
What's going to get printed from that?
IMHO, it should print 'ok 1'. The idea of the hash function is to use
PMC's as hash keys. That means that different content PMC (as an array
with different elements) must return different hash keys.
I can see the argument both ways, but I have a proposal.
foo = (1 .. 100);
%hash{@foo} = reference;
%hash{@foo.freeze} = contents;
%hash{@foo} eq reference;
%hash{[1..100].freeze} eq contents;
I'm just using freeze as the serialization routine until a real name is
determined. If I need a unique key for hashing based on aggregate content,
can I ass_u_me the builtin Perl6/Python/etc serialization mechanism will
suffice?
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Keyed access
On Sunday 21 July 2002 06:46 pm, Scott Walters wrote: 2. PMCs return iterators allocated on a stack that allow them to function as KEY *s allocating a single fixed size peice of memory rather than all of the parts of a linked list. In other words, factor out the part of PMCs that index a given element. This would completely bypass the construction of KEY* lists, and allow PMCs to function as keys. This case needs to be optimised, as most keys will be scalars or a few scalars, and quickly moving from a scalar to a key should be paramount. 3. Let PMCs create KEY * lists. Whats more, rather than scraping KEY * lists of an adequate size and replacing them every iteration in user code loops, *update* the KEY* list from PMCs. Eg, if $x is the first item, $y is the second, and $z is the third, update the values in the KEY* with the new values from the scalars, then shuffle the same KEY * off again. Use a load/store strategy! The complexity involved in exposing every single method in a contained object damages cache use beyond *any* possible benefit! See earlier post for details. Not to beat a dead horse, but I like the concept. However, rather than using the KEY* linked list, use a tuple. They would be constant size, so we could allocate them on the stack. They would iterate nicely without thrashing memory. No malloc(), so we could keep the main KEY* functionality without adding a special-purpose key pmc, and we'd get a *fast* generic Tuple PMC class out of it. Ashley (by committee) 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: 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: PARROT QUESTIONS: Use the source, Luke
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote: It's also unnecessary. It isn't like there aren't perfectly good alternatives--what's wrong with Parrot__? Well, what's wrong with Parrot_ ? There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*. A good thing used in excess is bad, and all that mumbo jumbo. 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.
PARROT QUESTIONS: Use the source, Luke
I'm trying to pay attention to the difficulties I have understanding parrot so
I can give some decent n00b feedback before I know the code like the back of
my hand.
First, test_main.c is a totally non-obvious location for parrot.exe's main().
I dismissed it out of hand when I did grep ^main. I only believed it was real
when I looked at the linker arguments. Is there a reason for the test_
prefix? It's really misleading if you're actually using it.
I'm also a little disturbed by *everything* having Parrot_ in front of it.
Namespace friendliness is nice, but having the internal functions with the
same prefix as the embed.c functions is unkind. I'd like to see _Parrot_ or
Parrot__ for the internal functions (hell, just the opcodes) and Parrot_
reserved for the visible API. _Parrot_ would be better, since source grepping
for ^Parrot wouldn't list them. Grepping for ^Parrot_new (the first function
called in main(), and the first function anyone reading from the top would
search for) was painful.
There's no pointers between source and documentation. embed.c is a direct
implementation of embed.pod, but neither mentions the other. Any place
documentation and implementation exist, they should point to each other.
Until the documentation is good enough that you don't need to look at the
source to see how to use it, the documentation needs to give the location of
the source. :)
test_main.c and embed.c have no comments. They are the starting-point of the
parrot interpreter but there's no guidance as to where to go from there. In
the case of embed.c, I would definitely like to see each function specify
what files their implementation can be found. A gushing amount of inline
documentation would be good too, but even as little as this:
struct Parrot_Interp *
Parrot_new(void)
{
if (!world_inited) {
world_inited = 1;
init_world(); /* global_setup.c */
}
return make_interpreter(NO_FLAGS); /* interpreter.c */
}
I had to cutpastegrep the source countless times to find anything.
A pointer from test_main.c to embed.c and embed.pod would've been helpful as
well.
What the heck is parrot.c doing empty? I expected it to have... something. I
don't know. Being empty is Wrong. I would've expected the functions which are
actually in embed.c to be in there ala. perl5's perl.c at least. If it's not
going to have source, it definitely needs a comment saying this is not the
file you are looking for, see test_main.c and embed.c.
/nitpick
I think that's all for today,
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Use the source, Luke
Hrm, I had intended to put my questions at the end. I hit Send early. Questions: 1. Why is test_main.c not named main.c? 2. What does having a Parrot_ prefix signify, considering both the opcodes and the embed api use it? It's hard to distinguish between them. 3. What source files implement what docs? 4. Where can I find out what embed.c is doing? 5. Why is parrot.c empty? Ashley Winters
Re: PARROT QUESTIONS: Use the source, Luke
On Monday 15 July 2002 02:25 am, Brent Dax wrote: -C library wrappers: This is Parrot's version of the function, so it makes sense to prefix it with Parrot_. The third category I can see having a prefix of plat_ (for platform) or some such, and perhaps the second could have misc_, but I foresee that becoming annoying. (Which seems better to you, Parrot_sprintf or misc_sprintf?) c. parrot_sprintf Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
PARROT QUESTIONS: The PDDs
. :) Discuss. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Parrot contribution
On Saturday 13 July 2002 07:39 am, Sean O'Rourke wrote: To help even more, you could collect the answers to these questions when you receive them, and make the resulting FAQ part of your contribution to Parrot. Write the FAQ you wish had existed when you first came. I would find that handy. I'm sure the answers would be enlightening. How much why? can this list handle, anyways? If I subscribe to the CVS commit list and start asking you folks for explanations of the interesting, undocumented patches, would you answer my questions if I submitted doc patches with the answers? I haven't even compiled Parrot before, so you'd be getting genuine n00b questions. Be warned. Is there a complete description, or even listing, of command-line switches outside of parrot -h or whatever? running.pod doesn't quite do it for me. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Mutable vs immutable strings
On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote:
I was referring to the above situation where a lexical might be optimized
away without being stored in a pad (for %MY).
I would *hope* %MY is only modified at compile-time. I wouldn'd be upset if
Perl ignored my attempts to access %MY at runtime.
As for eval, if I ever need a CS master's thesis subject, I could always try
this...
Whenever the compiler runs across an eval, take a continuation from within the
compiler. Make sure the compiler keeps enough state in lexicals to start
where it leaves off. At runtime when the eval is reached, save the current
continuation and hop over to the compile-time continuation and try compiling
it in-place as a sub. It would be necessary to treat any lexicals used inside
the eval as arguments to the sub -- otherwise usage of those lexicals
inside the sub might change the optimization of those scalars and you
wouldn't be able to call the continuation back to the runtime eval and have
it work. Then, fiddle with the newly compiled bytecode and find the address
of the eval continuation location we jumped from, and go back there.
for 1..1000 - int $i { # $i is optimized away in a nice register
my $str = '$i + 1';# assume this isn't constant voodoo'd away
#eval $str;# at runtime, this could mean:
my $compiletime_cont;
my $runtime_cont;
BEGIN {
$compiletime_cont = take_continuation();
if caller(0).continued { # just guessing at a flag
# this block is actually called at _runtime_
# this should morph the else clause bytecode below
Perl6::compile_for_eval($str, $runtime_cont);
invoke($runtime_cont);
}
}
$runtime_cont = take_continuation();
unless caller(0).continued {
invoke($compiletime_cont);
} else {
# this code is modified/generated/whatever by compile_for_eval above
my sub eval_expression = sub ($i) { $i + 1 }
eval_expression($i);
# I decided $(- $i { $i + 1 }).($i) was too obfuscated. You're welcome
}
}
Wouldn't it be great to have something so incredibly slow? Code morphing is so
80's! Okay, I've had my headache-inducing thought for the evening. bow/
Yes, my Scheme interpreter written in Perl6 is coming along nicely. Muahaha!
(kidding, obviously)
Ashley Winters
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: Mutable vs immutable strings
On Wednesday 10 July 2002 02:39 pm, Melvin Smith wrote:
Since Perl vars type-morph themselves, Perl will use PMC types everywhere
that there is an exposed interface. Internally you could use an I/S/N
register.
I see no reason why
foreach my $i (nums) {
...
}
should not use an Ix reg for $i, but maybe $i isn't an int at all, or nums
is actually a mixed list.
I thought that was the whole point of typing in Perl 6.
my int nums = (1, 2, 3.1); # (1,2,3) assuming Cmy int foo 'works'
for nums - $i {} # $i is a PMC, still
for nums - int $i {} # $i is in an Ix register now
for nums {}# will $_ be smart enough to 'int' itself? I hope so
Yes, people will have to think about optimizing their code. It's not great,
but it's not that onerous. It might be nice if the current topic would type
itself based on its initializer, when obvious.
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 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
greedy/non-greedy regex assertions
I was pondering how to implement the apocalypse 5 stuff (only pondering) and I was wondering if Inf,0 could be legal, indicating a greedy match. * = Inf,0 + = Inf,1 ? = 1,0 *? = 0,Inf +? = 1,Inf ?? = 0,1 Speaking of the range assertion, is there anything other than x,y? There used to be discussion on the list about adding more possibilities, but I didn't follow it. Thanks, 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: 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 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: 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 12:46 pm, Dan Sugalski wrote:
So, it's been a week or so and, while I'm mostly offline until
wednesday, I'll ask the question...
How's the work on the perl 6 grammar going? We any further along than
we were before YAPC?
I don't know how the grammars are going, and I'm not fit to write one myself,
but I wrote a list of variables I'll try to parse using any grammars which go
by. Are all of these legal? I suppose that's more of a -language question.
Ashley Winters
# Variable access you will want to parse
# standard variables
$foo;
foo;
%foo;
foo;
# need more tests for ${}, I'm not evil enough for it
${foo};
# Apocalypse 3 specifies context characters
*@foo;
$@foo;
foo;
*%foo;
*@{foo};# sanity check
# Also, there are globals to consider
$*foo;
*foo;
%*foo;
*foo;
$*{foo};
*@*foo;
$@*foo;
*foo;
*%*foo;
# not to mention members
$.foo;
.foo;
%.foo;
.foo;
$.{foo};
*@.foo;
$@.foo;
.foo;
*%.foo;
# lets test packages at least once
$foo::bar;
foo::bar::baz;
%foo::bar::baz::blurfl;
foo::bar::baz::blurfl::aybabtu;
# Now, the hard part. Element access
$foo{1};
$foo[1];
$foo(1);
$foo();
$foo.{1};
$foo.[1];
$foo.(1);
$foo.();
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
$foo..(1);
$foo..$*STDIN;# perfectly legal
$foo...bar; # $foo .. .bar, since there's no binary ...
foo{1}; # I ass_u_me {} [] and () can be overloaded?
foo[1];
foo(1);
foo();
.foo{1};
.foo[1];
.foo(1);
.foo();
foo.{1};
foo.[1];
foo.(1);
foo.();
.foo.{1};
.foo.[1];
.foo.(1);
.foo.();
# I will just assume if the parser made it this far, [%$] also work
foo{1}; # foo is unary here
foo[1];
foo();
foo.{1};
foo.[1];
foo.(); # Is this { foo() }() or foo()? I would vote former
.foo{1};
.foo[1];
.foo();
.foo.{1};
.foo.[1];
.foo.();
# As a final sanity check, lets chain these things
.proc[$*PID].ps.{RSS};
proc.[$*PID].ps().{RSS};
# And, just to make sure your parser doesn't pass this suite...
$foo{Do you want to try $interpolated{string}?};
# Okay, I've had my fun
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
RE: parrot rx engine
--- Brent Dax [EMAIL PROTECTED] wrote: Tim Bunce: # On Thu, Jan 31, 2002 at 05:15:49PM +, Graham Barr wrote: # # Especially as the perl6 rx engine will have to be able to # work directly on # non-trivial things like streams and generators ans suchlike. I have a suggestion similar to the ops suggestion but more flexible: Regex vtables. We'd probably need three: -normal text match -case-folded text match -generic sequence match (the stuff Larry's been talking about) Hmm... based on what I've read in Larry's message and the unicode spec, some of this could be spirited away into a customizable and/or chained unicode string iterator. For instance, it (the iterator) could return case-folded (or not) characters, it could convert pairs into Ps/Pe quote pairs (for code parsers) and remove comments (yay), and it could return locale-based graphemes (I'm scared). Since graphemes at least will be multi-character in some locales, I see how my objection to rx_literal was a Bad Thing. And I expect to be able to write a grapheme-sending unicode string iterator and plug it into a regex and have it DWIM in my Distant $future, right? Perhaps the backtracking mechanism should be *in* the iterator? Maybe the iterator will be the home of some locale evil? Could we make it handle locale character-ranges [a-o'] too? Okay, that last one's a bit much. Still, Larry did mention that business with generalized backtracking and bookkeeping... I can't wait for Apocalypse 5. Is there a custom iterator syntax/convention in parrot? I hope I don't give Larry any *new* scary ideas for the next apocalypse. This is just for entertainment purposes, after all /disclaimer. Ashley the Zealot __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
parrot rx engine
$r.current_code_point {
when U+43, U+44, U+63, U+64 {}
# since a switch is actually executed in order, the
# optimizer can not only merge sequential codepoints,
# it can order the comparisons to make the most likely
# matches (ascii) be tested first, and for oddball
# equivalent character comparisons be done later.
#
# just showing what the optimizer might do with /[a-z]/i
#if U+41 = $_ = U+5A or U+61 = $_ = U+7A {}
default { last }
}
}
}
}
return false;
}
match(xxabbBBcdcdcdzz);
__END__
Am I fool, or an idiot? Discuss.
Mostly, I'd like to hear how either Unicode character-ranges aren't
deterministic at compile-time (I doubt that) or how crippling to
performance this would be (and by implication how slow parrot will be)
in either time or space.
Ashley Winters
__
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
