On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw
around to your heart's content while modules are being compiled,
and to a lesser extent after compilation. But we'll never get to a
programming-in-the-large model if
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote:
finally by default? None for me; thanks, though.
I don't think so; we're just talking about whether you can extend a
class at _runtime_, not _compiletime_. Whether or not Perl can have
some degree of confidence that, once a
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
According to Michael Lazzaro:
As someone who has 90% of their projects relying very critically on
speed
... an anecdote ...
Yes.
and who has had to battle a number of clients' IT departments
over the years in defense of said
On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user
On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
But the agreement could be implied by silence. If, by the time the
entire program is parsed, nobody has said they want to extend an
interface, then the interface can be considered closed. In other
words, if you think you *might* want
On Thursday, December 11, 2003, at 10:04 AM, Larry Wall wrote:
Explicitly:
$bar.does(Color)# does $bar know how to be a Color?
$bar.as(Color) # always cast to Color
Implicitly boolean:
$bar ~~ Color # $bar.does(Color)
?$bar.Color # $bar.does(Color)
if
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know is would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as
of
3/25/03, which said ^[op] might be a synonym for or (Sorry,
no
fancy chars here. :)
Hey, that was *March*! ;-)
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have op and
op
do slightly different things. I assume that is also dead, and that
op is (typically) a syntax error.
Ack. No, slightly different things would
On Wednesday, November 26, 2003, at 12:13 PM, chromatic wrote:
On Wed, 2003-11-26 at 11:39, Michael Lazzaro wrote:
I think we also need to be skeptical of the false economy of putting
such sugar into CP6AN, if a sizable portion of the community is going
to download it anyway.
A more interesting
On Wednesday, November 26, 2003, at 01:50 PM, Michael Lazzaro wrote:
my $c = (defined($a) ? $a : $b);
Sorry, P5.
Before the grammar police attack...
my $c = (defined($a) ?? $a :: $b);
Parens for clarity.
MikeL
On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote:
If you contrast it with an explicit try block, sure, it looks better.
But
that's not what I compare it with. I compare it with Perl 5's:
$opus.write_to_file($file) or die Couldn't write to $file: $!;
That has some known
On Wednesday, November 19, 2003, at 12:28 PM, Smylers wrote:
Larry Wall writes:
: Michael Lazzaro wrote:
:
: return if $a { $a }
No, it's a syntax error. You must write
Excellent!
I too was quietly hoping someone would say that. These hurt my
admittedly ever-shrinking brain
On Tuesday, November 18, 2003, at 12:15 PM, Luke Palmer wrote:
Oh, and if you really want to do that return thing without using a
Cgiven, you can just:
sub blah {
return $a || goto CONT;
CONT:
...
}
I don't see what's wrong with that. :-p
Umm... refresh my/our memory.
On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
Given that we've introduced the concept of if having a return status:
my $result = if ($a) { $a } else { $b };
Would that then imply that
sub blah {
... # 1
return if $a;# 2
...
Would that then imply that
sub blah {
... # 1
return if $a;# 2
... # 3
}
...would return $a if $a was true, and fall through to (3) if it was
false?
It sure should, provided there were a correct context waiting, which
would
quite
On Thursday, August 14, 2003, at 07:00 AM, Alberto Manuel Brandão
Simões wrote:
On Thu, 2003-08-14 at 14:49, Simon Cozens wrote:
Just a hint: don't try writing it and revising it as the language
changes.
I wrote a Perl 6 chapter for a book in December and it is now almost
unusable
due to the
On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote:
On the subject of untyped scalars...what does it mean to say that the
conversion is 'lossless'? For example:
I've been using the word to mean that a conversion is lossless if,
for a particular A--B conversion, you can recreate the typed
On Monday, June 16, 2003, at 10:39 AM, Edwin Steiner wrote:
I'm content if this will be revisited (hopefully by someone with
better overview than mine). It just should not be ignored.
Oh, it definitely won't be ignored. :-) It's come up several times
before -- try searching for stringification,
On Monday, June 16, 2003, at 11:04 AM, David Storrs wrote:
On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote:
(I've been operating under the
assumption that an untyped scalar doesn't _remove_ the type of
something, it just can store values of _any_ type, and is by default
much more
On Monday, June 16, 2003, at 11:49 AM, Austin Hastings wrote:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
Or, if we have output rules just like we have input rules, could
something quite complex be expressed simply as:
You have $x as MoneyFormat
having previously defined your MoneyFormat
On Wednesday, June 11, 2003, at 05:48 AM, Tim Bunce wrote:
(vi) Conversions of User Defined Types/Classes
It may be useful to allow the same level of pragma-based control for
user-defined types and classes. For example, a given class Foo may
wish to be silently convertable to an
Seeing as how lots of folks are on the road, and you can hear the
on-list crickets chirping, I'm not sure if anything can be
accomplished, but I'll repost this as one of those perennial
things-which-really-need-to-be-decided-because-lots-of-stuff-is-
On Monday, June 9, 2003, at 07:13 AM, Adam Turoff wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Assuming I'm not misunderstanding what Adam is after, this has
come up
before (I think I asked about value based dispatch a few months
back)
and I can't remember if
On Monday, June 9, 2003, at 09:19 AM, Mark A. Biggar wrote:
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function
On Monday, June 9, 2003, at 03:45 PM, Dave Whipp wrote:
Michael Lazzaro [EMAIL PROTECTED] wrote
multi bar (Foo $self, int $i : ); # semicolon optional
pedantic
I think you meant colon optional. The semi-colon is, I think, a
syntax
error. You need the yada-yada-yada thing
On Thursday, May 29, 2003, at 10:47 AM, Dave Whipp wrote:
OK, we've beaten the producer/consumer thread/coro model to death.
Here's a
different use of threads: how simple can we make this in P6:
Hey, good example. Hmm...
Well, for starters I think it wouldn't be a big deal to associate a
On Thursday, May 29, 2003, at 12:45 PM, Dave Whipp wrote:
Michael Lazzaro [EMAIL PROTECTED] wrote in # But if
you want
to get the thread object, so you can monitor it's
{
...
my $tid = thread slow_func_impl(...);
while $tid.active {
status_monitor
On Thursday, May 29, 2003, at 04:48 PM, Luke Palmer wrote:
To nitpick:
my $result is lazy::threaded := { slow_fn_imp @_ };
Pursuing this lazy-threaded variables notion, a question. Given:
sub slow_func is threaded {# me likey this
auto-parallelizing syntax!
...
}
On Tuesday, May 27, 2003, at 07:32 PM, Jonathan Scott Duff wrote:
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
If we could think about threads not in terms of forkyness, but
simply
in terms of coroutines that can be called in parallel, it should be
possible to create
On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
Exampling:
sub traverse(Hash $tree) {
return unless $tree;
traverse $tree{left} if $tree{left};
yield $tree{node};
traverse $tree{right} if $tree{right};
}
my %hash is Tree;
my cotrav := coro traverse(%hash);
print $_ for
On Wednesday, May 28, 2003, at 02:56 PM, Austin Hastings wrote:
(s/coroutine/thread/g for the same rough arguments, e.g. why should
the caller care if what they're doing invokes parallelization, so
long as it does the right thing?)
Global variables. Threads __never__ do the right thing.
Heh.
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
What I'm getting at is that all these concepts are much more related
than they might at first seem, and that the differences between them
are largely of scope. If we have some form of coroutines, _and_
can run them
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
So, in summary, its good to have a clean abstraction for all the HCCCT
things. But I think it is a mistake to push them too close. Each of
the HCCCT things might be implemented as facades over the underlying
othogonal concepts of data
On Monday, May 26, 2003, at 06:51 PM, John Macdonald wrote:
This is an interesting idea. I'd add forked processes
to the list (which includes the magic opens that fork
a child process on the end of a pipeline instead of
opening a file.
I thought about that quite a bit, but fork() is a
On Tuesday, May 27, 2003, at 12:26 PM, Luke Palmer wrote:
We could also have things like:
sub { ... }
closure { ... }
I think you've finally gone crazy. :-)
All four of these things are closures.
coroutine { ... }
thread{ ... }
Well, yes, I've been crazy for a while
On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote:
I like and agree with some of what you've been saying. I too think that
there's a case of an x is just a y with ... underlying the whole
coro/thread/parallel thing. That's why I'm in favor of deconstructing
the threading thing -- a
On Tuesday, May 27, 2003, at 01:49 PM, Jonathan Scott Duff wrote:
I think there's some timing missing (or maybe it's just me). Executing
a
Code junction implies that I have all of the routines I wish to execute
in parallel available at the same time. This is often not the case.
Or if adding a
Luke Palmer wrote:
As much as I don't want to refute my own operator, I agree with you
here. I don't know what the official (this week) policy is, but I
think it's a bad idea for references to auto-dereference. The other
way around is fine, though (arrays auto-referencizing).
I'm pretty darn
One thing we should clear up is that we already *have* a generic
comparator, C~~, depending on what you mean by generic. It can be
made to compare things however you like, according to whatever standard
of similarness you decide you want to enforce, and can even compare
objects of disparate
On Tuesday, April 1, 2003, at 06:59 AM, Jonathan Scott Duff wrote:
On Tue, Apr 01, 2003 at 03:22:33AM -0700, Luke Palmer wrote:
($a =:= $b; # looks a little better)
I like =:= as identity operator if we want one. If not, as long as .id
returns something that compares properly with both == and
On Tuesday, April 1, 2003, at 02:22 AM, Luke Palmer wrote:
To outline the problem again, even disregarding user-defined objects:
Generic containers need a way to compare nums to nums and strings to
strings and only get true when they actually are equal. The kind that
the user overloads with his
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 11:04:35AM -0800, Michael Lazzaro wrote:
my bool $x = result_of_some_big_long_calculation(...args...);
return $x if $x;
Is there a way that doesn't require the named variable?
$_ and return given
On Monday, March 31, 2003, at 11:21 AM, Smylers wrote:
Michael Lazzaro writes:
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
return result_of_some_big_long_calculation
On Monday, March 31, 2003, at 07:39 AM, Piers Cawley wrote:
Argument initializations
Michael Lazzaro summarized the various different and proposed
assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how
On Monday, March 31, 2003, at 10:15 AM, Jonathan Scott Duff wrote:
On Mon, Mar 31, 2003 at 10:09:43AM -0800, Michael Lazzaro wrote:
I'm still hoping rather desperately for a if-uninitialized op in
general, even if only for hashes, because the difference between
present but undefined
Forgive me; a very minor style efficiency question... what would the
canonical way to do this be, given what we know of Perl6?
# the hapless, inefficient version:
...
return result_of_some_big_long_calculation(...args...)
if result_of_some_big_long_calculation(...args...);
On Tuesday, March 25, 2003, at 12:59 PM, Smylers wrote:
Michael Lazzaro writes:
Larry Wall wrote:
We don't have a word for START right now. It's somewhat equivalent
to
state $foo //= 0
unless $foo gets undefined, I suppose.
Assuming we have a static-like scope called Cstate, one can
Robin Berjon wrote:
one metric ton of useful stuff, in various messages, all of which I
agree with
Including...
The data binding folks have tried to address the problem using XML
Schema, and the result is, hmmm, unpleasant to use something polite.
The SOAP and WSDL people have been at it, and
On Tuesday, March 25, 2003, at 06:17 PM, Damian Conway wrote:
Likewise, I read
sub foo($x //= 1) {...}
as saying the value stored in $x is a constant, but if the caller
passed an undefined value (or didn't pass anything at all), we're
going to instead pretend they passed us a
On Tuesday, March 25, 2003, at 11:08 AM, Jonathan Scott Duff wrote:
On Tue, Mar 25, 2003 at 10:42:39AM -0800, Michael Lazzaro wrote:
But it is certainly possible to extend the initialization capabilities
to be more robust:
sub foo($x = 'blah') {...} # wrong: use one of the below
On Tuesday, March 25, 2003, at 03:35 PM, Mark Biggar wrote:
sub myprint(+$file is IO:File is rw ::= IO:STDOUT, [EMAIL PROTECTED]) {...}
open f /a/d/v/f/r;
myprint file = f, Hello World!\n; # goes to f
myprint Differnet World!\n;# goes to IO:STDOUT
As a side note... that sig will not do
On Tuesday, March 25, 2003, at 02:19 PM, Damian Conway wrote:
And I don't think that allowing 20 different types of assignment in
the parameter list of a subroutine actually helps at all. Especially
since the vast majority of parameters in Perl 6 will be constant.
Twenty types of
Getting back to A6, a few thoughts. From the 'Re: is static?' thread:
On Wednesday, March 19, 2003, at 08:30 AM, Larry Wall wrote:
Well, people *will* write
state $foo = 0;
The question is what that should mean, and which major set of people
we want to give the minor surprise to, and how
So, is anyone working on a P6ML, and/or is there any
discussion/agreement of what it would entail?
MikeL
On Tuesday, March 25, 2003, at 11:02 AM, Robin Berjon wrote:
Michael Lazzaro wrote:
So, is anyone working on a P6ML, and/or is there any
discussion/agreement of what it would entail?
Imho P6ML is a bad idea, if it means what I think it means (creating a
parser for quasi-MLs). People will laugh
On Wednesday, March 19, 2003, at 09:58 AM, Larry Wall wrote:
: sub foo($x, [EMAIL PROTECTED], +$k) {...}# (2) OK
Fine, you can set @a using positional notation, like push(), in
addition to the notations available to (1). But if you set k =,
it has to be before the list, unless you pass
On Tuesday, March 18, 2003, at 06:49 AM, Paul wrote:
Merely for the one small thing I might possibly contribute
Would it be useful to have a convenient place to do polls?
I suspect there already is one somewhere, but I'm unaware of it.
I don't want to undermine the authority of the core
Damian wrote:
Hence, I would argue, one ought to simply mark it with a trait:
FWIW, I personally think this is _absolutely_ the right approach.
Using a trait is a very visible, very obvious way to say what's going
on that is probably easier to remember than adding another keyword to
the
On Tuesday, March 18, 2003, at 09:55 AM, Austin Hastings wrote:
To me, this says that there's no real commitment to doing XML. What
there is seems to be a recognition that XML format is regular and
comprehensible to others, so writing XML-like files becomes popular.
Yep. Which makes things even
OK, divide conquer. We seem to be spasming about this and trying to
talk about N things at once, so here's an issue summary. We're talking
about at least two separate cases, (1) inferring type where none has
been specified, and (2) coercing a typed value into another type.
Let's take these
On Friday, March 14, 2003, at 11:06 AM, Michael Lazzaro wrote:
AFAICT, these are the *only* possible solutions to the problem. At
last count, Larry was leaning towards #2. Damian was countering with
#1. Some Lowly Grubs were suggesting #3. Am I missing anything?
Whoops! That needs
On Friday, March 14, 2003, at 12:21 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
3) If an untyped var is used for a typed parameter, a simple
dataflow analysis is used to determine whether the compiler can
guarantee that, at that point, an untyped var will _always_ contain
values of a known
A simple question, I hope...
From A6, Calling Subroutines, comes the following:
multi push(@array, +$how, [EMAIL PROTECTED]) {...}
push(@a, how = 'rapidly', 1,2,3); # OK
push(@a, 1,2,3); # WRONG, $how == 1!
Oops! What you really wanted to say was:
multi
On Wednesday, March 12, 2003, at 04:07 PM, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
Can we get a final answer, for the (documented) record?
@list is variadic
@list is slurpy
@list is greedy
@list is slurpificatious
@list is slurptacular
@list
On Thursday, March 13, 2003, at 01:05 PM, Austin Hastings wrote:
More to the point:
type sigfunc is interrupt is reentrant;
sub sig_ign() is sigfunc {...}
sub sig_kill() is sigfunc {...}
sub sig_intr() is sigfunc {...}
This is WAGging based on A6, but I guess I see things like this as
being
On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
What we do need is some way of bundling a bunch of traits together
under a simple name.
Yes, yes, yes.
Defining a Class for this is also overkill.
Ye.. well, no. Why?
So instead of saying:
my %pet is Hash of Array of Array
I think the issue of type coercion (forcing one type to another) should
be decided separately from the issue of implicit types (recognizing
when an untyped variable can be KNOWN at a given point to hold a
specific type, even if it isn't explicitly stated.)
As far as true coercion goes: for the
On Wednesday, March 12, 2003, at 05:03 PM, Deborah Ariel Pickett wrote:
Sort of a rehash on an old topic, but there's new stuff now with A6.
Mike Lazarro had been making a list of all the operators that Perl6
has.
The latest version I could find was Take 6 (at
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
On Wednesday, March 12, 2003, at 11:07 AM, Damian Conway wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically wrap the @input array
On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
You want Cmulti to tell the compiler to build in multiple dispatch.
Any invocation of Cfoo after Cmulti foo is going to be a penny
dropped into the great Pachinko game of multimethod-dispatchery. By
default, if no winning multi
Larry wrote:
: multi foo (@a is Array of int) {...}
:
: my int @a = baz(); # is Array of int
: my @b = baz(); # is Array of Scalar
:
: foo(@a);# @a is typed correctly, so OK
: foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
snip
I dunno. I can argue that
On Tuesday, March 11, 2003, at 08:41 AM, Brent Dax wrote:
Almost makes you wish for those backwards declarations from C that
computer scientists always gripe about, eh? :^) Well, what about
this?
multi substr(Str $str, $from = $CALLER::_ is optional, $len =
Inf is optional, $new is
On Tuesday, March 11, 2003, at 06:42 AM, Richard Proctor wrote:
If one has a simple sub such as factorial:
sub factorial(int $a) {...}
then one subsequently declares the multi form of factorial to pick up
the
non-integer form:
multi factorial(num $a) {...}
Does this promote the original
On Tuesday, March 11, 2003, at 11:19 AM, Austin Hastings wrote:
But you can't wrap multi-ness, as far as I can tell.
[A6]
And it happens that the multimethod dispatch is smart enough to find
the ordinary single-invocant sysread method, even though it may not
have been explicitly declared a
Since noone else has said it yet -- This Apoc looks *great*. The sig
stuff is very, very nice. (The wrapper stuff has interesting
possibilities, too, especially with OO.)
Question on pipes: I like very much the concept of relating them only
to the variadic list, that was the piece we were
In A6, it is confirmed that you can have complex types such as:
my %pet is Hash of Array of Array of Hash of Array of Cat;
It is also confirmed that you can indeed use such types in sub
signatures, e.g.:
sub foo (@a is Array of int) {...}
Confirmations/Questions:
1) Complex types for sub
On Saturday, February 15, 2003, at 08:47 AM, David Storrs wrote:
I can see five possible courses here:
1) We decide that my suggestion is a bad one and do nothing with it.
That's fine; I am not wedded to it, I just thought it was an
interesting idea that I wanted to raise.
2) (4, 1, 2)
On Wednesday, February 12, 2003, at 05:50 PM, Deborah Ariel Pickett
wrote:
All right, I'm prepared to buy that. Now how would it extend to
hashes?
A %hash in list context returns a list of its pairs (NOTE4)
A %hash in scalar context returns a reference to itself (NOTE1)
A %hash in numeric
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just
50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to
On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
Indeed, this supports the distinction, which I will reiterate:
- Arrays are variables.
- Lists are values.
My hesitation about the 'arrays are variables' part is that Damian
corrected me on a similar thing when I was
On Monday, February 10, 2003, at 06:26 PM, Joseph F. Ryan wrote:
Deborah Ariel Pickett wrote:
(Just going off on a tangent: Is it true that an array slice such as
@array[4..8]
is syntactically equivalent to this list
(@array[4], @array[5], @array[6], @array[7], @array[8])
? Are array
On Tuesday, February 11, 2003, at 10:56 AM, Garrett Goebel wrote:
What about this?
\@array
hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a
reference
to themselves in scalar context... I'm not sure what context '\' puts
them
in.
I'd guess \@array is a reference to an
On Saturday, February 8, 2003, at 02:53 AM, Luke Palmer wrote:
If you're talking about your own Cfor example, actually, this would
match it better:
grep $x - @list { $x eq 3 }
But if you're talking about A4's:
grep @list - $x { $x eq 3 }
Which is very close to (one of) the currently
On Friday, February 7, 2003, at 03:38 PM, Uri Guttman wrote:
but you can't derive the rules about allowing push/pop/splice/slice
from
that pair of defintions.
Is there any syntactic reason why both of the following cannot be
allowed?
(1,2,3).pop
[1,2,3].pop
I don't know that one is
I'm trying, and failing, to accurately and definitively answer the
question what's the difference between an array and a list in Perl6?
If someone can come up with a simple but accurate definition, it would
be helpful.
MikeL
On Friday, February 7, 2003, at 02:07 PM, Uri Guttman wrote:
the whole notion is that lists are always temporary and arrays can be
as
permanent as you want (an array ref going quickly out of scope is very
temporary). lists can't live beyond the current expression but arrays
can.
Along those
On Friday, February 7, 2003, at 04:24 PM, Uri Guttman wrote:
ML \(1,2,3)
ML returns an array reference...
in perl5 it returns a list of refs ( \1, \2, \3 ). i dunno the perl6
semantics. it could be the same as [ 1, 2, 3 ] which means it is not a
Sorry, I was misremembering a
A status update:
1) I'm actively working on the array section, and will start the hash
section soon, if nobody else wants it. (I posted the outline I'm
working to in my last message here.)
2) I'm working on a cleanup of the whole front section, based on our
all our existing content plus
On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote:
Or for the extremely thick:
GOOD: Separate syntax for indexed vs. named lookups
BAD: Same syntax with = 2 contextual meanings
Seriously, everyone read Damian's Seven Deadly Sins thing, if ya
haven't read/heard it already.
On Thursday, January 30, 2003, at 09:55 AM, Dan Sugalski wrote:
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:
This is leading me to the conclusion that primitive-typed arrays
should not be allowed to have defaults, period, and that attempting
to place one should be a compile-time error
On Thursday, January 30, 2003, at 10:56 AM, Austin Hastings wrote:
There is no reason why primitive-typed arrays can't have a default. It
is the confusion of default with undef that is causing this
problem.
Yes, I misspoke. You can have a default, which it will use for
autofill
For Cis computed arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2];
[EMAIL PROTECTED] wrote:
Shouldn't access to 'is computed' arrays be read-only?
In general, I would hope that 90% of them would be, but it's been
stated that it won't be a requirement. But hey -- note that, for
starters, this would mean that you could easily use an array for
caching
On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff wrote:
So you can't set something to its type's own empty value, because it
will, by definition, thereafter return it's overloaded empty value,
def.
Looks like a maintenance nightmare to me.
Agreed, it's not pretty. The
OK, here are the answers so far -- or more accurately, strawman
interpretations of those answers that should be objected to if they're
wrong.
1) Edge cases in array indexing:
my int @a = (1,2,3);
@a[0] # 1
@a[1] # 2
@a[2] # 3
@a[3] # undef
On Tuesday, January 28, 2003, at 10:20 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote:
1) Edge cases in array indexing:
my int @a = (1,2,3);
@a[3] # undef (warning: index out-of-bounds)
Or a real 0, since you said @a can only return integers
There has been discussion of allowing a default value for array cells
-- that is, one aside from Cundef or whatever the type-specific
default is. Questions, in order of increased evilness:
1) What's the final decided syntax? Two possibilities:
my @a is Array( default = 'foo' ); #
Corrected in accordance with design team member feedback. These should
be solid, now. Thanks much for the responses.
1) Edge cases in array indexing:
my @a = (1,2,3);
@a[0] # 1
@a[1] # 2
@a[2] # 3
@a[3] # def (warning: index
On Tuesday, January 28, 2003, at 01:14 PM, Damian Conway wrote:
I'm not compelled by the counter-argument that this makes it
impossible to store an Cundef in an array with a default. Because
the whole point of an array having a default is to prevent those nasty
out-of-range Cundefs from
1 - 100 of 360 matches
Mail list logo
