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 base
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
On Tuesday, December 16, 2003, at 03:00 PM, Luke Palmer wrote:
But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will
make it easy to figure that out in most cases. I was coming from the
perspective that 90% of my projects don't need speed; but I can say no
such thing on account of
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 prog
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 we
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 to
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 $b
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightl
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 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 prob
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: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 Monday, November 24, 2003, at 03:28 PM, Luke Palmer wrote:
Damian Conway writes:
In which case I think we just fall back to:
try{$opus.write_to_file($file); CATCH {die "Couldn't write to
$file:
$!"}}
which is, after all, only 5 characters longer than:
$opus.write_to_file($file) c
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
C, 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. Did we
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-shrinki
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 nicel
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
...
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 pac
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
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
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 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 type
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 C.
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-
dependant-on-it-in-terms-of-basic-A2-exam
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
I think you meant "colon optional". The semi-colon is, I think, a
syntax
error. You nee
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 inste
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 t
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 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
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
"prog
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. Tha
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 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
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 Cod
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 low
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 no
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 process-leve
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 manag
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,
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 disparat
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 su
On Tuesday, April 1, 2003, at 10:35 AM, John Williams wrote:
On Tue, 1 Apr 2003, Michael Lazzaro wrote:
So I would imagine it _is_ possible to test that two values "have the
same identity", but I would imagine it is -not- possible to actually
get what that identity "is". T
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 o
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 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_cal
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 retu
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 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
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'.
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 C
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 (still-constant)
Robin Berjon wrote:
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 I won't even describe
the result because I couldn't possibly be polite about
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 _initialization
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 n
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
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
So, is anyone working on a P6ML, and/or is there any
discussion/agreement of what it would entail?
MikeL
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 m
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 pas
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 ev
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 [my|our
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 planni
On Monday, March 17, 2003, at 10:35 AM, Luke Palmer wrote:
I've been thinking of it like this:
class int isa intlike; # and isa value or whatever
class Int isa intlike; # and isa Object or whatever
class num isa numlike; # and isa value or whatever
class Num isa numlike; # and isa Object
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 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_
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
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 t
On Thursday, March 13, 2003, at 01:23 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa("Baz") == FALSE;
A lightweigh
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 imp
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
@l
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 of
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
http://archive.develooper.com/[EMAI
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 th
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 Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not C!
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 C.
Riiight! Thank-you, General Haig
On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
You want C to tell the compiler to build in multiple dispatch.
Any invocation of C after C is going to be a penny
dropped into the great Pachinko game of multimethod-dispatchery. By
default, if no winning multi appears, the call falls
On Tuesday, March 11, 2003, at 05:18 PM, Damian Conway wrote:
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
I don't know...maybe I'm worry
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 multim
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 decla
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 optional)
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 C; OK or FAIL?
I dunno. I can argue that i
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 su
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 all
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 (sc
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 al
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 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 slices
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 writin
On Saturday, February 8, 2003, at 02:53 AM, Luke Palmer wrote:
If you're talking about your own C 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 v
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 threa
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
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 l
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, 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 10:44 PM, Leopold Toetsch wrote:
Michael Lazzaro wrote:
[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
[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 things
On Thursday, January 30, 2003, at 12:49 PM, Austin Hastings wrote:
undef @a[5]; # undefining the element sets it to the default
@a[5]; # 2
@a[5] = undef; # same as above
@a[5]; # 2
undef!!
@a is an array of Int (not int) and can store undef, so no error occurs
For C 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]; # 4 (doesn
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 & out-of-
1 - 100 of 297 matches
Mail list logo
