RE: http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
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.
Thanks for the excellent feedback from both of you. Using eval does
have its drawbacks, as Aaron points out, but along with some
substitutions like Luke suggested, it is fine for my purposes.
Re: http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
On 4 Apr 2002, Aaron Sherman wrote:
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.
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.
Re: $^a, $^b, and friends
Just some thoughts in case you assumed people would only us Perl for good. $_='opcpez/xsjuft/qzax/,kvtu/gps/hppe!' ;szaxfsmyb-z,/!a-y !-print;
Re: $^a, $^b, and friends
At 4:22 PM -0800 4/4/02, Larry Wall wrote: Dan Sugalski writes: : At 3:11 PM -0800 4/3/02, Larry Wall wrote: : Piers Cawley writes: : : Jonathan Scott Duff [EMAIL PROTECTED] writes: : : : : On Wed, Apr 03, 2002 at 11:27:10AM -0800, Larry Wall wrote: : : They are assumed to be declared in alphabetical order. Whoa! you say, : : that could get confusing. It surely can. But if you're doing : : something complicated enough that alphabetical order would be : : confusing, don't use this shorthand. : : : : Alphabetically or asciibetically? I mean, are these functionally : : equivalent? : : It's utf8ical, actually. : : That should be Unicodely, I expect. But strict unicode sorting, or do : we respect the locale? Strict, but doesn't really matter. Nobody sane will use anything other than $^a and $^b. Well Are we allowing non-latin characters in identifiers? There may be potential interesting ramifications with those. Kanji specifically, though I don't have details for them yet. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: classes, interfaces, properties and 'is'
At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
Melvin Smith wrote:
More generally, it also depends whether you think of out-of-band properties as
nouns or adjectives. For example:
class Toaster is silver is shiny is hot is little {...}
vs:
After rereading the example, this one bugs me.
This is compile time, and should be an inline property.
I see the potential for another Perl 'non-warning' bug, where
someone typed:
class Appliance {
mucho lines of code...
}
class Toaster is appliance {
}
This trivial example would of course be spottable to all but the blindest
programmer, but what about the more conceivable...
class ToasterException is MyExceptionLibinHungarianNotationBurntBread
{
}
Oops, the exception is really MyExceptionLibInHungarianNotationBurntBread
but Perl6 wouldn't complain, right? It creates a property.
It scares me to be able to _declare_ a new attribute with the same operator
that I typically use to _inherit_ an existing class or property.
Why not make 'is' a little tidier; require us to declare attributes inline, and
let us tag _objects_ (not classes) at runtime with different notation?
-Melvin
Re: $^a, $^b, and friends
Dan Sugalski writes: : Strict, but doesn't really matter. Nobody sane will use anything other : than $^a and $^b. : : Well Are we allowing non-latin characters in identifiers? There : may be potential interesting ramifications with those. Kanji : specifically, though I don't have details for them yet. Yes, you can use anything with the letter or number property in identifiers, plus you can use ideographs. As it happens, the Kanji for one and two come in the right order, but don't try to extend that to three. I am, of course, overstating the case when I say that anyone who uses anything other than $^a and $^b is insane. Any conventional pair will do, as long as they're known to order correctly, and serve as good identifiers. That's the only reason we didn't restrict curried parameters to single letters. (Damian can vouch for the fact that I seriously proposed doing so somewhere out in the middle of the Atlantic.) Interestingly, the Kanji for yin and yang sort in that order, even though the anglicized words don't. So a program or module not intended for circulation beyond Japan could reasonably use those two ideographs for a and b if it did so consistently. Indeed, it's almost beneficial to use them to represent natural pairs, because people would not then be tempted to extend the sequence to a third item, unless there's something I don't know about that comes after yang. :-) But anyone reading this should be using $^a and $^b most of the time. Larry
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: http://archive.develooper.com/perl6-announce-rfc@perl.org/msg00318.html
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; Good point. Well, we were brainstorming macros for a reason ;). But an efficient version would be nice, I suppose. We still have yet to come up with a good macro definition method.
Re: classes, interfaces, properties and 'is'
Melvin Smith writes:
: At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
: Melvin Smith wrote:
: More generally, it also depends whether you think of out-of-band properties as
: nouns or adjectives. For example:
:
: class Toaster is silver is shiny is hot is little {...}
:
: vs:
:
: After rereading the example, this one bugs me.
:
: This is compile time, and should be an inline property.
:
: I see the potential for another Perl 'non-warning' bug, where
: someone typed:
:
: class Appliance {
: mucho lines of code...
: }
:
: class Toaster is appliance {
:
: }
:
: This trivial example would of course be spottable to all but the blindest
: programmer, but what about the more conceivable...
:
: class ToasterException is MyExceptionLibinHungarianNotationBurntBread
: {
: }
:
: Oops, the exception is really MyExceptionLibInHungarianNotationBurntBread
: but Perl6 wouldn't complain, right? It creates a property.
No, compile-time properties will likely be declared as a kind of class,
so that such typos would be caught. But however compile-time properties
are implemented, there has to be an implementation available at the
time of the declaration because such properties are primarily for the
purpose of warping the nature of the variable itself, and you can't
really compile the code without knowing what is blurfl means. It might
mean blow up on any reference to this. :-)
In the particular case of a class property, we'd really like to know
its derivation at compile time whenever possible because this gives the
optimizer more information to work with.
: It scares me to be able to _declare_ a new attribute with the same operator
: that I typically use to _inherit_ an existing class or property.
:
: Why not make 'is' a little tidier; require us to declare attributes inline, and
: let us tag _objects_ (not classes) at runtime with different notation?
Objects *do* use a different notation, because objects are constructed
at run-time. Whether run-time properties must be predeclared has not
yet been decided. I can argue it both ways.
Larry
$i := 1;
At a recent talk, Larry showed a line of code that was something like: (@a; @b; @c) := (@x; @y; 1,2,3); I'm curious about the mapping of @c to a list of constants; if I write @c[0]++; am I bumping the value of 1? As it happens, this used to be the case on some old Fortrans that used literal pools. I _assume_ Perl6 won't have such a problem, but I'd like to hear how it works out... -r P.S. The Fortran code was something like: PROGRAM FOO CALL BAR(1) I = 1 PRINT I STOP END SUBROUTINE BAR(J) J = 2 RETURN END -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: $^a, $^b, and friends
Larry Wall [EMAIL PROTECTED] writes:
Dan Sugalski writes:
: Strict, but doesn't really matter. Nobody sane will use anything other
: than $^a and $^b.
:
: Well Are we allowing non-latin characters in identifiers? There
: may be potential interesting ramifications with those. Kanji
: specifically, though I don't have details for them yet.
Yes, you can use anything with the letter or number property in
identifiers, plus you can use ideographs. As it happens, the Kanji
for one and two come in the right order, but don't try to extend
that to three.
Aw... so no Cmethod empty? {...} then? I've kind of got used to that
while I've been playing with scheme and smalltalk.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: $^a, $^b, and friends
Piers Cawley writes:
: Larry Wall [EMAIL PROTECTED] writes:
:
: Dan Sugalski writes:
: : Strict, but doesn't really matter. Nobody sane will use anything other
: : than $^a and $^b.
: :
: : Well Are we allowing non-latin characters in identifiers? There
: : may be potential interesting ramifications with those. Kanji
: : specifically, though I don't have details for them yet.
:
: Yes, you can use anything with the letter or number property in
: identifiers, plus you can use ideographs. As it happens, the Kanji
: for one and two come in the right order, but don't try to extend
: that to three.
:
: Aw... so no Cmethod empty? {...} then? I've kind of got used to that
: while I've been playing with scheme and smalltalk.
You can do anything you like if you mess with the parser. Changing
the rules for recognizing an identifier would be trivial.
Larry
Re: $^a, $^b, and friends
Larry Wall [EMAIL PROTECTED] writes:
Piers Cawley writes:
: Larry Wall [EMAIL PROTECTED] writes:
:
: Dan Sugalski writes:
: : Strict, but doesn't really matter. Nobody sane will use anything other
: : than $^a and $^b.
: :
: : Well Are we allowing non-latin characters in identifiers? There
: : may be potential interesting ramifications with those. Kanji
: : specifically, though I don't have details for them yet.
:
: Yes, you can use anything with the letter or number property in
: identifiers, plus you can use ideographs. As it happens, the Kanji
: for one and two come in the right order, but don't try to extend
: that to three.
:
: Aw... so no Cmethod empty? {...} then? I've kind of got used to that
: while I've been playing with scheme and smalltalk.
You can do anything you like if you mess with the parser. Changing
the rules for recognizing an identifier would be trivial.
Duh! Of course. What was I thinking?
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: $i := 1;
At a recent talk, Larry showed a line of code that was something like:
(a; b; c) := (x; y; 1,2,3);
I'm curious about the mapping of c to a list of constants; if I write
c[0]++;
am I bumping the value of 1?
No. We've learnt that lesson, at least :-)
My understanding is that:
c[0]++
will get you a run-time Modification of a read-only value attempted exception.
The Perl 5 analogy for binding an array is what happens to _ in a subroutine:
sub foo { $_[0]++ }
foo(1,2,3);
Damian
Re: $^a, $^b, and friends
Larry wrote: Yes, you can use anything with the letter or number property in identifiers, plus you can use ideographs. As it happens, the Kanji for one and two come in the right order, but don't try to extend that to three. Of course, exactly the same thing is true for the English ideographs: one and two sort fine, but three does not. :-) I am, of course, overstating the case when I say that anyone who uses anything other than $^a and $^b is insane. Any conventional pair will do, as long as they're known to order correctly, and serve as good identifiers. That's the only reason we didn't restrict curried parameters to single letters. (Damian can vouch for the fact that I seriously proposed doing so somewhere out in the middle of the Atlantic.) It's true. But I blame the proximity of the Bermuda triangle for that momentary aberration. ;-) Damian
Re: $^a, $^b, and friends
You can do anything you like if you mess with the parser. Changing the rules for recognizing an identifier would be trivial. Does this refer to messing with the parser... compile time (that is, when Perl compiles, not when Perl is compiled)? Or are you actually talking about screwing with the Perl source? That'd sure be cool (albeit a little weird) to change parsing rules at compile time. Luke
Ex4 smart match question
Does one of these items not belong?
From Exegesis 4:
This new turbo-charged 'smart match' operator will also work on arrays, hashes and
lists:
if array =~ $elem {...}# true if array contains $elem
if $key =~ %hash {...} # true if %hash{$key}
if $value =~ (1..10) {...} # true if $value is in the list
if $value =~ ('a',/\s/,7) {...} # true if $value is eq to 'a'
# or if $value contains whitespace
# or if $value is == to 7
It's very cool--but why is it $key =~ %hash but $value =~ array rather than one way
or the other?
John A
They laughed at Joan of Arc, but she went right ahead and built it.
---Gracie Allen
Tail Recursion optimization
So, here I am working on a Scheme interpreter in Perl 6, and I'm trying to write it in a (for want of a better description) 'Scheme-like' fashion with lots of recursion. The trouble is, unless Perl6 is going to be guaranteed to do optimization of tail calls, this is going to lead to horribly slow code. So, do I bite the bullet and recast some of the functions in an iterative vein, or do I trust that Perl6 will do tail call optimization? Larry? -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Ex4 smart match question
On Fri, 5 Apr 2002 [EMAIL PROTECTED] wrote:
Does one of these items not belong?
From Exegesis 4:
This new turbo-charged 'smart match' operator will also work on arrays, hashes and
lists:
if @array =~ $elem {...}# true if @array contains $elem
if $key =~ %hash {...} # true if %hash{$key}
if $value =~ (1..10) {...} # true if $value is in the list
if $value =~ ('a',/\s/,7) {...} # true if $value is eq to 'a'
# or if $value contains whitespace
# or if $value is == to 7
It's very cool--but why is it $key =~ %hash but $value =~ @array rather than one way
or the other?
Probably because you never really want to find out whether some value is
in a hash, you just want to know whether a key has a value to look up. If
you need to know whether a value is in a hash, it'd be good to rethink
your design.
That and it's stupid to see if an index is in an array. You can just say
$ind @array. So, it DWIMs. In my opinion, it does so very well.
Re: Tail Recursion optimization
Piers Cawley writes: : So, here I am working on a Scheme interpreter in Perl 6, and I'm : trying to write it in a (for want of a better description) : 'Scheme-like' fashion with lots of recursion. : : The trouble is, unless Perl6 is going to be guaranteed to do : optimization of tail calls, this is going to lead to horribly slow : code. So, do I bite the bullet and recast some of the functions in an : iterative vein, or do I trust that Perl6 will do tail call optimization? : : Larry? Why not? The only casualty is caller()'s semantics, and I think we can live with that, or disable the optimization on routines that use caller(). Larry
Re: $^a, $^b, and friends
Luke Palmer writes: : You can do anything you like if you mess with the parser. Changing : the rules for recognizing an identifier would be trivial. : : Does this refer to messing with the parser... compile time (that is, when : Perl compiles, not when Perl is compiled)? Or are you actually talking : about screwing with the Perl source? That'd sure be cool (albeit a little : weird) to change parsing rules at compile time. When Perl starts out parsing Perl 6, it starts with a standard set of Perl 6 grammar rules. At any point during the parse, any immediate subroutine could switch you to a different grammar object, either one entirely unrelated, such as embedded C or Java, or more likey, a slight variant, probably written as a derived class of the standard Perl grammar, where one or two rule methods are overridden. Any grammar production in Perl 6 will be able to be overridden in this way, so you could redefine a block as easily as an identifier. Such a grammar switching routine could operate either over a lexical scope or over the rest of the file. The only restriction is that one module not clobber the grammar of a different module. Basically, we're trying to make the opposite mistake of the one we made with source filters. :-) Larry
Questions about private variables
I just read Exegesis 4, and I have a few questions about private
variables. First, is it possible to have 2 private variables of the same
name in different functions? For instance, what would happen in the
following code?
sub func1() {
our $varname is private \\= 1;
return $varname;
}
sub func2() {
our $varname is private \\= 2;
return varname;
}
print func1();
print func2();
Second, in the above code, the \\= operator is used to initialize the
private variable. This allows it to be initialized the first time the
function is called, but prevents it from being reinitialized subsequent
times as long as the variable never becomes undefined. But what if the
variable can become undefined? In that case, the next time you call the
function the variable will be reinitialized, whether you want it to or not.
Both of these show that private variables in Perl6 do not quite replace
C or C++ static variables. It would be nice if there was some way to do
something like this:
my $foo is static = 3;
so that $foo acts like a C++ static variable, i.e. its value always persists
between calls to the function containing it, and the initialization code is
performed only once. Unfortunately, I have no idea how this would be
implemented in Perl 6.
Joe Gottman
Re: Questions about private variables
Damian Conway [EMAIL PROTECTED] writes:
Joe Gottman wrote:
For instance, what would happen in the
following code?
sub func1() {
our $varname is private \\= 1;
return $varname;
}
sub func2() {
our $varname is private \\= 2;
Fatal error: Private variable $varname declared in two distinct scopes.
Um... there'd be a syntax error before that. \\= should be //= surely?
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
