Re: the handiness of undef becoming NaN (when you want that)
On Wed, Oct 17, 2001 at 03:42:30PM -0500, David Nicol wrote: I am implementing a textbook algo in Perl (the textbook has it written in C++) and have realized that if undef was to numericize to NaN instead of 0, there are a lot of uninitialization errors that would get caught. use strict vars; does not recognize use of new array indices as unitialized variables. Yes, but do you really want to break: $z[0] = 50; $z[2] = 20; @x = @y[@z]; -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
AOP
In reading the Oct'01 issue of Communications of the ACM, I find myself
intrigued by the concept of aspect oriented programming (AOP). The basic
idea is that some methods in an object tree have simillar concerns even
though they are in different objects. AOP is an attempt to make such
crosscutting concerns more easily identifiable and provide them with
the means to access required data, execute code when appropriate, etc.
I think calling this AOP might over-emphasise its usefulness, but
I could easily see a number of places where I would want some way to tag
multiple methods in different classes so that they had common behaviors.
If we're to add some kind of data hiding to Perl6, then perhaps this
is the right time to also add some AOP concepts.
Class classa is concerned('classx');
sub .amethod ($a,$b) concerns classx.y {
# ...
} concerns classx.z;
Class classb is concerned('classx');
sub .bmethod ($c,$d) concerns classx.y {
# ...
} concerns classx.z;
Class classx;
sub .y () {
# This gets called before classa.amtheod and
# classb.bmethod and can access the internals
# of the object's state.
}
sub .x () {
# This gets called after classa.amethod and
# classb.bmethod and can access the internals
# of the object's state.
}
All of this is still coming into focus for me, and I want to spend
more time reading the articles later, but for now I just wanted
to see if anyone else has been thinking these thoughts
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
RFC: Anonymous classes
Is it too late for RFCs? How does one get approved for submission these
days? Or, do we just mail them off to [EMAIL PROTECTED]?
=head1 TITLE
Anonymous classes
=head1 VERSION
Maintainer: Aaron Sherman [EMAIL PROTECTED]
Date: 24 October 2001
Version: 1
Mailing List: perl6-language
Number: 1
=head1 ABSTRACT
Anonymous classes are analogous to anonymous subroutines. They provide
an object with a unique namespace, lexical closure and method definitions.
=head1 DESCRIPTION
A while back on p5p, I suggested that:
$obj-atexit(sub {...});
should be added to CUNIVERSAL (e.g. run this function when
Ithis particular instance goes out of scope).
Looking at Perl6, I see a better way that generalizes much more cleanly.
First off, let's look at anonymous classes:
$x = class { sub .DESTROY { ... do cleanup ... } };
This creates a new object which exists in a class which is analogous
to an anonymous subroutine. This class is unique. It also provides
a closure in which its methods can access lexically scoped variables
within the caller's namespace.
So, C.atexit is:
class UNIVERSAL;
sub .atexit (function) {
my $tmp = $self; # To avoid clash inside nested method decl
push $self.{_atexits}, class {
sub .DESTROY {
function($tmp);
}
};
}
Of course, anonymous classes could be used for much more. Here's a silly
example that doesn't take advantage of the closure aspect at all (and
thus could have been done as a regular class):
sub uc_uri ($uri) {
return class {
sub .as_string { return uc $self.SUPER::as_string }
} inherits('URI').new($uri);
}
my $URI = uc_uri(http://perl.com/;);
I know that this will be serious apple-cart-tilting material, but
I think the long-term advantages could be huge.
I can't see it all yet, but the idea of abstracting vector tables
back a step to include inheritance seems very appealing.
=head1 IMPLEMENTATION
The implementation would require an obvious change to the syntax of
the class declaration.
The syntax would be something like:
class name BLOCK [inherits '(' LIST ')']
This would be a valid lvalue or rvalue.
Closures would have to be associatable with classes, and classes themselves
would have to be made to fit into lexical scope.
=head1 REFERENCES
=cut
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Beating string numerification to death [Was: Re: the handiness of undef becoming NaN (when you want that)]
On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
So then the lexically scoped operator:+ wouldn't be able to achieve
the goal of my suggested implicit numerification warning... the goal
being the ability to ensure that there are no implicit numerifications,
that all numerifications are done via a selected conversion methed.
That's fine, though. You've already got the warning in perl5:
/* from Perl_sv_2nv in sv.c */
if (SvPOKp(sv) SvLEN(sv)) {
if (ckWARN(WARN_NUMERIC) !SvIOKp(sv) !looks_like_number(sv))
not_a_number(sv);
return Atof(SvPVX(sv));
}
So, you don't need operator:+ to do it.
% perl -wle '$x=x;print sprintf(%d,$x), abs($x)'
Argument x isn't numeric in sprintf at -e line 1.
00
Note that once the conversion to number has happened once, it's cached,
and you won't see the warning again. This may or may not meet your
criteria
If you want to warn on conversions even if the number looked numeric, you
could simply add another warning type (e.g. WARN_VERBOSE_NUMERIC) and
then have:
if (SvPOKp(sv) SvLEN(sv)) {
if (ckWARN(WARN_NUMERIC) !SvIOKp(sv)
(ckWARN(WARN_VERBOSE_NUMERIC) || !looks_like_number(sv)))
not_a_number(sv);
return Atof(SvPVX(sv));
}
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Thu, Oct 25, 2001 at 04:53:46PM -0500, Garrett Goebel wrote:
Piers Cawley has written a nice article entitled: Perl 6 : Not Just For
Damians.
I had missed what unary . really did, and this explained it to me. I'm
now much more excited about it as a with-like operator.
It does make me think, though... Would it make sense to have an
accessor operator? For example, in Perl5 I would do this:
sub foo {
my $self = shift;
my $old = $self-{foo};
# So $obj-foo(undef) will work
if (@_) {
$self-{foo} = shift @_;
}
return $old;
}
In Perl6 with the unary ., that becomes:
sub .foo (*@args) {
my $old = $.{foo};
# So $obj.foo(undef) will work
$.{foo} = shift @args if @args;
return $old;
}
So, since this is likely to be fairly common, could we perhaps have
a shortcut?
sub .{foo} () {}
Of course, this is the simple case. In reality, the transformation
would be:
sub .{NAME} () BLOCK
which becomes
sub .NAME (*@args) {
BLOCK
my $old = $.{NAME};
$.{foo} = shift @args if @args;
return $old;
}
The syntax might not be wise. I dunno how I feel about YAUB
(Yet Another Use of Braces). Perhaps some syntax like:
accessor .NAME () BLOCK
But the .{method} syntax does seem to be a very ovious meaning, given
what .{NAME} is going to mean inside of the method.
Then again, we could call it all quits and come up with a naming
convention that allows some members to be automatically exported
as methods, and others to be withheld.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Mon, Oct 29, 2001 at 11:03:33AM +1100, Damian Conway wrote:
Brent asked:
I assume we're going to recycle 'my' and 'our' to be 'instance' and
'class'--is that correct?
That's what I'm proposing.
This seems wise. Very Perlish.
If it's an outer-scope lexical, use Ccaller-{MY}
Ok, I'm all over the nice new features of Perl6, but darnit,
upvar is one of the primary reasons that TCL is unusable. Please,
let's not soften the walls of lexical scope. They're there for a
reason.
If I ever read documentation to the effect:
=head2 CALLBACKS
All callbacks have access to the state of the event
handler through the lexical variables $state and
%state_data in the caller's namespace.
I will defenestrate the offending programmer. Is there any GOOD reason
to want this? Will we ever WANT to write:
class Foo {
my $bar;
sub fu {
my $bar;
}
}
Is that something to encourage? Is accessing a method caller's namepsace
desirable? That seems as bad as the caller accessing the member
variables.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Mon, Oct 29, 2001 at 11:57:47AM +1100, Damian Conway wrote:
AJS How would this play with constants?
class Demo {
my $threshold is const = 100;
Hmm... is a my const the same as an our const? If so, does this mean
that there will be no such thing as a C++-style const (constant per
instance)?
I'm thinking something like:
class Demo {
my $id is immutable;
method INIT ($demo_id is initializer ($id)) {}
is initializer is rather long, but you get the idea.
Does this help Perl at all? Maybe. It depends on the implementation
of the core. Does it help Perl programmers? I think so. It's nice
to be able to state with surety that a member will not be changed
by any of the methods.
Seriously, it would be nice to have a BNF somewhere, even if it changed
every day, and had a few alternates sections... I'd be interested
in starting this if no one else has their heart set on doing it. Perhaps
I could get it into a CVS archive so that we can all edit it on our
own branches.
I'm not proposing anything super-useful for actually cranking out
Perl6's perly.y, but just a high-level view of the operators and
essential syntax.
I'm planning to write a Perl6::Classes module as a proof-of-concept to
accompany my proposal.
Ok. I'll keep an eye out for this, and meanwhile I'll dust off my
BNF skills.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: %MY:: (was Re: Perl 6 - Cheerleaders?)
On Mon, Oct 29, 2001 at 03:03:58PM +, Dave Mitchell wrote: As to whether other uses of %MY:: are Good Things, see previous discussions ad nauseum on -internals and -language. Ok, sorry. I didn't mean to resurect an old, tired thread. I'm sure clear heads will prevail and some precaution will be available. -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Tue, Oct 30, 2001 at 09:59:49AM +1100, Damian Conway wrote:
class Demo {
my $threshold is const = 100;
Hmm... is a my const the same as an our const?
No. 'my' is per-instance; 'our' is per-class.
But, in terms of constants, it seems to me that there's no
difference. They both have only one value that is assigned
when the module/class is parsed.
class Demo {
my $id is immutable;
method INIT ($demo_id is initializer ($id)) {}
is initializer is rather long, but you get the idea.
I'd do that like so (using Larry's preferred syntax):
[...]
method INIT ($idval) { $.id := $idval }
Hm... that looks to me like a regular :=; is it?
If so, what good is is const if you can override it with
a :=? Am I missing something?
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Tue, Oct 30, 2001 at 04:29:15PM +1100, Damian Conway wrote:
I'd do that like so (using Larry's preferred syntax):
[...]
method INIT ($idval) { $.id := $idval }
Hm... that looks to me like a regular :=; is it?
Yep.
If so, what good is is const if you can override it with
a :=? Am I missing something?
That's a binding, not an assignment.
Cis const means: Once declared cannot be *assigned* to.
But that doesn't mean one can't *bind* a new value to the variable
(which would retain its Cconst-induced unassignability after the binding).
I understand that. I guess what I'm saying is, from a conceptual
standpoint, isn't it misleading to say that class Filesystem provides
a constant called MAXPATHLEN, which is 2048, but then to have
the class override that and change it to 1024?!
I understand that we can wag a finger at the person who does this
and tell them that they will have bad luck for seven years.
On a meta-topic, I see many answers in this list (especially from
Larry and Damian) coming back in the form, well, yeah, but
that's not how it works internally.
I suggest that Perl's internals are very interesting, and certainly
very important, but features such as constants instance variables
have meaning to programmers, and if their application in Perl does
not conform to expectation, programmers are likely to have a
rougher time.
Consider the following Perl 5:
# CREATE CONSTANT
*constant = \7;
print $constant\n;
# TRY TO ASSIGN (THROWS EXCEPTION)
eval { $constant = -7 } or print $@;
print $constant\n;
# TRY TO REBIND (WORKS FINE)
eval { *constant = \-7) } or print $@;
print $constant\n;
Yep, but in Perl5, this was never very clean or obvious to the
casual programmer. Constants have been coming of age in Perl,
and they're kind of scary if they're not constant.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Quick question on subroutine declaration syntax
On Tue, Oct 30, 2001 at 03:59:30PM +1100, Damian Conway wrote: (Though I *do* harbour a secret desire to resurrect - as a type specifier: sub foo (@args) - rettype Hmm... I would have expected is to come in here: sub foo (@args) is IO::Handle my $bar - int; Hmm... This, I think is very different. Now you're getting into casting, and I fear a Perl6 that has casting. Next, we'll have to start considering the various types of casting that C++ provides (static, dynamic, etc). Did you think of - as forcing the my expression to return a certain type or to say that $bar is of type int or to say that $bar is whatever it is, but will always be forced into an int when its value is taken (much like the behavior of Perl6 hash keys)? I could see each of those being useful, but I'm not sure they are all neccessary. -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: Constants
On Tue, Oct 30, 2001 at 04:15:46PM -0600, David M. Lloyd wrote: On Wed, 31 Oct 2001, Damian Conway wrote: To me Cis const means: the *value* stored in the memory implementing this variable cannot be changed. Which doesn't preclude rebinding the variable to some *other* memory. But others have a different (and equally reasonable) interpretation of Cis const: the value I get from this variable will always be the same. Then maybe we shouldn't call it 'is const'? Or maybe another tag is needed in addition, like 'is unbindable' for the latter case. Yes, I see the wisdom of not using const here, since it does carry SO MUCH baggage. final has Java baggage. only, stable, ro or firm might be the way to go. unbindable is a bit of a mouthfull... Perhaps fixed or eternal would be good. our $.pi is firm is fixed = 22/7; Has a nice ring to it Of course, so does our $.author is eternal = 'Larry'; Meaning you can have a new author, but only by killing the old one ;-) Speaking of killing the old one, I assume that: $a = 1; $b = 2; $c := $a; $a := $b; Will leave: $c == 1 $a == 2 True? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: General Feelings on Apoc 3
On Tue, Oct 09, 2001 at 08:35:10AM -0700, Brent Dax wrote: Bart Lateur: # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote: # # Binary // # # The analogy to || is probably a bit too clever. My first reaction # was it's some sort of weird division operator. But it's servicable. # # I think it's very cute. I think of it as a skewed or, which is, er, # both what it both is, and what it looks like. If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? I like dor. default also seems natural, but long. Then again, I don't think else is ever legal unless if appears between braces, so that's another possibility if we wish to recycle syntax. $live.happy else die Sad Looks pretty nice. Perhaps confusing if folks think else and or mean the same thing. If else seems to iffish, perhaps it could even be or else, which is also not currently legal, AFAIK $live.happy or else die Sad Hmm gets me thinking evil thoughts... like having else be the low-prec. //, and then or else be synonymous with ``else die $!'' so you get: $live.happy or else Read my lips: NO NEW TOKENS! ;-) -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: General Feelings on Apoc 3
On Tue, Oct 09, 2001 at 11:49:15AM -0700, Tim Conrow wrote: Brent Dax wrote: If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? Oh man. If we've gone so far as 'dor', why not make it 'doh' :-) print stomach_state @beer,@donuts doh burp!!! Well, that opens up a few possibilities... First of all, we'll want to have a unary defaulting operator. For example, $donuts should check the type of $donuts and do the same thing as $donuts is default The universal definition of default should return undef so that $donuts doh burp!!! Would do what you expect. In our next issue, I'll be getting into the intricacies of the chainable diddly-aye-o suffix operator -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: Just a thought...
On Tue, Oct 09, 2001 at 04:18:31PM -0400, Michael G Schwern wrote:
On Tue, Oct 09, 2001 at 11:22:02AM +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier? I quite like the ruby/scheme idiom of
having boolean methods ending in a question mark. eg:
sub is_visible? {...}
I was gonna suggest that pre-Apoc 3 but ran into the same trouble with ?:
Hmm, $obj.meth! is a syntax error, but func! isn't. Damn.
For those of you that don't know, func! is another Ruby idiom that
differentiates between the version of a function that returns it's
results and the one which alters it's arguments in place.
So, could you then apply that to method invocation as well:
$obj.meth1!.meth2!.meth3
I'm just trying to avoid:
$obj is meth1 is meth2.meth3
Which does not scan in my primative primate brain.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: string representations
On Tue, Oct 09, 2001 at 03:13:22PM -0500, Jonathan Scott Duff wrote:
the following would be equivalent:
$a = foo\r\n;
print $a;
print _$a;
print eval(repr($a));
That's probably a poor example of its utility, but I'm not as well
versed in python to give repr() its due in a perl example.
sub repr { my $str = shift; qq{\Q$str\E} }
or, Perl6ish:
sub repr ($str) { qq{\Q$str\E} }
Dunno what it's useful for, but Perl's got it.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: NaN semantics
On Wed, Oct 10, 2001 at 06:20:31PM +0200, Trond Michelsen wrote: BTW, I was thinking once that numeral literals like 4k or 10G (meaning 4*2**10, 10*2**30) would be very nice. What do you think? I think the meaning of the suffices are sufficiently vague as to make me uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case for both, and that's never a good sign. There's always the possibility of supporting SI's binary prefixes ;) http://physics.nist.gov/cuu/Units/binary.html I'm not really fond of 1K meaning anything, but if it's deemed appropos, I vote for the binary meaning. Question on the NIST definitions though: What does 1eie1i mean? I *think* that that's 2^60 times ten to the 1i... correct? Do we have precidence in mind, here? Can I say 1iei? Does anyone *do* that? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: reduce via ^
On Wed, Oct 10, 2001 at 01:27:35PM -0700, Colin Meyer wrote:
On Wed, Oct 10, 2001 at 09:42:58PM +1000, Damian Conway wrote:
John observed:
I just read Apocalypse and Exegesis 3, and something stuck out at me
because of its omission, namely using hyper operators for reduction.
$a ^+= @list; # should sum the elements of @list
Does this mean that
@a ^+= @b;
will add every value of @b to every value of @a?
Yes, that's correct.
Thinking about this, I'm realizing that there's something missing
in map I was trying to think of how this mapped to map's syntax,
and the problem is indexes. It would be very nice if there were some
temporary variable that could be accessed from map that contained
the index.
This is what I mean:
@a = map {$_ + $b[$map_index]} @a;
which is almost the same thing as the previous statement, except for the
behavior on a short @a.
I'm wondering about some other operators Will there be a ^?? operator?
I might, for example, say:
@a = @b ^?? 'yea' :: 'nay';
Which I would expect to be the same as:
@a = map {$_ ?? 'yea' :: 'nay'} @b;
Will unary operators have hyper-equivalents, as well? Will,
@a = ^-@b;
work?
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: NaN+NaNi
On Thu, Oct 11, 2001 at 10:28:34AM -0500, Jonathan Scott Duff wrote: On Thu, Oct 11, 2001 at 11:13:59AM -0400, Dan Sugalski wrote: As for more complex string literals evaluating to numbers, I think that's something best left to either a user-written sub, or user-written fancy parser hacks. Up to Larry whether it goes in the base language, but I think I'd prefer not. Speaking of string turning into numbers ... It's bothered me that I can write 100_000 in my perl code, but if I have a string 100_000 it'll evaluate to 100 when numerified. It would be really weird if 10indigo became 10i, 1e3foobar became 1000, and 10_000 became 10 in Perl 6 IMHO. Perl's been very consistent in not handling strange things in its string-to-number conversion because of the god-awful string processing code that a lot of people have to write to handle stupid file formats. For example, zero-filled numbers are not converted to octal because many text files contain zero-filled numbers. The idea that 0cat is 0, but 0xat is 10 will confuse a lot of folk. If strings in numeric context are treated the same way as the parser would, then I think there need to be warnings for trailing garbage. No, I think if you want 10_000 to be 1, you can always eval it, but I don't think anyone reading in text should expect that. -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: Hyperoperators and RFC 207
On Thu, Oct 11, 2001 at 08:06:15PM +0200, Angel Faus wrote:
Maybe i should better explain myself with an example.
@arr3 = @arr1[^i] + @arr2[^i] # also @arr[^i] = @arr1[^i] + @arr2[^i]
Hyper-operators do this just fine.
@arr4 = $v * @arr1[^i]
$sum =+ @arr1[^i]
@lengths_array = @arr1[^i].length()
These can be done in Perl 5 easily enough with map or foreach:
@arr4 = map {$v * $_} @arr1
$sum += $_ foreach (@arr1)
@lengths_array = map { length } @arr1
I turns out also that RFC's semantics allows much more powerful things
like:
@mat3 = @mat1[^i,^j] * @mat2[^j,^i]
That's more complicated, but doable. I'd personally be happier reading
the code if it used nested for loops
I don't *dislike* the idea, I'm just pointing out that there's a lot
of it already in the language. Perhaps making map/foreach/grep more
flexible with some kind of adverbial modification would be more
effective (e.g. having a way to specify an incrementor variable or
the temporary variable for map would allow nested maps to be more
useful).
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Apropos of nothing...
On Sun, Dec 16, 2001 at 03:55:10PM +1100, Damian Conway wrote: [...] And, just for laughs: $ref = [1,2]; @ary[$ref] = foo(); # probably a syntax error Ok, as far as I can recall, Larry hinted that arrays and references to arrays would be interchangable in many contexts in P6. In this case, I can't see any reason that subscripting would *want* to do a SvIV on a known reference, so I would expect it to obey that logic and treat the reference as an array. Thus, I expect this to be list context for the exact same reason that: @bar = (1,2); @ary[@bar] = foo(); would be. Next question, though: $val = (foo())[0]; List? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: 123_456
On Fri, 2002-01-25 at 12:38, Bryan C. Warnock wrote: On Friday 25 January 2002 12:34, Simon Cozens wrote: Should we be allowed to use _ to group numbers, now that _ is concat? If not _, then what? (if anything?) Sure, why not? '_' is still a valid character in an identifier. You'd still simply need disambiguating whitespace for concatenation. Ok, so the concern is that 100_000 could be (100) _ (000) or 10 It seems to me that the way around this is to change _ to space for numbers. Is there ever a reason to have: 100 000 currently? I can't think of one. Such spaces could easily be noted and removed by the tokenizer early on. Then again, _ still bothers me as an operator. I think it's because Perl has trained me to think of _ as being very flexible and context-sensitive (ala $_, @_, etc). And so, it seems odd that the _ operator should have one fixed, narrow purpose.
Perl6 -- what is in a name?
I'm going to just say this, and I ask that everyone who reads it take a deep breath, count to 10 and then respond if you wish. I was reading Apoc 4 and while marveling at the elegence of what Larry's doing to the language, I had an epiphany. Perl6 is simply not Perl. It's about as much Perl as Perl1 was AWK, C and Bourne Shell. I'm not saying that there's anything wrong with Perl6, or that it's on the wrong track. I love it, and want to start using it tomorrow. However, it is clearly a new species, and just as we do not call Homo Sapiens Sapiens, Homo Erectus 3, I am beginning to come around to the opinion that Perl6 is a poor choice of name for this new language. Aesthetics asside, the name implies continuity, and while that continuity is planned in terms of compatibility modes and anscestral influence, is that really sufficient? If Python X.0 included a Perl5 parser/compat mode and had many Perl features added, would *it* be Perl6? Is it Perl6 simply because Larry is its author (this makes AWK, C2 by extension)? If the language is named Pint (an example, not a suggestion), would this help new users to accept its features on its own terms instead of bristling over every way in which they are not Perl's? I don't know, but it seemed like a topic worthy of some discussion. What I don't want to start (and I may have done so anyway) is a simple name war. If you feel emotionally attached to Perl, then fine, so am I. But if you feel that there is some compelling logic here that will affect the community, I would be very interested. If someone has already brought this up, I appologize. I read as much of this list as I can while still getting real work done ;-)
Re: Barewords and subscripts
On Sat, 2002-01-26 at 12:01, Simon Cozens wrote:
A4 said that there were no barewords in Perl 6. Does this mean that
$foo{bar}
actually should be written
%foo{bar}
Hmm... I'm curious, has anyone yet tackled printf(%d{x},%d{x})? Is
that a bug or does it produce n{x} where n is the value of %d{x} as an
integer?
Mono and Perl6....
Ok, so I read Miguel's message: http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00031.html I drank the cool-aid and now I find myself thinking... should Perl6 compile down to its own byte-code or to Mono's CIL? Miguel feels this is the way to go, and if Mono's bytecode is in fact so flexible that many languages will be able to communicate through it, then perhaps we're shooting ourselves in the feet by NOT targetting Perl6's back-end there. I realize that this has the twin drawbacks of introducing the stigma of a Microsoft technology into Perl's core and moving away from the wonderful work done thus far on Perl6's byte-code. However, if there will ever be a time to make this choice, it would seem that now is it. Some pros: * If Miguel is able to swing the community, Gnome4 will heavily rely on Mono. If Perl is Mono-ready, that will make Perl a much more attractive technology for new Gnome libraries and applications. * If Perl6 uses CIL, then there will be a much larger community supporting the back-end. Also, there will be a ready-made community of people who understand how to integrate Mono-bytecoded applications into their infrastructures (from Web services to development platforms, etc). Just my thoughts
Re: RFC: new logical operator
On Thu, 2002-02-21 at 09:01, Sam Vilain wrote:
On Thu, 21 Feb 2002 06:50:13 -0600
[EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2002 at 12:30:11PM +, Sam Vilain wrote:
I think Perl 6 should have a but keyword, as in:
if (defined $foo but $foo eq ) {
*scratches head*
so... it negates the left side, then ANDs it with the right?
No, but is syntactically equivalent to and in English. It just
implies that the second condition is not generally what you'd expect if
the first was true.
Complete syntactic sugar :)
An off-the-wall thought... If this is not the expected condition,
should it have the extra meaning of an assertion? For example,
defined $foo but $foo eq
could set $! to 'defined $foo but $foo eq ' and, if -w was in use,
issue 'warn Exceptional condition: $!'
Perhaps but introduces more information than you had thought
Is there a unary but? Or would that be never?
Alternatively, this could all be replaced by should:
defined $foo $foo should ne
$foo should == $bar
should $state
should not $state
It's not a hard assertion, just a debugging tool.
should, unlike but would probably always force the expression to be
true. So, 'defined $foo $foo should ne ' would always be true if
$foo was defined (should should become false or die, under use
strict or the debugger?)
A stanalone should not would be useful for unexpected circumstances
that are not important enough to always issue a warning:
exec($prog);
should not;
This brings up the switch idea... (in C terminology because I don't have
time to look up the Perl version right now):
switch ($x) {
case 1: break;
case 2: break;
default: should not;
}
Ok, I think I'm rambling now... off to do more work.
Re: RFC: new logical operator more syntactic maple syrup
On Thu, 2002-02-21 at 19:49, Larry Wall wrote:
David M. Lloyd writes:
: On Thu, 21 Feb 2002, Sam Vilain wrote:
:
: I can't count the number of times I've had to do something like:
:
:if (defined $foo and $foo ne bar) { }
:
: to avoid my program writing garbage to STDERR.
:
: Of course you will now be able to say:
:
: if ($foo // ne bar) { }
:
: Right?
Not quite. You'd have to say:
if ($foo // ) ne bar { }
That's presuming we leave // with the same precedence as ||.
Of course, that's not the same as the original, it just avoids the
warning.
It seems that that may have been the intent, but I'm not sure
Certainly this change would modify the behavior.
I agree that there should be a simple way to say I don't want to be
told about undefined values, but I don't know what sorts of cans of
worms that opens. Something like a property might be better:
my $foo is undefined;
if ($foo ne bar) { }
Such a declaration seems safer than a global, don't warn me about it
directive.
Re: Loop exiting
On Mon, 2002-02-25 at 10:47, Simon Cozens wrote:
given (...) {
...
break;
for (...) {
...
last;
Same concept, different keyword. Good idea?
Larry pointed this out. His reasoning was that given isn't exactly a
loop construct to the user. I know that I'm more inclined to think of it
as a sort of if-like construct. Given that if doesn't pay any
attention to last, I'm not sure that given should.
OTOH... introducing a new keyword is heavy stuff. Perhaps it would be
good to have the last/next/redo/continue syntax be the same as for
loops.
I defer to others for that call.
Re: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?
On Thu, 2002-03-21 at 12:52, Allison Randal wrote:
On Wed, Mar 20, 2002 at 09:59:35AM -0800, Larry Wall wrote:
I should update y'all to my current thinking, which is that $_ is
always identical to the current topic, even if the topic is aliased to
some other variable. To get at an outer topic, you'd have to use the
same mechanism we'll use for redeclared lexicals:
my $foo = $OUTER::foo;
for x {# aliases $_
for y - $y { # aliases both $x and $_
print $OUTER::_;
}
}
I rather like this compromise. It provides the desired behaviour of
always default to the current topic and so eliminates the confusion
between Cwhen and other defaulting constructs. It also maintains the
$_ is default concept, which is quite important to people, as earlier
bits of this thread demonstrated.
Ok, so am I to take it that you could say:
FOO: for x {
BAR: for y {
print $FOO::_;
}
}
Or is OUTER a special-case label?
Personally, I've always prefered this syntax:
for x {\
for y { |
print;-/
}
}
Which is visually appealing and raises coding style arguments to a whole
new level.
Now on to my reasoning for adding emoticons to Perl $;-)
Re: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?
On Tue, 2002-03-26 at 13:19, Larry Wall wrote:
Aaron Sherman writes:
: Ok, so am I to take it that you could say:
:
: FOO: for x {
: BAR: for y {
: print $FOO::_;
: }
: }
Er, I don't think so.
: Or is OUTER a special-case label?
It's a special case like MY::, and somewhat ugly to discourage you from
using it when you should probably be naming your loop variables.
That's too bad. If OUTER could only jump up one level, it's going to be
painful. For example, when you take your example, and go back to modify
the code. It may not be glaringly obvious that adding a middle loop will
cause the code to break.
We're treading dangerously close to putting TCL's upvar into Perl, which
would be a crime against God and man. However, I think you can have a
reasonable syntax for what you want. Use labels as namespaces via a
special syntax. Then, scope labels lexically (already the case?), so you
can't use this syntax to get at callers' namespaces, etc.
Here's an example syntax:
FOO: for x {
BAR: for y {
my $foo_under FOO:= $_;
print $_, $foo_under;
}
}
This takes visual advantage of := as the aliasing syntax while
maintaining the look of a label. Of course, that's just one syntax
possibility. The concept here is accessing lexically-scoped namespaces
via labels.
Given this, you cannot break the code by adding a middle loop, and it's
obvious exactly what was intended.
The other syntax you could use would be less generic, but would really
nail home the idea of topic to the programmer:
FOO: for x {
BAR: for y {
my $foo_under is topicof(FOO);
print $_, $foo_under;
}
}
I don't like this as much, but I see the benefits.
: Personally, I've always prefered this syntax:
:
: for x {\
: for y { |
: print;-/
: }
: }
:
: Which is visually appealing and raises coding style arguments to a whole
: new level.
Hmm, tempting.
Ok, I'll get right on ascii_art_toke.c. I thought I'd never get a chance
to bring machine vision into the Perl core! ;-)
Re: Perl6 Macros
On Tue, 2002-03-26 at 16:26, Michel J Lambert wrote:
An example of where variable capture is needed is:
macro println ($a) {
return EOF;
print $a;
print \n;
EOF
}
for my $b (1..100) {
println $b;
}
Ok, I don't get it. I'm willing to concede that I'm dense, but I need to
understand how.
This looks to me like:
sub println ($a) {
print $a, \n;
}
for my $b (1..100) {
println $b;
}
And, if we inline the sub, the only difference will be...?
Your example seems to involve no variable capture at all, in fact, just
passing parameters to a macro. See below
Personally, I'm at a loss for how macros will fit seamlessly in Perl 6.
The examples above return a string, instead of real code (to make it
easier to see how the interpolation works.) The code passes in a block of
code, which magically gets interpolated back into a string as its original
code form.
I *can* see some advantage in:
macro mygrep ($code is macroblock, *@list) {
my newlist = ();
for list {
push newlist, $_ if $code.();
}
return newlist;
}
x = mygrep {/\S/} $fh.getlines();
where no code reference is ever created. It could be abused mercilessly,
but I can see the massive savings in performance that we would reap,
especially when translating/compiling this code for native or JIT
execution. This is because we don't have to fire a function call each
time we execute the block.
But, perhaps this is too syntax-heavy. Maybe something simpler:
sub mygrep ($code is inline, *@list) {
my newlist = ();
for list {
push newlist, $_ if $code.();
}
return newlist;
}
x = mygrep {/\S/} $fh.getlines();
Now you put it in the compiler's hands to determine if a code reference
should be generated or not. Access to $_ is the only thing that is in
question here, and I don't have a good answer off the top of my head.
It would be very interesting to see how
sub mymap ($code is inline, *@list) {
my newlist = ();
for list {
push newlist, $code.();
}
return newlist;
}
x = mymap {mygrep {$_} split //, $_} $fh.getlines();
would behave. Possibly quite efficient.
Other things which the above 'forintlist' example used was the ability to
send an arbitrary structure to the macro, and have it be matched against
the parameter list for the macro. This allows one more flexibility in
passing parameters to a macro, as they don't need to be a straight out
list/array, but can be more complicatged structures, which are
automagically matched. If this were in perl 6, regular array/list argument
passing could be a simple case of a more complex argument/parameter
passing structure.
I think your ideas here are good. If a general mechanism could be found
for the syntax and deemed valuable enough to add, I'd be all for it.
However, is it really macro-specific or should it be part of the
function call syntax in general?
Re: Perl6 Macros
First impression: Don't go there.
Longer answer:
On Wed, 2002-03-27 at 16:29, Michel J Lambert wrote:
New syntax is 'qs', aka quote sub, which is similar to q, except that it
interpolates all of: ${..} {..} and %{..}
All subroutines which are interpolated, are interpolated as regular text,
with no bindings, so that they get lexically scoped in the code they are
returned as part of.
Then macros essentially return a string which gets interpolated at the
call site.
macro while ($cond, $body) {
return qs{
GENLABEL:
goto ENDLABEL if( ${ $cond } );
${ $body };
goto GENLABEL;
ENDLABEL:
}
}
Ok, ignoring the fact ${ $body } seems to be wildly non-intuitive syntax
for a single-interpolation, I don't see the value of manipulating macros
as string at all. We have eval for that (eval+anon subs+closures is 99%
of what LISP macros are, and I think that's what you're modeling this
after).
Macros could add something to Perl, but I don't see why having a macro
return a string instead of looking and acting like a subroutine would be
a bad thing. In fact, as I pointed out before, you can do almost all of
the scoping stuff that you would want out of a macro in Perl with the
existing subroutine/code ref syntax and a special property.
Again, that would look like (a third syntax actually, but very similar
to what I suggested before):
sub uvula($cond,$body) is macro {
while($cond.()) {
$body.();
}
}
uvula cond = sub{$_ = $fh.getlines() }, body = sub{ print; };
There may be some simpler way to construct the call (this should all be
standard Perl6 syntax, I'm not trying to change anything here), but this
overly verbose invocation avoids my having to demonstrate that I'm not
sure how such things are being handled in Perl6 yet.
You just explode the code ref so that it does not construct its own
scope (actually, it does, in the same way that braces do, but not to the
extent that subroutines do... I'd have to look at the source to remember
the difference there).
The ugliness of the symbols is necessary for the more lowlevel macros that
would compile down to very simple ops, and thus make translation to the
parrot bytecode that much easier. One additional thing the above need is
that either GENLABEL and ENDLABEL need to be renamed by qs() so that
while's within while's don't have problems, or we'd need to follow
Scheme's example of gensym, which constructs unique symbols.
If labels are lexically scoped, There's no problem here. Of course, you
need to promote all lables to the beginning of the enclosing block,
but that's compiler magic, and doesn't violate lexical scoping.
Re: Perl6 Macros
On Wed, 2002-03-27 at 19:46, Michel J Lambert wrote:
Macros could add something to Perl, but I don't see why having a macro
return a string instead of looking and acting like a subroutine would be
a bad thing. In fact, as I pointed out before, you can do almost all of
the scoping stuff that you would want out of a macro in Perl with the
existing subroutine/code ref syntax and a special property.
I disagree here. How would I define foreach as a macro (assuming the
following, simplified syntax).
foreach $each, array, {
print $each;
};
Since $each is being passed to the foreach macro, the macro needs to
create a lexical scoping for $each, and place the third argument as a loop
body, within the context of the scoping it just defined.
First off, I want to say that this is the kind of discussion I joined
p6l for. I respect your point of view here, and don't want my argument
to be taken as lack of validation of yours. I don't have time to code,
so in the long run, my assistance here may be moot.
I think the difference between what we're saying is that you're
insisting on a defered evaluation phase (actually defered parsing, but
let's abstract that a little).
Ok, I see the value of the deferal (which, really is what I was asking
about at first). I think where you will get caught is where the Perl
tokenizer/parser have to look at an expression, determine which parts of
it are to be defered and which parts of it to perform Perl's usual
unholy rites on, and then step forward. I also don't like manual
construction of the macro string, though I understand that it gives you
some flexibility that you can't get otherwise.
Here's what I suggest as a compromise:
macro forall ($iterator, $list, $block) {
my ltmp = ($list);
foreach $iterator - ltmp $block
}
forall{$var}{@list}{{print;}};
Where the parser sees macro NAME PARAMS BLOCK it interpolates ONLY the
variables in PARAMS into BLOCK for every occurance of the macro. The
macro itself is then treated as a quoting operator (I'm uncomfortable
with forall%x%%y%%z%;, but it seems to be an expected consequence of
this way of defining macros). So, the above would become:
my ltmp = (list);
foreach $var - ltmp {print;}
Would that get you everything you want? For things like binary
operators, I don't know. I don't think you want to introduce binary
quoting operators.
This avoids a couple of things that I found hairy in what you proposed,
but does accomplish all of the defered evaluation that you suggested.
- Transformation: they can look inside the structure of their arguments.
Ok, here's where I think you don't want to go. I understand the power,
but now you get into what you had suggested earlier. Basically, a macro
would have to be a subroutine that constructs a string that is your
code. This sets off alarms deep in my racial memory. I see debugability
going near-zero and code maintanence being a not-even-remotely-humorus
joke.
I do think that you need some sort of quotemeta syntax for a macro so
that you can construct a string out of one of your arguments. This gives
you:
marcro assert($expr) {
die Assertion failed: \$\expr\ unless $expr;
}
In this case, I'm suggesting $\name as the syntax for meta-quoting
the macro parameter, but if there's something that would seem more
natural, let me know.
- Binding: I've already explained this one to death. Any operator which
is to alter the lexical bindings of its arguments must be written as a
macro.
Not clear on how this impacts Perl. I do think that a macro expansion
should implicitly comprise its own block. This gives you the ability to
declare lexicals that will evaporate at the end of the macro. However,
if you're talking about
forall{my $x}{@list}{code}
then I think my suggestion covers your case.
- Conditional evaluation: how would you write 'if' or 'and' using
functions?
if is hard because it has variable forms.
I guess you could have:
macro condition(*@pairs) {
for ($expr,$block) - (pairs) {
if (eval $expr) {
return eval $block;
}
}
}
But you're evaluating at run-time, not compile time. I understand why
you would *want* more, but I don't think it's going to be very clean
otherwise.
- Multiple evaluation: this can be emulated by receiving coderefs, and
calling them multiple times. But it requires the caller format them *as* a
coderef.
You can do this the way I propse.
- Using the calling environment: I believe Damian likes this one for
Exporter, and flexibility, and Dan doesn't for optimization reasons.
Macros give the BOBW.
I think that
macro x($a){$a}
x{y}
should evaluate to
{y}
This gives you lexical scope for any declared variables (thus avoiding
needing a gensym type facillity) but allows access to the caller's
namespace.
- Saving function calls: A minor one, which can be emulated with inlined
Re: Perl6 Macros
On Thu, 2002-03-28 at 10:19, Aaron Sherman wrote:
Here's what I suggest as a compromise:
macro forall ($iterator, $list, $block) {
my ltmp = ($list);
foreach $iterator - ltmp $block
}
forall{$var}{@list}{{print;}};
Where the parser sees macro NAME PARAMS BLOCK it interpolates ONLY the
variables in PARAMS into BLOCK for every occurance of the macro. The
macro itself is then treated as a quoting operator (I'm uncomfortable
with forall%x%%y%%z%;, but it seems to be an expected consequence of
this way of defining macros). So, the above would become:
To follow up, and further compromise, you might have a second form of
macro definition:
macro idiv($num,$dev) = {
if ($dev =~ /^(0x)?[0_]+(\.[0_]*)?$/) {
die divide by zero; # Compile-time error
} else {
return int($num)/int($dev);
}
};
I think it will lead to some ugly code that's hard to maintain, but if
you truely want to be able to construct such painful beasts as if,
you're going to need to do this. The win is that without the =, you fall
back on what I suggested previously, and then it looks and behaves the
way I think most people think of macros.
I thought of using the BEGIN keyword after the =, but that would be
confusing (as it would be evaluated every time the macro is seen, not
once as Larry suggests in Apoc4).
You would still treat idiv as a quoting operator after seeing the macro:
idiv{1}{0};
You may also desire to have the normal function-call form of a macro
invocation in order to allow macros to replace functions in libraries.
So, for example:
idiv(1,0);
Which would have to work very hard to defer evaluation (easy here, but
theoretically very hard), but would nominally work the same as the
quoting form.
Re: Tree Transformations (was: Perl6 Macros)
On Sat, 2002-03-30 at 21:41, Michel J Lambert wrote:
Too late. I'm going there... :)
Good for you. I was hoping transformations could make it :)
Why didn't you chime in support before, then? I feel like Aaron and I are
the only ones who are opinionated on this matter...
Hopefully, this has been a productive debate, and I'm not just sucking
up bits on everyone's disk. I tend to assume that when a small number of
people are debating on a mailing list that the others who are reading
are in agreement with one (or more?) of the stated opinions.
Here's something I was wondering. Say you wanted to write a pow() macro
(from a previous example) that would forward to C's pow() unless the
exponent was an integer, in which case it would optimize to many *'s. If
it was called like so:
pow(2.718, 2 * 6 / 3)
Yeah, this is part of the problem of scheduling transformations. I believe
it was mentioned to be NP-complete in the literature I read, but so are
most compiler optimizations, and compilers usually use heuristics, so this
problem shouldn't be unsolveable.
As Nick said in a different email, this particular constant-folding
problem can be solved by using a bottom-up approach.
2*pow(2.718,2*6);
2*6=12
pow(2.718,12)=constant
2*whatever=another constant
It sounds like you're proposing that a macro be executed the way the
peephole optimizations in GCC's RTL are executed (GCC is about the only
other compiler that I know as well as Perl, so pardon the forced
example). This has some merit, and I don't want to discount the idea.
However, I see the following problems that we would have to resolve:
1. The programmer is thinking in Perl (we hope!), but at the stage of
transformation that you're discussing, they will have to manipulate
Perl's internal form which may be structured counter-intuitively to a
Perl programmer.
2. As others have pointed out, a good deal of the magic of Perl is
performed at the syntax, not the grammar level (unlike, for example,
LISP).
In order to resolve these, I think we'd have to drop down to concrete
examples of implementation. What do you see this sort of macro looking
like?
The problem comes in when we allow additions to these transformations. Say
we have a simple arithmetic constant-folding transformation that handles
the operators. The pow operator, when we 'use' it from some module, would
import the pow() constant-folding transformation, or somesuch. It's a bit
of a contrived example since pow() will probably be included by default,
and not be imported, but I think the scenario is still a valid one.
We're speaking about how we manipulate Perl and do the same sorts of
things that the Perl compiler is doing, so I see your example as ideal
(if not practical).
So, let me see if I can get a handle on how your pow might work:
macro pow($a,$b) {
if ($b.is_constant() int($b) == $b) {
my $func = sub { 1; };
for(my $i = 0;$i$b;$i++) {
$func = sub { $func.() * $a };
}
return $func;
} else {
return \CORE::pow;
}
}
I'm not 100% happy with the syntax, but I think it's pretty clear as an
example. First off, there's some things here which look like normal Perl
but aren't so they should be explained:
* $a and $b are not plain scalars. They are objects which represent the
operands to pow(). When evaluated in a numerical context, we try to peer
into $b and determine its value, but undef might be a valid response.
Thus, the test for is_constant.
* Since we're building an anonymous function during compilation, we
expect automatic inlining to take place after macro transformation. Thus
our return value for pow(3,2) would be:
sub { (sub { (sub { 1; } ).() * $a}).() * $a}
But we expect Perl to transform this into:
sub {1*$a*$a}
via inlining and then to inline this subroutine where the macro is being
evaluated. At that stage, Perl will have to root through the tree that
it's injecting and pull out any macro operand objects and replace them
with the variables that they represent. Thus pow(3,2) should become
9 after macro expansion and optimization.
So, think this will handle your case of:
my $y = 0;
forall(my $x, list, sub{$y += $x});
Though the handling of my $x gets a little hairy, and puts some
requirements on macro evaluation that may turn out to be cumbersome.
What I guess I'm saying is that I think I get it. So, what have we
bought? We're not using string handling to build code, and that makes me
happier. But, how much value does this add to the language, really?
If we have these two different constant-folding transformations, no
ordering of them can solve the one I just presented. They need to be
applied in an interleaved manner.
In the worst case, after every transformation, the entire tree needs to be
rechecked for every possible transformation. In this case, these
transformations
Re: The new =~, and chaining statement modifiers
On Wed, 2002-04-03 at 20:49, Larry Wall wrote: : Additionally, can you chain statement modifiers? : : do_this() if $a unless $b; [...] No, still can't chain them. That's a darned shame. In p5, I keep going back to code and finding something like: print foreach x; and wanting to change it to: print foreach x if x 2; or finding this: print $_ if /^X/; and wanting: print $_ if /^X/ for split /\n/; Yes, I know this last one can be accomlished by: print $_ while /^(X.*)/mg; but the former always seems more obvios to me.
Re:http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
On Thu, 2002-04-04 at 11:09, Luke Palmer wrote:
On Thu, 4 Apr 2002, James Ryley wrote:
How 'bout:
$foo = 'def';
$bar = 'ghi';
$y = 'abc$foo$bar';
$z = eval qq{$y};
Of course, for security and correctness reasons, you'd probably want to:
$y =~ s/\\//g;
$y =~ s/!/\\/g;
Why would \\t not double-interpolate to a tab? Also, why would \\
not double interpolate to a syntax error?
Given $(...), you might as well give up on correctness and security. It
seems like you really just want to have a limited version of eval called
interpolate, e.g.:
$z = interpolate interpolate $y;
Then you have ultimate control. Of course, you have to check $ (er, $!)
just like you do with eval.
Re:http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
On Fri, 2002-04-05 at 09:30, Luke Palmer wrote:
On 4 Apr 2002, Aaron Sherman wrote:
$z = interpolate interpolate $y;
Then you have ultimate control.
Uhm, I disagree. I think you really get ultimate control _without_
interpolate. Some people might want to make \\t interpolate to tab, and
some would not. The syntax is simple enough for simple s///'s to take care
of it. And you could say
die Can't interpolate expressions if /$\(/;
And things like that. I think its fine.
Sorry, I guess I have to define my terms.
By ultimate control, I meant that if you have an interpolate command,
you can then do whatever you want at each stage. You could do:
$z = interpolate interpolate $y;
or
$z = interpolate $y;
$z =~ s/\\//g;
$z = interpolate $z;
or
$z = interpolate $y;
die WOOGA! if $z =~ /\$\(/;
$z = interpolate $z;
or whatever. You can do whatever you want. This is faster and more
efficient (I would hope) than:
$z = eval qq{$y};
because you don't have to go through the parser unless the interpolation
invokes an eval.
Re: Bracekets
On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
I'm I beating this point to death, or do I have to write
the RPC:
Keep the {} and [] notation for hashes and arrays
or
Save our array!
Let's boil this RFC down to one short phrase:
If {} goes away in Perl6, then everything you've heard about Perl6 being
not really all that different from Perl5 is either a lie or a damned
lie. People keep saying it's just Perl5, but instead of syntax X, you
now use syntax Y. Well, as both X and Y lists grow longer
I know this is harsh, but really folks, you're pulling Perl apart
looking at a half-dozen good features and building a new language around
them. I don't fault you for this (it's a great way to come up with a new
language), but I'm beginning to get the feeling that going from Perl5 to
Perl6 is going to be almost the same level of effort as going from
Pascal to ANSI C!
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Re: Bracekets
On Mon, 2002-04-08 at 14:56, Piers Cawley wrote: Aaron Sherman [EMAIL PROTECTED] writes: Also, just wondering: $_[_][EMAIL PROTECTED] _=_0_-_ does that work the way I expect it to? Dunno, what do you expect it to do?. To my way of thinking there's going to be a syntax error at the third '_'. But I'm not entirely certain of that. Sorry, I was a little punchy from support calls, and forgot the smily there. The first part of my message was meant to be serious, but this was just to humerously emphasise.
Re: Bracekets
On Mon, 2002-04-08 at 15:09, Mark J. Reed wrote:
On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote:
Also, just wondering:
$_[_][EMAIL PROTECTED] _=_0_-_
does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a syntax error at the third '_'. But I'm not entirely
certain of that.
To me, the third '_' seems like it'd be an unambiguous case of the concatenation
operator. I still can't parse it, however; it looks like an attempt to
modify a non-lvalue:
$_.[_()] _ @_._() _= _0_() - _()
Hmm... meant this to be silly, but this is now bringing up some
important things.
$_[_]
This to me, means
$_ . ['_']
But, only if {} goes away, as we still need the
$x{foo}
behavior, don't we?
_0_
This was my mistake. It would have to be 0_0_, to be a number, which
breaks my perfect string of underscores ;-)
Everything else that you say is as I expected it to be taken. It's
interesting how many people assumed it'd be a syntax error, though
Re: Bracekets
On Mon, 2002-04-08 at 15:12, Piers Cawley wrote: Mark J. Reed [EMAIL PROTECTED] writes: On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote: $_[_][EMAIL PROTECTED] _=_0_-_ $_.[_()] _ @_._() _= _0_() - _() [...] This is where my interpretation fails because the result of step 5 is not an lvalue. How do you know that? '_' could be a method on its LHS that returns and object that responds to _=. But generally, I think it's weird. Yes, I was thinking that there would be lvalue-methods or operator overloading of some sort in the _= Oh the joy of subtle code features, eh?
Re: Bracekets
On Mon, 2002-04-08 at 20:39, Larry Wall wrote:
Aaron Sherman writes:
: If {} goes away in Perl6, then everything you've heard about Perl6 being
: not really all that different from Perl5 is either a lie or a damned
: lie. People keep saying it's just Perl5, but instead of syntax X, you
: now use syntax Y. Well, as both X and Y lists grow longer
Your turn to panic, eh? :-)
I'm not really panicking so much as fretting. I love where Perl6 is
going. Among my favorite new features are named parameters,
typing/propertizing, streamlined OO. I love these features, and wouldn't
want them to go away.
It's just that the more I look at Perl6, the more I think of my days
running training classes. I think about all of the times (even in 1998!)
when people would be confused by something because it didn't work the
same as it did in Perl4.
Perl's history is one of subtly dragging script-hackers from thinking
about code a line at a time to thinking about programming in the large.
Perl 6 continues that trend, but accelerates it exponentally, and I'm
just not sure how ready the audience is.
By the same token, please remember those of us who write Perl programs
like this:
perl -MNet::Ping -nle 'print Ghost DHCP lease: $1
if /lease\s+(\d\S+)/
! Net::Ping-new(icmp)-ping($1)' \
/var/state/dhcp/dhcpd.leases
and
nice du -a | sort -n | tail -300 | tac | perl -nle '
die Require non-zero disk size!\n unless $ENV{DF};
if ($. == 1) {
$total = $_ + 0;
next;
}
($size,$rest) = split /\s+/, $_, 2;
if ($rest =~ /^\.\/([\w.\-]+)\//) {
next if $count{$1}++ = 3;
}
printf %5.1f%% %5.1f%% %11s %s\n, $size/$ENV{DF}*100,
$size/$total*100, $size, $rest;' |\
head -100
This is about 60-80% of what *I* do with Perl on a daily basis. Only
rarely do I get to craft modules and write XS interfaces to internal
libraries.
If the new, spiffy features of Perl6 are out of my reach that 60-80% of
the time, and I have to use perl5compat -nle ..., then the usefulness
of this new language will be largely lost on me.
Oh god... I didn't just show off some of my worst hacks on a public
list, did I? Yikes! ;-)
Re: I'll show you mine...
On Wed, 2002-04-10 at 10:03, Piers Cawley wrote: In message [EMAIL PROTECTED], I wrote: [ A huge wodge of possible perl 6 code ] I'm getting that Warnock's Dilemma feeling here... Did I stun you all into silence? On my clock, your original message arrived at 04:23, and your followup at 10:03. On the west coast of the US, that would be 01:23 to 07:03. That's probably the time you're least likely to get responses. Personally, I'm a little stunned. I wish I could load it into a debuggger ;-) Your idea at the end of regugitating the code back out as Parrot or Perl is just slightly stunning on its own. Still digesting
Re: Defaulting params
On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
sub load_data ($filename) { load_data($filename, 1) }
sub load_data ($filename, $version) {...}
Interesting. This brings goto to mind. Above, I could just assume that
inlining will happen, but what about goto? Obviously:
sub load_data($filename) { goto load_data }
would be ambiguous, and would throw away the (now lexical) $filename.
I can't see any way to usefully preserve the old new meaning of goto. Is
this a good thing?
Re: Unary dot
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
Ah, but I think the mnemonic value of the '.' more than earns its keep
here. Cour $foo is private is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol table (or syte, to use
Damian's oh so clever term from Perl 5+i) and I'm all for things that
are different *looking* different.
Well, I certainly don't like the aesthetic value of them. They are ugly
as Perl 4. But, I have been caught in C++ making all my private variables
_named _like _this, so I suppose it's analogous. But I don't like being
forced to do it that way.
What if you just want a simple struct-like thing? That's when it becomes
really ugly and dislikable. Erm... wait a minute, how would you do that?
$foo = new Foo;
$foo..instancevar = 7;
I doubt that's it.
$foo.instancevar = 7;
This should not be allowed. External code should not access instance
variables. We did discuss the idea that accessors would be created
automatically, and coincidentally, you're using the correct syntax for
that above, but certainly there should be the ability to override the
default accessor and to declare an instance variable as accessor-less.
In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
thought we had agreed that it would flat out be impossible.
Re: Defaulting params
On Thu, 2002-04-11 at 09:59, Ariel Scolnicov wrote:
[Apologies to Aaron Sherman, who gets this twice due to my
dunderheadedness]
No problem. I usually reply to the person and CC the list because some
folks have filters that will make discussions easier if I'm replying to
them vs. sending just to the list. Everyone else can just shut up and
use procmail to filter common message IDs ;-)
Aaron Sherman [EMAIL PROTECTED] writes:
[...]
Also, another thought:
sub foo($a = 1, $b, $c) { ... }
In C++ at least, I think this is an error. However, it seems to me that
in Perl it could be interpreted to be equivalent to:
sub foo($a = 1, $b = undef, $c = undef) { ... }
Which, again, allows us to clean up the common case.
Not really. The problem (and the reason C++ doesn't allow this) is
that
sub foo($a=1, $b, $c=3) { ... }
is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
say what foo(4,5) should do.
Nope. Someone else has already pointed out what they expect the behavior
to be in this case (and I concur), but let me state the rules explicitly
(as I would imagine them):
1. The first default marks the beginning of optional parameters.
2. An optional parameter with no default will automatically default to
undef.
That's it. Simple as pie, and always non-ambiguous.
One could also imagine a rule saying all optional matches occur
right-to-left, no matter where they are; this would be very confusing,
though. It's also a bad idea, software-engineering-wise. Say I start
off with
sub bar($a, $b=2, $c, $d=4) { ... }
So bar(11,12,13) matches 11,12,13 - $a,$b,$c, and bar(1,3) matches
1,3 - $a,$c. All seems well, until I decide that since anyway $c is
usually 3, I should change the signature and make $c optional too:
Yikes! I would never do that. Let me re-state my example:
sub foo($a = 1, $b, $c) { ... }
would be the same as
sub foo($a = 1, $b = undef, $c = undef) { ... }
So your example would silently become:
sub bar($a, $b = 2, $c = undef, $d = 4) { ... }
This is much easier to understand. Here are some permutations:
bar(1) = bar(1,2,undef,4);
bar(1,3) = bar(1,3,undef,4);
bar(1,3,8) = bar(1,3,8,4);
bar(1,undef,3) = bar(1,undef,3,4);
The only thing that gets a little tricky is named pairs:
bar(d=1) = error: a not defined
bar(a=1, d=8) = bar(1,2,undef,8);
Makes sense, no?
Re: Unary dot
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
Aaron Sherman writes:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
[...]
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
We're in violent agreement ;)
What I was saying was that C$.x ne C$obj.x. One is directly
accessing an instance variable and one is an accessor (which may in fact
be optimized by the compiler in some cases, but the control still lies
in the hands of the class author). Further, I was refering to a previous
thread (no ref handy) where it was stated that instance variables would
be private and accessors would be created automatically (which you
reiterate and clarify in your response here).
I agree that there may be code that looks an awful lot like hash access,
and in practice some of those usages may even BE simple hash access
after compiler optimization. The key difference is that that is all
under the control of the class author (or rather the class author has
the right/ability to give up control). When the author wishes for
something that looks like instance variable access to become a remote
procedure call or have some taint checking performed, this too should be
their choice (and hopefully would not have to involve any Ctieing or
the like, but would instead fall neatly out of the way accessors work).
I think you have agreed with the above, but I was stating it too quicky
in my original post, and it came out like a statement that the syntax of
instance variable access would never be allowed again, when I was only
refering to the semantic.
Re: Defaulting params
On Thu, 2002-04-11 at 11:55, Aaron Sherman wrote:
1. The first default marks the beginning of optional parameters.
2. An optional parameter with no default will automatically default to
undef.
Interestingly, I just said something that I did not mean to, but it
opens up an interesting avenue. As I understand it, right now we have:
sub foo ($a;$b, $c) { ... }
Which indicates taht $b and $c are optional.
If we go with the above defaulting rules, we could dump the semi-colon
(to be re-used for something else?) in favor of:
sub foo ($a, $b=undef, $c) { ... }
Slightly longer, but a unifying syntax between defaulting and optional
parameters!
Speaking of defaults, has anyone talked about C++'s instance variable
defaults? I don't like thier system, but the case of:
const myobj foo(1,2,3); // C++
Is a tough one. As I understand it, in Perl that's:
my $foo = myobj.new(1,2,3) but const;
Or is that
my $foo is myobj(1,2,3) but const;
Either way, is the constructor allowed to manipulate the embryonic $foo?
For those who don't know, in C++ this is resolved by the following
syntax:
class myobj {
...
int a,b,c;
myobj(int aa, int bb, int cc) :
a(aa), b(bb), c(cc) const {}
...
};
Notice that the constructor itself does nothing to this const instance
that is being contstructed by the instance variable defaults.
It's a fine syntactical line, and I don't like how much the compiler has
to think about what Ca(aa) really means. But, I have to admit I'm at a
loss for other ways to allow safe compilation of const instantiations.
Re: Defaulting params
On Thu, 2002-04-11 at 12:44, Luke Palmer wrote:
class myobj {
...
int a,b,c;
myobj(int aa, int bb, int cc) :
a(aa), b(bb), c(cc) const {}
...
};
Ummm no. Straight from Bjarne: You can't have a const constructor. You
just do what you did without the const. A const myobj is essentially
equivalent (with the exception of not being allowed to call methods not
marked 'const', except the constructor) to:
I'm not much of a C++ fan, as you can tell. What he said, but my point
stands in a somewhat modified capacity
Do we have a way to do this, or do we not do it, or do we adopt a silly
C++-like style?
Re: Defaulting params
On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
Miko O'Sullivan writes:
: Well, I had been hoping to appeal to the mathematical mindset of the list,
: but there is a second reason for = in addition to / /=: it's simpler to
: understand. I just think that the potential Perl hackers will understand =
: right away but will have to spin a lot of cycles to get / /=, and will
: meanwhile be wondering why not just =. I'm hoping to point out that = is
: both logically precise AND more marketable.
Leaving marketability aside for the moment, I don't buy the argument
that it's a feature for the user to be able to pass an undef past the
default. The primary purpose of the default is to guarantee the
semantics of the function, not to make life easier for the caller.
If that also happens, it's a nice side effect.
Hmmm... I have to disagree with you there.
Consider this bit of Perl5 which I've done in various forms:
sub nukeuser {
my $user = shift;
my $pwf = shift;
$pwf = '/etc/passwd' unless defined $pwf;
my $backup = _ ? shift _ : $pwf.bak;
my $do_backup = defined($backup);
...
}
Notice that we have two different types of defaulting here. The second
argument is the file to work on, and we set it to a reasonable default
if it is undefined for whatever reason. However, the third argument is
sensitive to undef vs no parameter. In the case of not getting a third
arguement, a reasonable default is set. If an argument is given, but it
is undef, no backup will be performed.
We're not just makeing life easier for the caller. What we're doing is
extracting as much information from the arguments as possible (just as
many Perl functions do). With //=, there's simply some data thrown away.
In Perl6, this might be:
sub nukeuser ($user, $pwf //= 'passwd', $backup = $pwf.bak) {
my $do_backup = defined $backup;
...
}
[I don't know if you can use a parameter to default another parameter.
It would be nice, but I can see why you wouldn't.]
Without an = operator here, you would need to add another argument to
flag doing backups or not (not really the Perl Tao) or you would have to
do the argument processing manually, which sort of defeats the whole
point.
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
Perhaps
sub printRec(-$rec)
I'm just throwing that out, but some way to say that the argument
defaults to getting the topic would seem to be called for.
Re: Defaulting params
On Fri, 2002-04-12 at 00:37, Melvin Smith wrote:
At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
Notice that we have two different types of defaulting here. The second
argument is the file to work on, and we set it to a reasonable default
if it is undefined for whatever reason. However, the third argument is
sensitive to undef vs no parameter. In the case of not getting a third
arguement, a reasonable default is set. If an argument is given, but it
is undef, no backup will be performed.
So we have undef and reallyundef? :)
Yes, just as with any array. We always have an exists() vs defined(). We
also have a length.
An argument list has a length and each element either exists or does
not. An undefined parameter still exists, of course. Is this not basic
Perl?
[I don't know if you can use a parameter to default another parameter.
It would be nice, but I can see why you wouldn't.]
Without an = operator here, you would need to add another argument to
flag doing backups or not (not really the Perl Tao) or you would have to
do the argument processing manually, which sort of defeats the whole
point.
I would typically handle this with overloading the function instead.
Its definitely easier for the reader to understand that way, in my opinion.
Ok, let's take my example and try to do it with overloading:
sub nukeuser ($user,$pwfile //= $pwdfl) {...}
sub nukeuser ($user,$pwfile //= $pwdfl, $backup) {...}
Question, are you proposing that this is valid? Would I need a second
//= on the $backup? Which version would nukeuser('ajs') call? Which one
would nukeuser(backup = $x, user = $y) call (I *think* that one is
obvious to me, but I don't see how it's obvious to the compiler).
You're proposing a whole lot more coding for the user than:
sub nukeuser ($user,$pwfile//=$pwdfl,$backup=$pwfile.bak) {...}
Which, seems to also be easier on the eye, at least to me. Granted, the
//= looks a little funky, but that's the syntax we already had. I'm just
proposing the simpler one be added.
Else your function prototypes become a language of their own.
Having two operators is hardly a language of their own if it is, then
having the one operator is half a language? ;-)
I wish we would stick to simple semantics, allow overloading, allow
a single operator for a default argument, and follow the C++ style of
ambiguity resolution.
The C++ style of ambiguity resolution does not involve passing parameter
pairs, list explosion, etc. These are all features that Perl6 will have
from the gate, so I just don't see how Perl6 can have the same approach
as C++.
What's more, in C++,
void foo(const char* a=stuff){ ... }
foo(NULL);
will pass NULL, not stuff. We're proposing a syntax which is incapable
of that distinction. :-(
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 09:52, Jonathan Scott Duff wrote:
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
If $_ is lexical by default (did larry say this somewhere?), then I'm
sure we can make it dynamic on request ala:
Nope, I don't think that works. If the caller of printRec has to do
something special, we're meeting the original request which is to be
able to write print, which scoops up $_ without any special case code.
Now, we can say, you just can't ever write print. I can understand why
we would, but why NOT just allow the subroutine author to indicate that
the subroutine acquires the current topic as a parameter default? It
would seem nice and clean. Either
foo($a=$_){}
as Graham suggests, or
foo(-$a){}
which was mine. Either one works. I guess with the aliasing of $_,
Graham's seems cleaner to me.
Of course, the other conversation pending, we might end up with:
foo($a//=$_){}
which doesn't do the same thing as print, but may be the best we can do
with the syntax we have.
I read the original posters message the same as Piers though.
Ok, what did you get from it that's different?
Hashes, Stringification, Hashing and Strings
In this example:
%hash = ($a=$b);
$a can be anything. In fact, since Perl6 promises to retain the original
value of $a, we're rather encouraged to store complex data there. But,
this poses a problem. The key to use for hashing might not ideally be
the string representation.
For example, if I'm hashing a collection of special file objects, it
might be useful in one context to do:
method operator:qq () {
return read_whole_file();
}
But, if I have 100 of these objects, and I try to put them in a hash,
life could get ugly fast!
More helpful would be to have this builtin:
method operator:hash () {
return operator:qq();
}
and then allow me to override it in my class like so:
method operator:hash () {
return filename();
}
This allows me to specify separate hashing and stringification methods,
but retains Perl's original default of combining the two.
Re: Hashes, Stringification, Hashing and Strings
On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
Speaking of which, how do we ensure the immutability of keys being put
into the hash? I think Perl copied the string, so that:
$b = aa;
$a{$b} = 1;
chop $b;
print $a{aa};
still works.
If we start storing full thingies into the keys of a hash, we either need
to make deep copies of these, or copy enough to ensure the hashing
function has all that it needs.
I thought about this myself, and I don't think Perl would do it that
way. Please, Larry, et al. correct me if I'm wrong.
I suspect it would involve:
1. Copying the key (which might be a reference) on insertion.
2. Hashing once, and caching the hash.
This means a minimum of overhead, so it's a good thing. It also means
that the structure of your hash would never need to re-compute if the
hash of a particular object changes (which I would imagine it could
easily do in any number of cases).
Re: Hashes, Stringification, Hashing and Strings
On Tue, 2002-04-16 at 14:57, Piers Cawley wrote:
Aaron Sherman [EMAIL PROTECTED] writes:
I suspect it would involve:
1. Copying the key (which might be a reference) on insertion.
2. Hashing once, and caching the hash.
This means a minimum of overhead, so it's a good thing. It also means
that the structure of your hash would never need to re-compute if the
hash of a particular object changes (which I would imagine it could
easily do in any number of cases).
So you'd have:
%hash{$some_obj} = $aValue;
$some_obj.mutator;
exists %hash{$some_obj} # returns undef.
Somehow I *really* don't think that's going to fly.
Personally I'd like the default hash to return some immutable, unique
and probably opaque object id (something the like
'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
probably not identical). This isn't going to change as an object's
contents change.
I don't see why your above example would behave as you suggest. Larry
has already put in his TMTOWTDI comment, but let's look back at what I
said, using your example:
%hash{$some_obj} = $aValue;
1. Copy the key (possibly a reference)
%hash.magic_key_store($some_obj)
2. Cache the hash of that key
%hash.magic_hash_store($some_obj.hash())
Now, you suggest:
$some_obj.mutator;
exists %hash{$some_obj} # returns undef.
Well, if you want that behavior, I'm sure you can get it by redefining
hash() (or whatever the operator/method/whatever is called), but I don't
suggest it in the normal case. By default, as I've suggested in previous
mail the string representation should be used for hashing, which would
lead to that second statement returning true, since $some_obj still has
the same string representation.
Then again, if you're hashing by (as in my previous example) file name,
then you might want to change the hash of your object when it represents
a different file (say, you call an open method on it). There's good
cause to want to do that.
What I was saying above, however, was that you don't want to have to
re-compute your internal hash structure on the fly, hence caching the
hash of your object. That way, if an object returns a 1k block from
/dev/random as it's hash, you don't re-build the entire hash every time
you access an element, which would be absurdly unfortunate. Is there
ever a reason to want to do that?
Re: Cfor loop variations
On Wed, 2002-04-17 at 11:23, Jonathan Scott Duff wrote:
On Wed, Apr 17, 2002 at 01:38:59PM +0100, Piers Cawley wrote:
I've got the horrible feeling that doing it this way will lead to
nasty ambiguities in parsing, but if that's not the case then I must
confess that I prefer this syntax. Especially if you want to do
something like:
for a, b ; c, d - $x ; $y {...} # Apocalypse
for a, b - $x ; c, d - $y {...}
I think the second version of that looks cleaner, but neither of them
is exactly gorgeous.
And while we're at it, could someone write out the equivalent of this in
perl6 without the use of the - or the funny for syntax? I find it hard
to think of - as synonymous to sub with either syntax above.
As usual, I'm coming into this late, and so I'm going to sound a little
wild-eyed (how do I *sound* any such thing, you may ask...)
I think this syntax is sensible in concept, but in practice, it breaks
down into incomprehensible very quickly.
If I step, back, the goal was this, right?
for LIST[;LIST...] - ARG[,ARG...][;ARG[,ARG...]...] BLOCK
It seems simple enough, but we're getting hung up because of the
multiple list thing...
I agree that while
for LIST - ARG[,ARG...] [; LIST - ARG[,ARG...]...] BLOCK
may LOOK, better, it's very broken WRT the idea that -x is sub(x) in
disguise (with topicalization, of course), and it's still hard to read,
just not AS hard.
What you're trying to have is a loop union construct, and semicolon is
fairly hard to interpret in that way. However, since this is not likely
to be the common case (not rare, but uncommon) Larry's Huffman-style
coding of syntax would seem to suggest that a longer operator is called
for anyway.
for LIST - ARG during LIST - ARG BLOCK
would seem to fit nicely (notice I'm simplifying ARG to save typing
here, but the complex case still holds), and if you accept that this is
a special case short-hand for:
for LIST - ARG during for LIST - ARG BLOCK
then you have two loops sharing a block in a well defined way to create
a single closure, and yet it stays fairly readable. Want more?
for a - $a during - $_ during 0 .. Inf {
last unless exists $a exists $_
...
}
If you read this as you do in English, the length of the last during
clause should control the length of the loop, so this is a nice way to
say keep looping until both are exhausted. After all, if you eat popcorn
during the big game, you don't stop watching the big game when the
popcorn runs out, but you stop eating popcorn when the game is over (at
least, I would).
This gets ugly when you mix in traditional C for (are we keeping that in
Perl6?):
for a - $a during for ($i=1000;$i$a;$i-=$a) {...}
but not by a whole lot.
Re: Please rename 'but' to 'has'.
On Sun, 2002-04-21 at 10:59, Trey Harris wrote: 0 has true my first reaction would be, huh? Since when? Dare I say... now? ;-) Sorry, someone had to say it. Personally, even though it sucks up namespace, I think what we're seeing here is a need for more than one keyword that are synonyms. but and now seem to cover a good deal of ground. 0 now true Is misleading, IMHO, as 0 is not now true. 0, in this context is an expression, and we're saying that that expression is now true. but conveys this much more clearly. However, as many have pointed out, there are a number of cases where but is equally misleading. Is there any problem with allowing both but and now? It might even be elegant to use both at the same time: $x now integer but true which is clearer to my eye than $x now integer now true which seems to change the properties of $x twice without reconciling the changes with each other. In any other language this would be unthinkable, but I think it fits nicely with Perl's philosophy. Not TMTOWTDI, which I think is often used to excuse the inexcusable, but the idea that Perl reflects the ways in which humans use language. We want to convey shades of meaning that do not translate directly to action. So, have I just lost it, or would it make sense to have now and but? Apologies to the person who started this thread. I know you thought has was ideal, and I understand why. It's just that between but and now, I think you get more ground covered than you do with has and either one.
RE: Regex and Matched Delimiters
On Sat, 2002-04-20 at 05:06, Mike Lambert wrote:
He then went on to describe something I didn't understand at all.
Sorry.
Few corrections to what you wrote:
To avoid the problem of extending {} to support new features with a
character 'x', without breaking stuff that might have an 'x' immediately
after the '{', my proposal is to require one space after the { before the
real regex appears.
I hope that you mean one or more whitespace characters, not just a
space. The following would be correct, no?
/{|
.*
}/
Anything else would seem rather confusing to the average Perl
programmer.
Re: Regex and Matched Delimiters
On Sat, 2002-04-20 at 14:33, Me wrote:
[2c. What about ( data) or (ops data) normally means non-capturing,
($2 data) captures into $2, ($foo data) captures into $foo?]
Very nice (but, I assume you meant {$foo data})! This does add another
special case to the regexp parser's handling of $, but it seems like
it would be worth it.
Makes me think of the even slightly hairier:
{foo data}
or even more hair-full:
{{$foo} data}
for references.
Where you capture into the usual positional, and then invoke foo with
the variable as parameter.
Would be pretty nice closure-wise:
sub match_with_alert($re,$id,$ops,$fac,$pri) {
openlog $id,$ops,$fac;
my $alert = sub ($match) {
syslog $pri, Matched regexp: $match;
}
return study /{{$alert} $re}/;
}
my $m = match_with_alert('ROOT login',$0,0,LOG_USER,PRI_CRIT);
for - $_ { /$m/ }
That would certainly be a handy thing that would set Perl apart from the
pack of advanced regexp languages that don't support closures
Some other things come to mind as well, but I'm not sure how evil they
are. For example:
sub decrypt($data is rw) {
$data = rot13($data);
}
print The secret message is: , /^Encrypted: {decrypt .*}/,
\n;
Re: Regex and Matched Delimiters
On Mon, 2002-04-22 at 14:18, Me wrote:
Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)( data)
(?opsdata)(ops data)
({}) {}
I don't like that particular way of looking at things, but either way my
comments about subroutines and closures still holds.
Re: Please rename 'but' to 'has'.
On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
Perl 6 will try to avoid synonyms but make it easy to declare them. At
worst it would be something like:
my sub operator:now ($a,$b) is inline { $a but $b }
I see your point, and it makes sense, but how will precedence work? What
would this do:
$i now foo but bar and 2;
or this:
$i but foo now bar and 2;
What if I want to define a synonym for and?
sub operator:also ($a,$b) is inline { $a and $b }
print $_ also die;
Scratching my head here in userville
Re: Regex and Matched Delimiters
On Mon, 2002-04-22 at 21:53, Larry Wall wrote:
* Parens always capture.
* Braces are always closures.
* Square brackets are always character classes.
* Angle brackets are always metasyntax (along with backslash).
So a first whack at the differences might be:
[...]
space sp (or \h for horizontal?)
{n,m} n,m
\talso tab
I want to know how he does this!! We sit around scratching out heads
looking for a syntax that fits and refines and he jumps in with
something that redefines and simplifies. Larry is wasted on Perl. He
needs to run for office ;-)
\Lstring\E\Lstring
\Ustring\E\Ustring
This one boggles me. Wouldn't that be something like:
tolower string or tolowerstring/tolower # ;-)
Seriously, it seems that \Lprior would be confusing.
\Q$var\E $varalways assumed literal, so $1 is literal backref
$var $var assumed to be regex
Very nice. I can get behind this, and a lot of people will thank you who
have to maintain code.
=~ $re=~ /$re/ ouch?
If $re is a regexp, wouldn't $str =~ $re turn into $re.match($str)?
Perhaps $re.m $str which is no more typing and pretty clear to me.
Obviously the word and word:... syntaxes will be user extensible.
We have to be able to support full grammars. I consider it a feature
that foo looks like a non-terminal in standard BNF notation. I do
not consider it a misfeature that foo resembles an HTML or XML tag,
since most of those languages need to be matched with a fancy rule
named tag anyway.
It's too bad that /tag would be messy with standard Perl //-enclosed
regexes, as it would be a nice way to pass parameters to user-defined
tags. It would also allow XML-like propagation of results:
fooxbary/barz/foo
Re: Regex and Matched Delimiters
On Tue, 2002-04-23 at 04:32, Ariel Scolnicov wrote: Larry Wall [EMAIL PROTECTED] writes: [...] /pat/x /pat/ How do I do a no /x? I know that commented /x'ed regexps are easier reading (I even write them myself, I swear I do!), but having to escape whitespace is often very annoying. Will I really have to escape all spaces (or use sp, below)? I'm not sure that that's a bad thing. Regular expressions are the hairiest, ugliest thing in Perl. If they change in this way, I see them getting a tad more verbose, and a whole lot more readable and maintainable. Besides you can always do this: $str = COPYING file for more information; /$str/ since scalars will be interpolated as quoted by default.
Re: Regex and Matched Delimiters
On Tue, 2002-04-23 at 12:48, Larry Wall wrote:
Brent Dax writes:
: # \talso tab
: # \nalso lf or nl (latter matching
: logical newline)
: # \ralso cr
: # \falso ff
: # \aalso bell
: # \ealso esc
:
: I can tell you right now that these are going to screw people up.
: They'll try to use these in normal strings and be confused when it
: doesn't work. And you probably won't be able to emit a warning,
: considering how much CGI Perl munches.
I can see pragmatic variants in which those *do* interpolate by default.
And pragmatic variants where they don't.
If you put them in one, put them in the other, HOWEVER, there's a strong
pragmatic reason for neither that i can see.
HTML/XML/SGML
I hate to say it, but if interpolates in everything cleanly with no
overloading, the *ML camps will thank you deeply. How often I've
written:
qq{foo$content/foo}
I cannot tell you, but it's large.
Why not use {} for this and add an {eval:code}?
I'm just wondering how far I can drive the principle that {} is always
a closure (even though it isn't). I admit that it's probably overkill
here, which is why there are question marks.
I like the idea, but I don't think it fits. On the other hand, if inside
all interpolating operators {} is the special thing that gets
interpolated (and NOTHING else), I could see liking the new look:
qq{a${x}b} = qq{a{$x}b}
qr{a\Q${x}\Eb$} = qr{a{q:$x}b$}
qr{a${x}b$} = qr{a{$x}b$}
q{a}.eval($x).q{b} = qq{a{e:$x}b} or qq{a{{$x}}b}
ajs\@ajs.com = qq{[EMAIL PROTECTED]}
ajs. @{ajs} ..com = qq{ajs{@ajs}.com}
I know it's a departure from your original idea, but it certainly
unifies the syntax nicely:
qq{Hello, World!{nl}}
qr{Hello, World!{nl}}
With respect to Perl 5, I'm trying to unhijack curlies as much as possible.
Ooops :-)
Re: Loop controls
On Thu, 2002-04-25 at 18:20, Damian Conway wrote:
Miko O'Sullivan wrote:
before { ... } # run before first iteration,
# only if there is at least one iteration
Larry is still considering allowing a CFIRST block that would do this.
[...]
This will be called a CNEXT block. It goes inside the loop block.
[...]
This will be called a CLAST block. It goes inside the loop block.
[...]
Celse blocks to accomplish this.
This bothers me. Traditionally, all-caps keywords in Perl have indicated
compile-time constructs that may relate only loosely to the code around
them (e.g. BEGIN, END).
Why would these keywords need to be set off in this fashion? Is there
something dangerous about:
for x-$y {
first { ... }
...
next { ... }
last { ... }
} else {
...
}
I can see next and last being confusing, and you might want to choose
other keywords, but making them upper-case doesn't really eliminate the
confusion.
Also, first is perhaps a poor keyword itself. What about this case:
for x-$y {
if (defined $y) {
first { ... }
}
}
Does that work?
Re: Loop controls
On Fri, 2002-04-26 at 14:11, Allison Randal wrote:
On Fri, Apr 26, 2002 at 08:49:23AM +1000, Damian Conway wrote:
Hmmm... how about:
for $results.get_next() {
print $_;
LAST { print Done.; }
ELSE { print No results.; }
}
The else of a loop construct isn't really the same as the else of an
Cif. You can't use an Celsif for one thing. And the condition for
Why not? What would be wrong with:
for x {
...
} elsif (stuff) {
...
} else {
...
}
Of course it brings other less wholesome things to mind like elsfor
and elsloop and if ... elsfor and for ... elsif ... elsloop ...
else, but why not?
reaching the else is different too, it isn't always a false value,
Yes it is.
sometimes it's no values to iterate over or condition met before
first execution of loop.
while(x) { ... } / if (x) { ... }
while($x) { ... } / if ($x) { ... }
These are different how? To my eye, the only difference is what happens
at the end of the block. In fact,
while ($x) { ... ; last; }
is an if.
I can also think of some advantages to having the else within the
scope of the loop. You might want your object to return a false value
from .get_next() (one that Cfor will see as non-iterate-able) but that
still contains some interesting properties that can be used by the
else. If the else followed the loop this value wouldn't be in scope.
This is something I had not considered, but sounds very cool.
sub alllines ($file) {
my $fh;
if ($fh = IO::File-new($file)) {
return $fh-getlines;
} else {
return $! but false;
}
}
while alllines(/etc/passwd) - $_ {
...
} else {
die /etc/passwd: $_;
}
Yeah... I like it.
Re: Loop controls
On Fri, 2002-04-26 at 19:06, Allison Randal wrote:
On Fri, Apr 26, 2002 at 05:24:13PM -0400, Aaron Sherman wrote:
Of course it brings other less wholesome things to mind like elsfor
and elsloop and if ... elsfor and for ... elsif ... elsloop ...
else, but why not?
Urk. And why?
Besides, I would expect an Celsfor to actually be a loop of it's own,
on the principle of elsif = else + if so elsfor = else + for.
Absolutely what I thought. elsif would be for thing else if where
elsfor would be thing else for-loop. Since you got this distinction
right off, it sounds like an intuitive enough syntax.
Yes, but there's a difference with Cwhile in that you wouldn't want an
else to execute anytime the Cwhile came across a false value, but
only if the *first* value it came across was false (i.e. only if the
loop isn't going to execute at all). Otherwise, you'd just use a LAST
block (a parallel that I think argues for ELSE blocks).
This is just going up a level in terms of what you're looking at. If I
wrote this:
if (!grep {$_ eq 'foo'} bar) { ... }
You wouldn't find it confusing that the block only executes if NO
element of the array bar is 'foo'.
So, this should not be confusing either:
$i=0;
loop ;$i$max;$i++ { ... } else { ... }
In this case, if $max = 0, then you will execute the else.
And Cfor and Cloop are even more different. You could kind of
stretch the point and say that the evaluation of the second expression
is the false value, I'll give you that. But it still has the same
problem as Cwhile.
$i = $somevalue; # possibly set by user input to 5 or higher
...
loop ; $i 5; $i++ {
...
}
And where's the false value here? The else would be more of no
values to iterate over.
Again, it's just first derivative over time. You're not asking is there
a false value, you're asking is the loop false. Just as we understand
that an array in a conditional context is false if it is empty, so too
is a loop false if it is empty. This is a basic Perl concept, and it
makes sense to promote it from static arrays to more dynamic loops.
I can also think of some advantages to having the else within the
scope of the loop.
while alllines(/etc/passwd) - $_ {
...
} else {
die /etc/passwd: $_;
}
But the aliased value, $_, is restricted to the scope of the Cwhile's
block, it isn't going to be accessible in the block associated with the
Celse (you would be getting some $_ from an outer scope).
You're thinking of loops in a curious and convoluted way, Try this out:
{ loop-keyword [ conditional/declaration ]
block
{ else-clauses ...} }
The loop itself comprises an outer scope in which the conditionals or
declarations exist. Then, each block comprises a sub-scope. In this way,
there is no confusion, no special case, no violation of the rules.
It becomes reasonable now to have:
for a - $b {
stuff using $b
} elsfor c - $d {
more stuff using $b and $d
} else {
yet further stuff with access to $b and $d
}
And what a neophyte programmer might expect about access to variables is
all true.
Re: Loop controls
On Fri, 2002-04-26 at 19:30, Miko O'Sullivan wrote:
Of course it brings other less wholesome things to mind like elsfor
and elsloop and if ... elsfor and for ... elsif ... elsloop ...
else, but why not?
Well, I agree with the concept, but boyoboy those names ain't gonna
fly. We'll have to head down the road of
unlessfor
Why? We don't have an unlessif, why would we ever have unlessfor?!
elseuntil
I would expect that to be elsuntil, but as we're dropping until from
the language, it's a moot point.
unlessuntil
See above.
Two issues spring to mind:
1) Do we have a reality check on why this syntax is needed? I agree it's
cool idea, but can anyone name a real-world scenario where it would be
useful? Can we do things just bcause they're cool? That approach didn't
work too well for me as a teenager, but then nothing else did either.
It's not because it's cool. It's because the alternative is:
Perl5:
$did = 0;
for($i=0;$i$max;$i++) {
...
}
unless ($did) {
foreach (x) {
...
}
}
Perl6:
loop $i=0;$i$max;$i++ {
...
ELSE {
for x - $_ {
...
}
}
}
Proposed Perl6:
loop $i=0;$i$max;$i++ {
...
} elsfor x - $_ {
...
}
Points for last option:
1. Cleaner code
2. Scope is cleaner. Why does the we never executed this block code,
have to exist inside of the block's scope? What are we preserving?
At the very least, moving the else out of the block makes sense, but I
think preserving elsif is useful as well. The fact that that calls for
the possibility of elsfor, elseloop, etc, is IMHO just a nice extra.
Re: Loop controls
On Sat, 2002-04-27 at 01:14, Luke Palmer wrote: On Fri, 26 Apr 2002, Allison Randal wrote: Besides, I would expect an Celsfor to actually be a loop of it's own, on the principle of elsif = else + if so elsfor = else + for. So, you're suggesting we add Celsunless then? Just because it's possible doesn't mean it's necessary. Not a bad idea. It doesn't strike me as being quite as helpful as the conditional loops, but you could probably talk me into it.
Re: Loop controls
On Mon, 2002-04-29 at 10:41, Jonathan Scott Duff wrote:
On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
I would expect that to be elsuntil, but as we're dropping until from
the language, it's a moot point.
Er, what?!? Who said we're dropping until? Did I miss something?
Well, if there's no while (replaced by generic loop, per Apoc4) why
would there be an until?
Proposed Perl6:
loop $i=0;$i$max;$i++ {
...
} elsfor x - $_ {
...
}
Hrm. Do you also propose an elsloop too? I think a general else
or otherwise on all loops allows what you want:
Ok, once more for those in the cheap seats (no offense, it's just a lot
of people seemed to have ignored the thread until now and jumped in
without the context), this is how we got here:
1. Larry says loops will have ELSE blocks inside them.
2. Someone suggests loop {} else {}
3. Someone else points out that that's bad, because people will expect
elsif
4. I point out that elsif isn't so bad, and perhaps there should be an
array of other else options.
So, the answer to your question is: yes, I do propose that there should
be an elsif, elsloop and elsfor. That's it. Three words, not an
expansive list of ever-more-complex words.
Now, I agree that else for might make more sense, but it's very ugly
on the grammar (given that we don't allow free statements like C does).
Re: Loop controls
On Sat, 2002-04-27 at 08:53, Damian Conway wrote:
Which I presume was that the proposed usage:
while $result.get_next() - $next {
# do something with $next...
ELSE {
if $next eq xyz572 {
print We defined this value, $next, as false for obscure purposes.;
print No loop was executed. Just wanted to let you know.;
}
}
}
would actually be a (very subtle and nasty) bug!
I disagree. It has no bug (unless you want it to).
I also thought while was gone, replaced by loop, but if while is in,
then there's no bug.
Here's the code, expanded:
my $tmploop = sub ($next is rw) {
# do something with $next...
}
my $tmpelse = sub ($next is rw) {
print We defined this value, $next, as false for obscure purposes.;
}
{
my $tmpval;
my $loopcnt = 0;
loop {
$tmpval = $result.get_next();
last unless $tmpval;
$loopcnt++;
$tmploop.($tmpval);
}
$tmpelse.($tmpval) unless $loopcnt;
}
Now, if you put the temporary inside of the loop scope, then I have to
agree with you: there's no $next when you get to the else, but that's
not the only way to do it, and I really don't think you SHOULD do it
that way. After all, you might have important reasons to want access to
that value!
If you're implying that putting the else outside the block should
indicate that $next is no longer in scope, I disagree on the exact same
grounds. I want the else to be outside, but the primary reason to me is
that it's far cleaner looking code.
Is there any reason to do it the other way?
Re: Loop controls
On Mon, 2002-04-29 at 15:46, Miko O'Sullivan wrote: Well, if there's no while (replaced by generic loop, per Apoc4) why would there be an until? Whoa. I actually had a moment of panic there. Then I checked for myself. I don't see anything in Apoc4 about getting rid of while. It may be excluded from evolution, but it's still there, sorta like the alligator. Larry uses while in several examples. Ok, going back and looking, I was mislead by a bad memory. I had asked if for(;;) was still in, and Larry pointed out that it was, but it was now loop;; So, the answer to your question is: yes, I do propose that there should be an elsif, elsloop and elsfor. That's it. Three words, not an expansive list of ever-more-complex words. Why not also elswhile? According to Apoc4, while still gets the cool loop controls like NEXT, why shouldn't it get to join the els party? Even alligators evolve a little. If there's a while, there should be an elswhile. My bad on the mix-up.
Re: Loop controls
On Mon, 2002-04-29 at 15:54, Jonathan Scott Duff wrote:
On Mon, Apr 29, 2002 at 03:30:40PM -0400, Aaron Sherman wrote:
On Mon, 2002-04-29 at 10:41, Jonathan Scott Duff wrote:
On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
I would expect that to be elsuntil, but as we're dropping until from
the language, it's a moot point.
Er, what?!? Who said we're dropping until? Did I miss something?
Well, if there's no while (replaced by generic loop, per Apoc4) why
would there be an until?
Larry didn't say loop was replacing while. He said that the magic
do {} while was going away to be replaced by loop. while and
until (both as loops and modifiers) will still be around AFAIK.
1. Larry says loops will have ELSE blocks inside them.
Did he say that? Or was it inferred from NEXT, LAST, etc. by others?
No he didn't. Again, flaky memory on my part. What DAMIAN said was:
Larry has been mulling over whether various types of loop should be
allowed to take Celse blocks to accomplish this.
So, you can see where my confusion came from. It's not clear if this was
suggesting loop{else{}} or loop{}else{}, but either way, this was the
origin of the discussion.
4. I point out that elsif isn't so bad, and perhaps there should be an
array of other else options.
And I say, why have several specific things when you can have 1
generalized thing that does the same job. (I'm not going to describe it
beyond that. It's up to Larry+Damian to define the shape of the thing)
Well then, I guess we should dump elsif from if too. After all, it
could all be done with nested blocks of if/else
If we're to keep if the same, and add an else to loops, I think the
syntax should be unified.
You would then see code like:
unless $fh = $x.open() {
die $0: Cannot open $x;
} elswhile $fh.getline() - $_ {
print;
} else {
die $0: There were no lines to read from $x!\n;
}
Which is as clean and elegant as it gets, IMHO.
So, the answer to your question is: yes, I do propose that there should
be an elsif, elsloop and elsfor. That's it. Three words, not an
expansive list of ever-more-complex words.
You're just weird. :)
Thanks ;)
Now, I agree that else for might make more sense, but it's very ugly
on the grammar (given that we don't allow free statements like C does).
Hey, perl 6 is supposed to be optimized for the programmer, not the
perl parser ;-)
I agree. This is why I think conditionals and loops should have roughly
the same syntax.
Introducing a major twist in the grammar just so that loops and
conditionals can be different, seems to hurt both camps equally and
benefit none.
Re: Loop controls
On Mon, 2002-04-29 at 16:41, Luke Palmer wrote:
So, the answer to your question is: yes, I do propose that there should
be an elsif, elsloop and elsfor. That's it. Three words, not an
expansive list of ever-more-complex words.
Oh! I have an idea! Why don't we make the lexer just realize a prefix
els on any operator. Then you could do Cif .. {} elsexit. :P
That's just a bit more off-the-wall than adding for keywords (the three
above, plus I've been corrected on the while thing). Let's not get too
hyperbolic here; it doesn't help the discussion along much.
My point is that, IMO, this whole els thing is completely preposterous.
I'm the kind of person that likes to keep down on keywords. And I never
liked Perl5's Celsif anyway; I always preferred Celse if. I really
don't understand what at all is appealing about Celsloop.
If you want if/else if, talk to Larry (I would not disagree, though old
friends are hard to part with). I'm just saying that as long as if has
the syntax it has, we should replicate that on loops.
I don't want this thread to turn into a mindless squabble. Perhaps people
could look at the thing a different way altogether, not taking side 1 or
2, but rather 1+2i.
We've had a lot of good thought here, and I see this as anything but a
mindless squabble.
Here's my synopsis of how everything's gone so far:
We have the following syntaxes for elses on loops (for any kind, not just
loop).
loop ;; {} else {}
loop ;; { else {} }
loop ;; { ELSE {} }
See the thread that Damian started, which discusses these options.
Furthermore, we have a couple of different ways for loops to come after
elses:
elsloop ;; {}
else loop ;; {}
else { loop ;; {} }
Correct, and this has been pointed out previously in the thread. Thank
you for collecting it.
I think the reasoning for each, respectively is:
1. Consistent syntax with if/elsif/else
2. Cleaner
3. No new syntax required
I agree with all three points. I have a feeling we're not going to get
if/else if, but if we do I prefer the second. If we don't I prefer the
first.
Re: Loop controls
On Tue, 2002-04-30 at 13:07, Miko O'Sullivan wrote:
Damian, now having terrible visions of someone suggesting Celswhen ;-)
Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
Aaron, trying hard not to be a crackpot, but getting the impression
that's now just a dream :-/
If we all agree that the meaning of elsflow-control-keyword is
clear, but we dislike adding insane numbers of keywords to the language,
let's step back and ask why it would have ever occurred to us to do such
a silly thing.
Since the beginning of this discussion, I've been happy to accept the
idea that elswhile is ugly and unmanageable, but I saw no other way,
given the if/elsif syntax.
I do think that unifying the if/loop syntax is wildly useful, but
there's no reason that we HAVE to put the burden on the loop constructs.
Why do we use elsif? Well, it seemed like the right choice at the
time, and avoided C's infamous ambiguity by allowing braces without
bogging down the programmer (Larry, jump in if that wasn't the
reasoning, it's been nearly a decade since I last saw you discuss the
topic).
What would happen if we had:
if expr {
...
} else if expr {
...
} else {
...
}
Not as a naked (i.e. un-braced) statement, but if else if were treated
as a single token (either at the tokenizer level or gathered together in
the parser, it doesn't really matter).
In this case, you could have all of the funky control structures you
want, but the user does not have to play string-concatenation games in
their head.
It's reasonably obvious what:
unless my $fh=$x.open {
die Cannot open $x: $!;
} else while $fh.getline - $_ {
print;
} else {
die No lines to read from $x;
}
would mean, and it's also a pleasingly simple addition.
Then if you want else when or else do, you're all set. It's an easy
change and there are no new keywords.
I think else grep would be pointless, as grep is not a flow-control
structure as such. You can always else if grep {...} list { ... }
This also resolves the long-standing question: why isn't there an
elsunless, which has been asked since as long as I've been programming
in Perl. I see no reason for there not to be else unless, does anyone
else? unless?
Re: Loop controls
On Wed, 2002-05-01 at 08:27, Miko O'Sullivan wrote:
Damian said:
6. Cotherwise would seem to fit the bill rather nicely.
To me, otherwise is a synonym for else, and that makes it too
confusingly similar. I foresee forever explaining to people the difference
between Celse and Cotherwise. I'm not sure if Cotherwise is popular
because it is similar to Celse, but I think the similarity is a reason
*not* to use it.
How about Cnoloop? It's absolutely clear what it means and won't be
confused with else.
Call it maxheadroom for all it will matter.
* people will still see conditional execution associated with loops
* the unless/elsif syntax is still grotesque and asymmetric
* the treatment of conditionals{1} vs conditionals{1,} is asymmetric
If you un-peel this and expose the elegant simplicity of flow control,
you can unify all of these concepts to their basic form:
flowcontrol:
controlblock |
controlblock TOK_else flowcontrol |
controlblock TOK_else block
;
controlblock:
controlword expression closure |
controlword expression block |
TOK_loop block |
TOK_loop expression ';' expression ';' expression block
;
controlword:
TOK_if |
TOK_unless |
TOK_while |
TOK_until |
TOK_for |
TOK_when
;
block: '{' statements '}' ;
closure: mumble... ;
expression: mumble... ;
statements: mumble... ;
I haven't really thought about this representation of the grammar much,
and I'm not grammar constructor by nature, but you can see the idea
here, and the stark simplicity of it.
What is so lovely about elsif that we cling to it, and mutate the
admittedly obvious choices elsewhere to preserve it?
Re: Loop controls
On Wed, 2002-05-01 at 12:22, Allison Randal wrote:
On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote:
[... in python ...]
while_stmt ::= while expression : suite
[else : suite]
That's straight from http://www.python.org/doc/current/ref/while.html.
If you abstract the meaning of Celse to execute when the condition in
the previous block is false this makes perfect sense. It's just not
very useful. This is actually a good reason for Perl to use a different
keyword than else with loops. You avoid that interpretation entirely.
You also avoid totally annoying Pythonists who occasionally use (and
might be converted to) Perl. :)
So, the Python while is the Perl6:
loop {
if (expression) {
suite
} else {
suite
last;
}
}
This is not shocking at all, as Python does not dip into the
polymorphism of containers nearly so much as Perl does. To Python,
evaluating the truth of a sequence of this type requires there to be a
truth already present. In this case, the truth of the last evaluation of
the expression suffices.
Perl is fundamentally different in its approach and just as a Pythoner
will have to swallow hard and squint to understand other polymorphic and
context-sensitive aspects of Perl containers, so too will they have to
get over this distinction.
I'm not slighting Python here. I'm just saying that there's a learning
curve fraught with dangerous similarities in both directions, and
constructing Perl to accommodate that transition does not seem to be
particularly wise.
Re: Loop controls
I now realize that my previous message was a little hard to read (plus I
sounded a bit harsh, which I did not mean to be, I was just excited,
thinking about this), because I insisted on being sort of stilted in my
pseudo-BNF. Here's a cleaner shot at what I meant:
flow:
control 'else' flow |
control 'else' block |
control ;
control:
controlkey expr '-' closuredef |
controlkey expr block |
'loop' block |
'loop' expr ';' expr ';' expr block ;
controlkey:
'if' | 'unless' | 'while' | 'until' | 'for' | 'when' ;
block: '{' statements '}'
That should be a bit easier to appreciate. I find myself looking at this
and loving Perl just a little bit more
Again, my example from before:
unless my $fh = $x.open {
die Cannot open $x: $!;
} else while $fh.getline - $_ {
print;
} else {
die No lines to read in $x;
}
That does seem to roll of the tongue, does it not?
Re: Loop controls
On Wed, 2002-05-01 at 18:47, Damien Neil wrote:
On Wednesday, May 1, 2002, at 02:27 PM, Aaron Sherman wrote:
unless my $fh = $x.open {
die Cannot open $x: $!;
} else while $fh.getline - $_ {
print;
} else {
die No lines to read in $x;
}
I think you need a better example--given that the unless clause throws
an exception, the else while can just as easily be written as a
while, no else. (Which I, personally, would find far clearer.)
No, I write this sort of thing all the time:
if (foo) {
die $!
} else {
stuff
}
It's clearer, IMHO, to the reader and maintainer of the code, exactly
what is expected. It's taste and style and visual aesthetics, but we
wouldn't have a postfix if if those things didn't matter in Perl.
Re: Perl (well, Parrot) Internals QA
On Mon, 2002-05-06 at 16:26, Dan Sugalski wrote: I forgot to announce the call for questions here (sorry), but the answers 9and the questions) to the first round of Ask The Parrot have been posted over on use.perl. http://use.perl.org/article.pl?sid=02/05/06/179233 for the interested. Some interesting items there. I'd like to ask a few follow-ups, but not sure who the right audience is. For now, let's assume it's this list, and not use.perl.org On language features: How is it that Parrot is language-neutral, and yet as a specific set of guarantees for destructors? Wouldn't those assumptions be wrong for, say, Scheme or Python? Also on that point, what of closures? Can those be managed in an efficient, and yet language-neutral fashion? On the Perl5 handling: why do you need step 3? Specifically, why not just continue to use the Perl5 parser as the Perl5 front-end for Perl6? That should guarantee compatibility. Very nice QA. Thank you very much for the info!
RE: Loop controls
On Mon, 2002-05-06 at 14:21, David Whipp wrote: Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote: Sorry, I thought I'd expressed agreement at some point. I like the else\s+(if|while|for|loop) construct very much, and I think the programmers of the world would like it too. I know a some people have issues with where's the if but it's no worse than where's the semicolon or where's the filehandle closed. 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. No. That would introduce a problem that Larry has said (back when I started learning perl 3.x) that he wanted to avoid from C: the mystery of bare-blocks. What I was proposing was that else could be followed by a block (as normal) or by a whole control structure, which could be a loop or conditional and might itself contain an else. There's no ambiguity because all blocks still require braces.
Re: What does this do?
On Fri, 2002-05-03 at 12:37, Larry Wall wrote:
Piers Cawley writes:
: Consider the following.
:
:sub foo {...}
:
:foo *@ary;
:foo * ary;
:
: Is this another place where whitespace will have meaning? Or should I
: add parentheses to disambiguate? Enquiring minds want to know.
I see no ambiguity. It's a unary * in either case. You'd have to
declare it
sub foo () {...}
to get a multiply out of it.
Ok, I'm not going to say you're wrong (I most likely am), but I would
like to try to understand why this would be true.
The tokenizer is going to hand back what? 'bareword:foo', '*', 'type:',
'identifier:ary'?
In which case, it seems to me that you would be right, but there's a big
trap Does that mean that if foo has the following:
sub foo();
sub foo($x,$y);
Then you always get multiply, or you always get argument expansion? Is
that going to be counter-intuitive for the programmer who uses a library
that provides such a definition?
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thu, 2002-05-09 at 13:22, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do look-ahead
here. we don't guarantee order of evaluation is exactly saying
that, no?
As the he refered to, let me be absolutely clear that I am
*not* suggesting any type of look-ahead here. I was specifically
talking about the Cforeach loop, where Perl is expected to
implement the iterator. In a Cwhile loop, the programmer
controls the iterator, and would be surprised by a loop-ahead.
My bad. Missed the transition from foreach to while... oops!
Re: Accessor methods ?
On Thu, 2002-05-09 at 12:37, David Wheeler wrote:
On 5/8/02 1:24 PM, Damian Conway [EMAIL PROTECTED] claimed:
Yes.
If you write:
class Foo {
my $.bar;
my $.baz is public;
...
}
you get a private C.bar() accessor and a public C.baz accessor.
What if I want my methods to be called C.get_bar() and C.set_bar(),
since a certain Perl OO specialist suggests this approach is best for
avoiding ambiguity in one's API?
Then you can declare them as such:
sub get_bar() { .bar }
sub get_baz() { .baz }
sub set_baz($newbaz) { .baz = $newbaz }
I suppose there could be some magic like:
class Foo is accessedby('get_','','r')
is accessedby('set_','','rw') { ... }
To declare that Foo has accessors with prefix get_ and no suffix for
read-only acces and prefix set_ and no suffix for read/write access.
But, I'm not sure how valuable this would be
Re: Accessor methods ?
On Fri, 2002-05-10 at 00:27, Damian Conway wrote:
Aaron Sherman wrote:
What if I want my methods to be called C.get_bar() and C.set_bar(),
since a certain Perl OO specialist suggests this approach is best for
avoiding ambiguity in one's API?
Then you can declare them as such:
sub get_bar() { .bar }
sub get_baz() { .baz }
sub set_baz($newbaz) { .baz = $newbaz }
Close. They'd probably be implemented like this:
method get_bar() { $.bar }
method get_baz() { $.baz }
method set_baz($newbaz) { $.baz = $newbaz }
Wouldn't those be the same? .bar is the auto-created accessor for
$.bar, so they should do the same thing, no?
And in the case of .baz, I'm assuming that a public member will be
given an is rw accessor, so that .baz = $newbaz will work the same
as $.baz = $newbaz.
Granted, I use sub instead of method... that's going to take some
getting used to, but I suppose it makes sense.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote: From: David Whipp [EMAIL PROTECTED] It it too much to ask, of the creator of a tied array, to implement their code in such a way that *reading* an element of that array does not have significant side-effects? Actually, I think that *is* a significant imposition. The whole point of tied arrays ( and hashes, scalars, etc) is that they act like arrays but internally do whatever they want. But could we go back a step? Could somebody explain why we need lookaheads, or perhaps what exactly a lookahead is in this context? Part of the current interface for tied arrays is that they know how long they are. It seems like it would be a relatively simply algorithm to say if there are still elements left in the array then populate the loop variable with the next element and run the block. Else, leave the variables as they are, run the LAST block. This brings up a concern that I've had with the idea of lazy arrays in Perl for a while. An awful lot of things in the current Perl codebase rely on the idea that an array (even a tied one) has a length at any given time (even if it changes). To change that assumption may have some serious impact on a lot of features of the language. You cannot, for example, reasonably do: (0..Inf).length You might special-case that particular one (return Inf if either end-point of a lazy array is Inf), but this is a simple example. Tie creates much more interestingly clever examples Should a tied and/or lazy array be forced to present a length on demand, or can length return undef on indeterminate arrays?
Re: Accessor methods ?
On Sat, 2002-05-11 at 17:43, Damian Conway wrote:
Paul Johnson wrote:
I've always found the word like to be very wishy-washy in a computer
langauge. In what way is newbaz like baz? And just how alike are they?
There must be a better way to describe this.
Perhaps:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I don't like the second one, as it implies that Perl has types, which it
really doesn't (properties are just that, properties).
The first is a bit long, but I could get behind it in a crunch.
However, my first thought is, why do we need a keyword here?
Since it's not otherwise valid syntax (the semi-unofficial battle-cry of
perl6-language ;-), I propose:
method set_baz($newbaz is $.baz) { .baz = $newbaz }
There's two ways to take C$x is $y. I think it's easy enough to get
people used to the idea that aliases are created vi C:=, so there's
really only one left.
And, yes I do think that using the auto-accessor is more correct. It
should be in-lined under most circumstances, but if someone comes along
later and moves that accessor into a super-class, we're still good.
Re: Accessor methods ?
On Fri, 2002-05-10 at 21:42, Damian Conway wrote: Wouldn't those be the same? Not quite. C$.bar is a direct access to the attribute. C.bar is a call to the accessor. There might well be performance issues. I would expect that there won't be, but perhaps I'm optimistically over-hyping Perl6's inlining before it exists. Surely, we would always prefer that every method except accessors use the accessors, though. After all, later modification of the class might move the member variables to a super-class.
Re: stringification of objects, subroutine refs
On Sat, 2002-05-11 at 00:39, Dan Sugalski wrote: At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote: I was wondering how perl6 would stringify (as in Data::Dumper): That's not stringification. It's serialization, which is a different thing entirely. What you'll potentially get is a thing that can be completely reconstituted into what it originally was, complete with variables, methods, attributes, and whatnot. How much gets serialized depends on what you'll choose--in the worst case, your entire program will need to get serialized, but that'll be doable. This seems like a no-brainer to me, so I must be missing something ;-) Wouldn't it be possible to just settle on Parrot byte-code as a serialization form? If so, everything is serializable, no? Granted, your data might not come out intact if your writer and reader don't agree in module versions, but this is a minor nit in the scheme of things.
Re: Selective exporting of properties/methods
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
underscores give me gas. ;)
Re: Why not {,n} in quantifiers?
On Tue, 2002-05-14 at 20:13, Larry Wall wrote:
It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe we'll
have something like this:
Perl 5Perl 6
{1,3} 1..3
{3} 3
{3,} 3+
{0,3} 3-
Then again, maybe not...
Hopefully there will be some replacement. I can't count the number of
times I've relied on things like:
$b = qr/\d{1,3}/;
if (ip = ($addr =~ /($b)\.($b)\.($b)\.($b)/)) {
die $0: \$addr\: bad IP\n if grep {$_255} ip;
print(0x,(map {sprintf %02x, $_} ip),\n);
} else {
die $0: \$addr\ is not an IP address\n;
}
It would be a shame to loose that.
Re: Accessor methods ?
On Wed, 2002-05-15 at 10:36, Dan Sugalski wrote:
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
Wouldn't those be the same?
Not quite. C$.bar is a direct access to the attribute. C.bar is a call
to the accessor. There might well be performance issues.
I would expect that there won't be, but perhaps I'm optimistically
over-hyping Perl6's inlining before it exists.
Languages like perl can't easily be inlined, since subs may be
redefined at any time. If a sub's a leaf sub you can detect changes
before calling safely, but if it's not a leaf sub you run into the
potential issue of having the sub potentially redefined while you're
in it.
That seems like a tragic performance-sink Is there some way that the
caller and/or function could indicate that they want to avoid such
over-generalization? Something like an is const or is inline to
indicate that the subroutine is read-only and cannot be redefined?
When the parser sees:
sub subname(...) is inline { ... }
subname(...);
It could safely just inline the code without any sort of run-time check.
Normal inlining would still take a hit, but I'd hate to see:
$minusone = E ** (PI * I)
go through a run-time check for redefinition.
Of course, we're talking run-time. If you use two modules which both
define a common subroutine as inline (or only one does), there should be
no conflict and the second should override the first. It's only run-time
redefinition of a subroutine which would prevent efficient inlining.
So, in my example above, you could still Cuse Math::Pi::Simple to get
the version of PI that's defined as 3, but you could not have a
subroutine that swapped PI between the two values, based on a
command-line flag.
Re: Methods, and such
On Wed, 2002-05-15 at 21:38, root wrote:
I've always liked how VB allowed you to define instance methods.
Basically a more elegant way of doing callbacks, plus allows some
structure within your callbacks. Will Perl6 allow this (Perl5 sortof did,
but since the bless way of doing things is going away...)
Perhaps...
class foo {...}
$x = new foo;#BTW, is there some standard way of creating instances
#now?
my $x is foo; # I think that's correct
method $x.frob() {...}
Since these are more for run-time sorts of things than compile-time
sorts of things, perhaps you want that to be a closure. You could have a
autoload check in UNIVERSAL (even in Perl5, not sure how in Perl6) that
would work like so (Perl5 syntax):
$x = foo-new();
$x-insmeth 'frob', sub {...}; # name wins 'cause it sounds Lovecraftian
$x-frob();
So, you can already do this, though I would sit down and think long and
hard about adding an autoload to UNIVERSAL in Perl5. Hopefully
autoloading will be able to chain correctly in Perl6.
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Thu, 2002-05-16 at 16:13, 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. If I'm wrong about no proof existing for pi's infiniteness, I apologize. Pick your favorite series of discrete units n, where n may or may not be infinite, but where series[x] can be determined (though possibly at great cost) for all Perl-available positive integers, x. That aside, the point holds. Tied arrays which point to complex systems may not have a known length (even in Perl5). We know this.
Re: Accessor methods ?
On Thu, 2002-05-16 at 16:07, Mike Lambert wrote:
Languages like perl can't easily be inlined, since subs may be
redefined at any time. If a sub's a leaf sub you can detect changes
before calling safely, but if it's not a leaf sub you run into the
potential issue of having the sub potentially redefined while you're
in it.
If I'm in middle of executing function A, and I redefine function A, then
it doesn't matter for the execution of the function. Even un-inlined, the
execution continues as it did before. Perhaps this should be an argument
to appease the callee-save proponents. Their main argument was leaf subs.
If we can guarantee that these are inlined, then their only argument goes
away. :)
Hmm... I see some conversational double-speak there, but I don't recall
the thread. Point granted.
As such, I think we should be able to inline a call to A() with:
if( value A == value of A when we inlined it )
contents of sub
} else {
A()
}
Yes, in the default case I think that's what was being discussed.
Alternately, I think we should be able to mark subs as 'final' or 'inline'
to indicate our guarantee that they won't be modified. Of course, it'll
conflict with auto memoizing or auto currying modules that'd want to
override it, but that's their fault. :)
Yes, I suggested inline or const I can't imagine that we would
want to do without this, regardless of what we call it. Otherwise,
auto-accessors will always be slower than using the variable. Would
everyone agree that this property should default to being set for
auto-accessors?
And even though distributed .pbc files and seperate compilation are some
goals of perl6, I still think we're okay. If we inline a function in
module A, and module A changes, Perl6 should ensure that the original
version is still loaded for our code, and thus our inlining should still
be valid.
Oh, that one's easy (I think/hope/pray).
There're three stages:
1. compile time -- When a module or program is byte-coded
2. load time -- When byte-code is loaded off of disk
3. run time -- When the program begins to execute
There are complexities, but you get the idea. Load time, I assume is
also when BEGIN executes.
In this model, you only ever inline at load time ***OR*** when the
compiler is attempting to produce a self-contained byte-code executable
(e.g. one which has all of the modules in it), in which case it executes
that part of the load time process early. If you like, call this a
sub-stage of load time, which I shall dub link time. Link time can
only happen once per program, so it must happen when we actually know
what all of the program components are.
Any other way of doing this would seem to me to be a very dangerous
weapon to brandish so close to so many unsuspecting feet. :-(
Another avenue is that of self-modifying code. I know it would break
threads, or cause code duplication between threads, but when A changes, we
can either re-inline the new subroutine, or eliminate the 'if-else' check
to avoid the branch we know will be false from then on. Creating code
which optimizes itself as it's run based upon internal profiling would be
cool. But that's the topic of a different thread. :)
Code that does this by changing sub references should still work. Code
that does this by changing its own internal representation gets what it
paid for.
Re: Accessor methods ?
On Mon, 2002-05-20 at 00:27, Larry Wall wrote:
Aaron Sherman writes:
: Alternately, I think we should be able to mark subs as 'final' or 'inline'
: to indicate our guarantee that they won't be modified. Of course, it'll
: conflict with auto memoizing or auto currying modules that'd want to
: override it, but that's their fault. :)
:
: Yes, I suggested inline or const I can't imagine that we would
: want to do without this, regardless of what we call it. Otherwise,
: auto-accessors will always be slower than using the variable. Would
: everyone agree that this property should default to being set for
: auto-accessors?
No, that would undo the whole point of making them accessors in the
first place.
Think of this like a constant variable. In Perl5, we can do:
use constant foo=1;
use constant foo=2;
and foo will have the value 2, but you cannot change the value of foo
during run-time. That's all I'm saying for accessors. This way, when I
define
class argh {
my $.foo;
}
I get
method foo() is rw($newfoo) is inline { ... }
but, in another module, there's nothing to stop you from:
method argh::foo() { die No, you don't! }
because all that matters is that AFTER perl sees you call C$obj.foo,
it never changes.
Of course, this all goes out the window if inlining happens at
compile-time, since libraries will no longer be able to override
auto-accessors later on.
: In this model, you only ever inline at load time ***OR*** when the
: compiler is attempting to produce a self-contained byte-code executable
: (e.g. one which has all of the modules in it), in which case it executes
: that part of the load time process early. If you like, call this a
: sub-stage of load time, which I shall dub link time. Link time can
: only happen once per program, so it must happen when we actually know
: what all of the program components are.
It seems like an assumption that link time can only happen once. An
incremental linker might feel like it can relink any time it feels like
it. Some very useful programs never completely know what their
components are.
Agreed, and I would be remiss if I didn't mention that all good
intentions go out the window the moment someone does:
sub mumble() is inline { ... }
eval 'use stuff;mumble()';
Now, we could have the case where mumble has been redefined, or the case
where mumble is still the old inlinable thing, but inlineables that it
calls have been redefined.
Ick, *shudder*.
I guess the run-time checks will be required, and inlining of small
chunks of code will never really be all that useful (as you cannot rip
open that scope and optimize the whole context).
Re: Backslashes
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
Here's an easier one: backslash followed by the delimiter is that thing.
Everything else is literal.
print 'c:\it\'s\easier\to\write\win32\paths\this\way';
print q{this is ok { and so is \} } C:\this };
I desire you print your statement above. Would it be:
print 'print \'c:\it\\'s\easier\to\write...\';';
The quesiton here is that C\\', which means something different in
your recommendation than it means in Perl5, but still does the same
thing
Is there any gotcha, here? I'm not sure, but it's tickling my brain in
an odd way, and I keep wanting to say that it breaks down somewhere
RFC261 in Perl 5 and where it needs Perl 6 support
Larry discounted RFC261 in A5, but I think there's some good in it. The
biggest problem is not that it's hard to do in Perl6, but that 80-90% of
it is ALREADY done in Perl5! Once you peel away that portion of the RFC,
you get to Perl5's limitations and what Perl6 might do to support these
things.
NOTE: My examples are unchecked, so they should be considered
pseudo-code.
# RFC261
match ($a) = foo;
# Perl5
($a) = foo;
#RFC261
match { 'Joe' = ? } = $h or die Hash does not contain Joe;
#Perl5
scalar(grep { $_ eq 'Joe' } keys %$h) or die ...
# This one states its own solution
# Equiv to scalar(grep { $_ == 1 } list)
match (..., 1, ...) = list;
# No idea what this is supposed to do. I think $_[$_] is meant to work
# in a way it doesn't ($_ will be a value, not an index).
# Pretty close to ($idx) = grep { $_[$_] == 1 } _; $b = $_[$idx+1];
match (..., 1, $b) = _;
# However, I want to suggest that Perl6 closures on grep and map should
# be considered anonymous methods on the implied loop itself, so that we
# can call methods like .index or .prev or .next (look ahead/behind), etc.
# This gets sticky in some situations, but it would be invaluable, so it's
# worth the effort, IMHO.
# RFC
# It gets worse! This gives the value associated with a key matching the
# regular expression a*b:
match { /a*b/ = $value } = \%h;
#Perl5
# The RFC does not account for multiple matches
# (presumably we just take the first)
($value) = map {$h{$_}} grep {/a*b/} keys %h;
# RFC
# And if you want to know what the key was:
match { $key = /a*b/ = $value } = \%h;
# Perl5
($key,$value) = map {($_,$h{$_})} grep {/a*b/} keys %h;
# RFC
# What if you want to grab out the index? This is like
# ($i) = grep { $list[$_] =~ /foo/ } 0..$#list
match ( $i = /foo/ ) = list;
# Perl5
# As suggested above
# Perl6
# See my previous comment on closures of this type
grep {/foo/ $i = .index} list;
Sorry, it's time for me to go meet someone, but I think the rest of the
RFC just gets into two cases. One involves some funky OO stuff that I'm
not going to touch on here. The other is the idea of matching sub-lists,
which would be the place for some methods inside of grep and map that
support look ahead and behind.
I hope others will take up this line of thought. Improved list
manipulation can only be a good thing, IMHO.
