Simon Cozens wrote:
John Porter wrote:
$thing is;
Existence is not the same as essence.
strike() while $the_iron is;
--
John Porter
da Du ron ron ron
--
John Porter
Old stuff becomes relevant again...
-
From: [EMAIL PROTECTED] (Larry Wall)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] (Larry Wall), [EMAIL PROTECTED] (Perl 5 Porters)
Date: Wed, 3 Sep 1997 16:32:29 -0700
Message-Id: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: According to Larry
[EMAIL PROTECTED] writes:
:
: why should a reader expect that a declarative description
: of foo would be followed by the body of foo?
Isn't the functional definition of a sub
just another one of its attributes, anyway?
--
John Porter
On Mon, May 07, 2001 at 10:07:50AM -0400, John Porter wrote:
Isn't the functional definition of a sub
just another one of its attributes, anyway?
Oh my. Form 1, Content 0.
--
An ASCII character walks into a bar and orders a double. Having a bad
day? asks the barman. Yeah, I have a parity
[Quoting Michael G Schwern, on May 6 2001, 22:58, in Re: Apo2: \Q ambigui]
Hmmm, maybe you can point out the compose key on my keyboard, I
can't find it. ;)
Pick whatever you find convenient. I use the right control key.
From my .Xmodmap:
! Compose key
keycode 109 = Multi_key
I know
On Sun, 6 May 2001, Jarkko Hietaniemi wrote:
durian.
Aw, nuts. You beat me to it. Do we really think the externals will be
spiky and the internals smelly but delicious?
--- Joe M.
On Fri, May 04, 2001 at 09:06:47PM -0700, Nathan Wiger wrote:
%a = (%b : %c);# flattened like Perl 5
Why not this?
*%a = (%b, %c); # flattened. splat!
This makes sense to me since * is already proposed as the slurping
operator and since the LHS is providing context
$$STDIN # Return one element regardless of context.
@$STDIN # Return number of element wanted by context.
*$STDIN # Return all element regardless of context.
How about
$STDIN.$ # Return one element regardless of context.
Grocers either stock [durians] outside or frozen.
And I believe there are laws in some of the SE Asian countries where they
are more common that makes getting on public transportation with a durian
illegal.
Jeff
* Simon Cozens [EMAIL PROTECTED] [05/05/2001 17:51]:
%foo = ( foo = 1, bar = 1, '=' = 'baz' )
Of course, that could be spelt
%foo = +foo +bar =(baz);
Actually, it couldn't be because the in = would end the parsing.
Same problem that the POD chars have.
I think Uri's qh() suggestion
I think Uri's qh() suggestion is the cleanest:
Interesting train of thought, since one of the ideas was that qw() is
ugly and has to go. (Larry's been saying this for nearly two years now,
it's just that people sometimes don't listen. :) Let's keep it and add
something similarly ugly to
On Mon, May 07, 2001 at 01:27:52PM -0700, Nathan Wiger wrote:
I'm not against a cleaner way to do qw() in principle, but I
definitely think is not it for a lot of reasons (glob, readline,
can't use =, iterators, ...)
Sheesh. Yes, those would be problems with using in Perl 5.
However, we
Uri Guttman wrote:
what larry seems to want is qh() for quote hash.
%foo = qh( foo bar baz )
is like
%foo = ( foo = 1, bar = 1, baz = 1 )
Thank you for giving me a chance to drag out my favorite
soapbox again. :-)
What is needed is better support for treating hashes as
sets.
Larry Wall wrote:
We do have to worry about the Cnext loop control function though.
It's possible that in
FOO: while (1) {
next FOO if /foo/;
...
}
the CFOO label is actually being recognized as a pseudo-package
name! The loop could well be an object whose full
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:33]:
I'm not against a cleaner way to do qw() in principle, but I
definitely think is not it for a lot of reasons (glob, readline,
can't use =, iterators, ...)
Sheesh. Yes, those would be problems with using in Perl 5.
However, we are
On Mon, May 07, 2001 at 01:43:56PM -0700, Nathan Wiger wrote:
To quote you:
: http://dev.perl.org/rfc/28.pod
I'm not trying to be a jerk at all, but I think at times we're losing
sight of the above.
I hope not, since it was primarily written with you in mind. :)
--
He was a modest,
* Simon Cozens [EMAIL PROTECTED] [05/07/2001 13:46]:
To quote you:
: http://dev.perl.org/rfc/28.pod
I'm not trying to be a jerk at all, but I think at times we're losing
sight of the above.
I hope not, since it was primarily written with you in mind. :)
Hmm, that's odd. As I
Edward Peschko wrote:
If
%a = @b;
does
%c = map{ ($_ = undef ) } @a;
Yep... particularly considering something neat like
keys(%a) = @b;
could be defined to do that. Or, even niftier
@%a = @b;
--
John Porter
On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote:
Edward Peschko wrote:
If
%a = @b;
does
%c = map{ ($_ = undef ) } @a;
Yep... particularly considering something neat like
keys(%a) = @b;
And what is wrong with
@a{@b} = ();
which I use all the time. But I
Graham Barr wrote:
And what is wrong with
@a{@b} = ();
which I use all the time.
I use it too, because that's the perl5 idiom. But what's wrong with
it is that you don't have a set on the LHS, you have some funky hash
slice thing, with both the hash AND the keys being assigned into it.
On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote:
Yep... particularly considering something neat like
keys(%a) = @b;
See my earlier comments on lvalue operators. I *hope* lvalues will be
a lot more flexible in Perl 6. :)
--
Be not anxious about what you have, but about what
Simon Cozens writes:
However, we are not designing Perl 5.
This gets to a theme that is turning into more and more of an
irritant in following (and very occasionally participating) in the
ongoing discussion here.
There seems to be a sense among some participants that certain issues
are Off
On Mon, May 07, 2001 at 05:14:23PM +, Fred Heutte wrote:
It strikes me as counterproductive to say, Oh, that's ALREADY been
decided (with the distinct undertone of by the way please note
how out of touch you are), or That's fine but we're not designing
Perl 5 here (with the apparent
Simon Cozens makes a good point in response to my slightly overamped
oration on the qualities of dissent.
I am seeing most of the current discussion on this list as being
brainstorming on details, not painting the vast new blue skies,
and that is as it should be.
Acknowledging that making
On Mon, May 07, 2001 at 05:47:59PM +, Fred Heutte wrote:
And so there's a bit of a three-dimensional Rubik's Cube
game here to try and rejigger the use of the keyboard to make the
language more efficient and productive and maybe even clean out
some of the accumulated crud out there.
26 matches
Mail list logo
