Re: Apoc4: The loop keyword
At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote: >On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > > > > >What we're cleaning up is the ickiness of having things declared outside > > >the braces be lexical to the braces. *That's* hard to explain to > beginners. > > > > But it's handy. And that was, until now, what mattered with Perl. > >No, handiness still matters with Perl. It's just that the balance has >tipped a wee bit towards the consistency/regularity/simplicity/whatever >side of the scale. > >Besides no one has commented on Steve Fink's (I think it was him) idea >to store the result of the most recently executed conditional in $?. I >kinda like that idea myself. It makes mnemonic sense. I like the $? idea, and it could probably be optimized away. -Melvin
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
I would not be appalled if Perl 6 were to assume use
of caps for catcher block labels, but I would still like to
see Larry et al reconsider this design choice.
One suggestion is use of label syntax for catcher
blocks (suggests "come-from"). If catch and CATCH
were defined as synonyms, then one could type:
LAST: {
or
last: {
--me
Re: What can be hyperoperated?
On Fri, Jan 25, 2002 at 06:03:55PM -0800, Larry Wall wrote: > Do they need to? In the simple case, the hyperoperator provides list > context to its arguments, but just calls the scalar operation repeatedly > to fake up the list operation. Cool. So as far as the parser cares, ^ is simply a flag meaning "carry out the next operation in an interesting way". That helps. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: What can be hyperoperated?
Simon Cozens writes:
: I'm trying to answer the question "what does ^ mean?".
: Can anything be hyperoperated, or just a built-in set of operations?
Probably anything that is sufficiently "scalar" in its typology.
: If "anything", can user's subroutines be hyperoperated?
Why not? (Provided the type signature isn't too wacky.)
: How will they know that they're being called in "hyper context"?
Do they need to? In the simple case, the hyperoperator provides list
context to its arguments, but just calls the scalar operation repeatedly
to fake up the list operation. Any operator
@result = @a ^op @b
is really just something like
@result = for @a; @b -> $a, $b { $a op $b }
(presuming we make C actually act like C).
For the case where one or the other argument is a scalar, we can just
replicate it to a list.
If the PDL folks want to get fancier, I'm sure we can arrange overloading
of ^op as easily as op.
Larry
Re: string interpolation
On Fri, Jan 25, 2002 at 05:07:48PM -0800, Dew-Jones, Malcolm MSER:EX wrote: > Lets add an .interpolate method. The parameter(s) are rules that control > the interpolation, and the returned value is the interpolated string using > those rules. > > $result = 'scalar $vars (only) will be interpolated' . > interpolate($) ; I'm actually just thinking about how to do interpolation now; I'm basically using Perl 5 rules for the most part. The thing that worries me about this idea of yours is that interpolate certainly looks like a method, but it isn't; the arguments you're passing in aren't real arguments at all, they're not ordinary Perl syntax. In fact, you've made up a special tiny domain-specific language for conveying how to interpolate certain things. Now, there's nothing wrong with tiny domain-specific languages, given the right domain. For instance, regular expressions are the right domain. But when you add a little DSL, you have to tell the parser to stop parsing ordinary Perl, and start parsing something else. And you want to do this when you see an interpolate method on a string. Or maybe not just on a string - maybe "interpolate" becomes a special method on everything, which takes this special syntax. Either way, I'm not sure this is something you want to be making up new syntax for. > scenario two, same idea but using =~ notation. Slightly better, but =~ means "match" in some sense, and that sense is getting broader in Perl 6. And interpolation doesn't have very much in common with matching. -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
string interpolation
Hello, I was reading stuff on the perl6 web site, and had some ideas about
string interpolation rules. Is this a place to send this?
String interpolation should be controlled by the programmer on a string by
string basis, or on more global quote-type by quote type basis.
---
scenario one, object.method format
---
Lets pretend a string is an object. The "normal" value of the string is the
interpolation of the string using the default rules for the quotes used.
Lets add an .interpolate method. The parameter(s) are rules that control
the interpolation, and the returned value is the interpolated string using
those rules.
$result = 'scalar $vars (only) will be interpolated' .
interpolate($) ;
The .interpolate method would have the additional ability to interpolate the
contents of a variable.
$result = $string.interpolate; # some type of interpolate, probably
like "
$result = $string.interpolate(${}); # interpolate scalar vars
surrounded by {}'s
you could imagine allowing more complex rules, such as mapping
interpolations to user defined functions, or only interpolating defined
variables, otherwise leave them as-is, or perhaps allowing you to map
specific variables to values but just for that one string's interpolation
# only interpolate defined variables
$result = "$some $of $these $will $be
$interpolated".interpolate(defined($)) ;
# interpolate, one variable gets a specific value
$result = "$one $two $three".interpolate('$one'=>'hi there') ;
# interpolate, scalar values come from user defined function
$result = "$one $two $three".interpolate($ => \&my_function) ;
Here's some more examples
# normal interpolation (i.e. none in ' quotes)
$result = 'string with $var';
# override the ' defaults
# use the $ rule, which would mean interpolate scalars just
# as we do today in " strings
$result = 'string with $var' . interpolate($);
# use the ${} rule, which would mean interpolate scalars,
but
# only when bracketed (using {})
$result = 'string with ${var}' . interpolate(${});
# allow a function to interpolate in scalar context
# by using the & rule combined with $-with-round-brackets
rule
# the function parameters would not be interpolated,
$result = 'string with $(my_function($one,$two))' .
interpolate($(&));
# allow a function to interpolate in array context
# by using the & rule combined with @-with-round-brackets
rule
$result = 'string with @(my_function($one,$two))' .
interpolate(@(&));
# allow a function to interpolate in scalar context
# by using the & rule combined with $-with-round-brackets
rule
# and also let the function parameters be interpolated
$result = 'string with $(my_function("$one","$two"))' .
interpolate($(&));
# nested interpolation rules.
# We force regular scalar interpolation on one of the
parameters
# overriding the default ' interpolation rules
$result = 'string with $(my_function('$one'.interpolate($)
,'$two'))'
. interpolate($(&));
You could set the default interpolation on a quote-type basis for a scope.
# allow qq{} to always do scalar, array, and function
interpolation,
# but only if the scalar is surrounded by //, the array by
{}, and
# the function by <>
use interpolate 'qq' => '$//@{}$<&>' ;
$result = "$this does *not* @interpolate $(at{'all'})";
$result = "$/this/ *does* @{interpolate} $";
---
scenario two, same idea but using =~ notation.
---
A string could have interpolation rules "applied" to the string. The rules
would not modify the string, just the value seen by when the value is
extracted. That's not an issue in a simple quoted string, but makes a
difference if you interpolate a variable
$result = "this $is_not interpolated, but ${this_is}" =~ i/${}/;
$result1 = $master_copy =~ i/${}/; # get the result of
interpolating ${} vars
$result2 = $master_copy =~ i/@/;# get the result of
interpolating @ vars
$0.02
Re: Apoc4: The loop keyword
>>Besides no one has commented on Steve Fink's (I think it was him) idea
>>to store the result of the most recently executed conditional in $?. I
>>kinda like that idea myself. It makes mnemonic sense.
H . . . I could grow used to that. A couple of thoughts.
1) It doesn't seem to buy us much that $_ doesn't already, except some slight
legibility in that we can say what the variable holds as in:
foreach $PIN_number (@list) {
my $PIN = $PIN_number;
#Stuff
}
2) What about our new, more complex foreach:
foreach ($key, $value) %hash {
#What's $? here?
}
Perhaps we could use @_, since we're already used to that giving us arguments from
outside the current scope. Using @_ might very well be logical since custom iterators
will be using it anyway.
3) Even given 2 above I'm not sure that:
foreach ($key, $value) %hash {
my ($key, $value) = @_;
# Do stuff
}
is more useful than
do{
my ($key, $value);
foreach ($key, $value) { . . . }
}
simply because at the end of the first we have $key and $value still overwriting any
previous values, and they'll have values afterward. Even if a $? or @_ implementation
existed I'd probably use the do { . . . } anyway for that reason.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Apoc4: The loop keyword
At 11:40 AM 01-25-2002 -0600, Jonathan Scott Duff you wrote:
>On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
> > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
> >
> > >What we're cleaning up is the ickiness of having things declared outside
> > >the braces be lexical to the braces. *That's* hard to explain to
> beginners.
> >
> > But it's handy. And that was, until now, what mattered with Perl.
>
>No, handiness still matters with Perl. It's just that the balance has
>tipped a wee bit towards the consistency/regularity/simplicity/whatever
>side of the scale.
>
>Besides no one has commented on Steve Fink's (I think it was him) idea
>to store the result of the most recently executed conditional in $?. I
>kinda like that idea myself. It makes mnemonic sense.
>
>But then I'm sure that someone will come out of the woodwork and say
>"What about if ((my $a = foo()) && ($b < 4)) ?" or something. To
>which I'd say "Fooey!" I personally don't think that an extra set of
>curlies are too high a price for getting rid of weird scoping rules.
>But that's just me.
We have
while (foo()) -> $a {...}
doing the right thing.
Why can't
if foo() -> $a { ... }
take the place of the perl5
if (my $a = foo()) {...}
Too bad we can't do
while (foo() -> $a) && ($b < 4) { ... }
and have it do the right thing.
>-Scott
>--
>Jonathan Scott Duff
>[EMAIL PROTECTED]
Re: 123_456
Falling back on the "numbers is strings, too" legacy: $a = 100; $b = "000"; $c = ($a _ $b) + 1; # I'd expect $c == 11. If I say: $a = 1 _ 000 _ 000; or $a = 1_000_000; DWIM (In scalar context, coerce arguments to strings). (Frankly, I think this is unlikely. But who knows?) If course, if I say: $a = $1_000_000; You can complain. WARNING: test.pm (line 4): Cannot assemble $1_000_000. =Austin --- Aaron Sherman <[EMAIL PROTECTED]> wrote: > 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. > > __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
RE: 123_456
> Should we be allowed to use _ to group numbers, now that _ is concat? > If not _, then what? (if anything?) Sure. In Perl 5, we have 123.456 and a . b, but in Perl 6, we will have 123_456 and 123 _ 456. People have to put space around '_' anway. Hong
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.
What can be hyperoperated?
I'm trying to answer the question "what does ^ mean?". Can anything be hyperoperated, or just a built-in set of operations? If "anything", can user's subroutines be hyperoperated? How will they know that they're being called in "hyper context"? If a built-in set of operations, which ones? -- You are in a maze of UUCP connections, all alike.
Re: 123_456
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. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc4: The loop keyword
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > > >What we're cleaning up is the ickiness of having things declared outside > >the braces be lexical to the braces. *That's* hard to explain to beginners. > > But it's handy. And that was, until now, what mattered with Perl. No, handiness still matters with Perl. It's just that the balance has tipped a wee bit towards the consistency/regularity/simplicity/whatever side of the scale. Besides no one has commented on Steve Fink's (I think it was him) idea to store the result of the most recently executed conditional in $?. I kinda like that idea myself. It makes mnemonic sense. But then I'm sure that someone will come out of the woodwork and say "What about if ((my $a = foo()) && ($b < 4)) ?" or something. To which I'd say "Fooey!" I personally don't think that an extra set of curlies are too high a price for getting rid of weird scoping rules. But that's just me. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
123_456
Should we be allowed to use _ to group numbers, now that _ is concat? If not _, then what? (if anything?) -- Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.
Re: Apoc4: The loop keyword
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: >What we're cleaning up is the ickiness of having things declared outside >the braces be lexical to the braces. *That's* hard to explain to beginners. But it's handy. And that was, until now, what mattered with Perl. -- Bart.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
> In most other languages, you wouldn't even have the opportunity to put
> a declaration into the conditional. You'd have to say something like:
>
> my $line = <$in>;
> if $line ne "" { ... }
>
> Since
>
> if my $line = <$in> { ... }
>
> is Perl shorthand for those two lines, I don't see how one can say that
> the variable is more related to the inside than the outside of the block.
> One can claim that the code after the C may not be interested in
> C<$line>, but the same is true of the block itself! The conditional
> only decides whether the block runs. It's not part of the block.
>
> Larry
Particularly in perl, boolean values are often very interesting. I
very much like the "curly brackets are the only things that delimit
scopes within a file, dammit" rule, but I also like to use very
localized conditionals:
if (my $result = expensive_computation()) {
...do stuff with $result...
}
if (my $result = expensive_computation2()) { ... }
func($result);
I would like for there to be a way of saying that so that the
func($result) would trigger an error about using an unknown variable.
(I do *not* want the above syntax to be that way, though.)
Perhaps:
if (expensive_computation()) {
my $result = __HOW_DID_I_GET_HERE__;
...do stuff with $result...
}
I'm just not just how to spell __HOW_DID_I_GET_HERE__.
- $LAST, for the value of the last executed expression?
- $__? (ick)
- Say, isn't $? going away, because it's getting absorbed by $!
I rather like that last one.
if (expensive_computation()) {
my $result = $?;
...do stuff with $result...
}
In fact, it seems clear enough that renaming is only necessary if you
have nested conditionals.
while (read(FH, $buf, 10)) { print "Not EOF yet, received $? bytes\n"; }
Though I don't know if
foo() && print "Yeah baby";
should set it or not. I'd vote not.
