--
On Fri, 14 Mar 2003 10:08:15
Larry Wall wrote:
On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote:
: I think that there should be two types of arg typing[1]: 'strict' and
: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses
: into superclasses; loose arg typing,
--
On Thu, 13 Feb 2003 16:03:41
Joseph F. Ryan wrote:
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral
--
On Tue, 11 Feb 2003 12:28:23
Luke Palmer wrote:
Date: Tue, 11 Feb 2003 10:34:57 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
Indeed, this supports the distinction, which I will reiterate:
- Arrays are
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray is a variable that holds a list.
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence
--
On Fri, 7 Feb 2003 16:28:43
gpurdy wrote:
All --
A4 gives this example of Cfor:
for @foo - $a, $b { ... } # for @foo into $a and $b...
but, this seems more natural to me (and, it turns out, closer to the P5
syntax for ill or good):
for $a, $b - @foo { ... } # for $a and $b
--
On 17 Nov 2002 11:09:53 -050
Bryan C. Warnock wrote:
On Wed, 2002-11-13 at 13:26, Angel Faus wrote:
There are many ways to specify literal numeric values in perl, but
they default to base 10 for input and output. Once the number has
Surely, Perl 6 will allow changing the radix on a
--
On Mon, 11 Nov 2002 13:02:12
Brent Dax wrote:
Erik Steven Harrison:
# I think that, if Perl can determine the type with virtually no
# ambiguity, it should autovivify.
#
# Actually, this behavior has already (mostly) been decided over in P6
# language. It was decided (and I agree
--
On Sat, 9 Nov 2002 23:22:45
Brent Dax wrote:
Michael Lazzaro:
# Brent Dax wrote:
#
# I was writing up some docs (in a perldoc-like style--we can always
# change the form later, but the content is important), and started
# working on documenting references. I ended up with this
On Sat, 09 Nov 2002 13:21:06
Michael Lazzaro wrote:
Markus Laire wrote:
On 9 Nov 2002 at 18:56, Andrew Wilson wrote:
I will be happy to be proved wrong about this but I have a feeling that
too much attention to detail will get us bogged down.
I also think that we shouldn't try to
--
On Thu, 31 Oct 2002 15:08:06
Brent Dax wrote:
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
Is that a call to
sub something() returns(IO
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is operator ever going to be
confused for $File_Handle? The vector operation
--
On Sat, 26 Oct 2002 21:02:20
Larry Wall wrote:
On Sat, 26 Oct 2002, Steve Canfield wrote:
: Will Perl6 have labeled if blocks? Like this:
:
: BLAH:
: if ($foo) {
: ...
: last BLAH if $bar;
: ...
: }
I don't see why we need it offhand. But we might well have
--
On Mon, 21 Oct 2002 16:49:57
Dan Sugalski wrote:
Almost. At least perl 5's macros look like C. Emacs' macro horrors
make C look like Lisp...
This is because C is _clearly_ a dialect of Lisp . . .
-Erik
--
Dan
--
On Thu, 3 Oct 2002 18:46:14
Michael G Schwern wrote:
I see us already smashing too many things into the method signature as it
is. It will rapidly get messy if you have a method with a complex signature
and a handful of attributes and preconditions.
This is the sort of creeping
--
On Thu, 26 Sep 2002 14:06:50
John Williams wrote:
We should respect default values if arrays can declare them.
Perhaps there will be a modifier for operator declarations to declare what
the default behavior should be. Otherwise I don't know how different
behaviors for different
--
On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:
Think of it as punctuation. As a necessary alternative to the poor
overworked colon.
Or the poor overworked dot?
it all looks the same to me. And I like different things to look different.
A fair point. My counterargument is
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
Erik Steven Harrison wrote:
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int
reposted because my mailer is evil
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
Erik Steven Harrison wrote:
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol
--
On Thu, 05 Sep 2002 09:26:08
Damian Conway wrote:
Erik Steven Harrison wrote:
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is to apply a
property.
That's because most of the problems
It seems to me that what I mostly do is wave my arms
about my head with a concern and then stay silent
whenever praise is required. Everyone - consider
yourselves praised :-)
On to the concern (which I am fairly confident someone
will obviate). I've never touched the Perl internals
(and P5P
--
On Wed, 4 Sep 2002 07:45:37
Sean O'Rourke obviated:
To me a language's grammar, once
defined, shouldn't do a lot of changing, internally or otherwise. When
was the last time C's grammar changed? Or even gcc's implementation of
it?
Granted . . .mostly. Were talking about Perl, the
Somewhere, in another thread . . .
Dr. Claw wrote . . .
sub hidden (str $name, int $force is aka($override))
{ ... }
Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is
sub hidden (str $name, int $force is aka($override))
{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{ .
From: [EMAIL PROTECTED]
Wow, this is nice. He means (I think) that this will be translated into
my Date $bday = Date-new('June 25, 2002');
I don't think this is going to work. First off, there
is no predefined constructor name in Perl. Secondly,
you can have multiple constructors in the
I've sent this message before, but Piers was kind
enough to point out that the CGI script I'm forced to
use to send mail does not readably format my messages,
increasing the likelyhood that they are ignored. So
here's a repost that's (hopefully) better to read.
Somewhat random question here:
We all know how to alias things in Perl 5. The binding operator allows aliasing in
Perl 6, I understand. So, how do we alias grammer rules? Here are my guesses.
Rules live in the same namespace as subroutines, so you can use the . Or possibly
(because
Long have I been a fan of giving pure Perl modules the power to change the rules and
create a more built-in look, feel, and functionality. So, of course, I love %MY, I
love real named parameters, I love the ability to create iterators that look just like
native control structures. But while
Karl Glazebrook [EMAIL PROTECTED] disgusted:
@solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
[Stuff]
If I was forced to write vector code like this I *WILL* give up on perl,
and resort to Numerical
Python or IDL instead.
You can always use the map and foreach like we've
What about parsing? I think the fact that Perl 6 will pretty much
have parser capabilities built in is pretty distinctive.
Ted
When someone wants to write a parser, they turn to Perl 90% of the time (at least to
prototype). The fact that they're really using a powerful lexer instead of a
But unlike
iterators, when you ask a generator for the next value, it picks up
execution exactly where
it left off when it returned the last value -- i
Aren't these what The Damien calls coroutines? Are we getting coroutines (RFC 30, as I
recall . . .)? I'm also big on seeing these.
Also,
Michael Schwerned:
I've been trying to pick out what parts of Perl 6 would make a Java
programmer sit up and go I wish I had that or a Python programmer think
Hmm, maybe there is more than one way to do it and, in fine Perl
tradition, a few things which make the whole audience go what a bunch of
--
On 02 Jul 2002 09:56:46 +010
pdcawley summed:
Ruby iterators
Ruby interators were the subject of Erik Steven Harrison's post, which
also referred to 'pass by name' and 'the Jensen Machine', and wanted to
know 'the Perl 6 stance on the matter'. Nobody has yet stepped up to
--
On Sun, 30 Jun 2002 21:09:40
Sean O'Rourke wrote:
On Sun, 30 Jun 2002, Ashley Winters wrote:
I don't know how the grammars are going, and I'm not fit to write one
myself,
Hey, neither am I, but that hasn't stopped me from taking a stab or two,
figuring that through pain comes
EvilScientist cat=white
Ah, Mr Wardley, I see you have finally apprehended the magnitude of my
nefarious plan. Five years of plotting and scheming, of gaining influence and
gradually insinuating my dastardly code creations into the community
consciousness: all
about to culminate in unleashing
--
On Wed, 5 Jun 2002 13:21:39
Brent Dax wrote:
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#a href=aimg src=sss!banner..etc#
#
# after
#
# m#\a\
--
On Thu, 16 May 2002 12:36:42
Miko O'Sullivan wrote:
SUMMARY
Arrays should always have known lengths because that's what arrays do. This
requirement is enforced culturally, not programmatically.
I totally agree that this should be enforced culturally. I think that the way a tied
(Perl6 syntax obviously). I hope it's going to be possible to set that
up automagically... (Yeah, I know, if/when Perl 6 gets macros...)
I've been playing around with Perl 5.6's lvalue subs. And (though at times irritating
to deal with) they're wonderful. It seems to me that the use of an
--
On Mon, 6 May 2002 16:26:16
Dan Sugalski wrote:
*Alot of good answers to questions*
Appreciate the descent from the mountain to help clear things up down here.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at
Lots of people said:
Lots of stuff about 'else' loops.
*Erik thunks himself some deep thought*
I see no true slippery slope here, especially if handled correctly. I suspect that an
explicit or implicit why not near the beginning of discussion lead to the feature
feeding frenzy and the
--
On Fri, 12 Apr 2002 18:27:11
abigail wrote:
On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
[EMAIL PROTECTED] writes:
Why isn't
if %foo {key} {print Hello 1}
equivalent with the perl5 syntax:
if (%foo) {key} {print Hello 1}
Which keyword is it
$a is a hash key
$b is an array index
$c is another hash key
So, if I try:
multi_dim[$b][$a][$c]
then it's obviously going to break. But how can I, the
programmer, easily spot that? It's not as clear as:
multi_dim{$a}[$b]{$c}
where I can see what I'm getting as I work through the
data
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
43 matches
Mail list logo