Simon Glover wrote:
On Wed, 11 Dec 2002, Simon Glover wrote:
Is this a bug, or am I misunderstanding how properties are supposed to
work?
I did check in (a totally untested) fix.
leo
> Are the Tru64 registers scanned for live PMCs/Buffers? I don't know
> what things would typically get missed that way, but it's a known
> problem for most architectures (or was until recently? What's the
> status on this?)
I don't know if they are or not. How could you tell?
> Does Tru64 have
Luke Palmer:
# > There's no need for special methods or (gods forbid) more operators.
# > Just:
# >
# > $obj1.id == $obj2.id
# >
# > That's what the universal C method is *for*.
#
# I rather like that. It's used for hashing by default (in
# absence of a stringification or .hash (?) method
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #18782]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18782 >
As no one complained (or answered) I have checked in
> Date: Thu, 12 Dec 2002 02:19:18 -0500
> From: Dan Sugalski <[EMAIL PROTECTED]>
>
> Since that may be either:
>
>$foo = bar($x, $y), foo()
>
> in which case it's in scalar context, or
>
>$foo = bar($x, $y, foo())
>
> in which case it's in list context (sort of)
>
> The fun thing is that
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote:
> [Dks wrote:]
> > So...are we intending that types and type safety will be like 'use
> > strict' (optional and only on request), or will they be like sigils
> > (mandatory, can't be turned off)? Or, perhaps, on by default but able
> >
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote:
> Dave Storrs wrote:
> > - the ability for the programmer to set "limiters" (??better name??)
> > on the junction, which will specify how the junction should
> > collapse--e.g. always collapse to the lowest/highest value that hasn't
> >
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote:
> "Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> > After thinking about it a little more, I'll set myself on the "yes"
> > side. And propose either '===' or ':=:' to do it.
>
> Definitely '==='.
Hopefully, this thread has been settled
Simon Cozens <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
>> About this point was when my brain when "a ha!". But I'm not yet
>> convinced that generating all possible parses is (a) of sane time
>> complexity, and (b) a little *too* DWIM for its own good.
>
> As
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
>> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
>> Are we married to the "AS_*" thing?
>
> Not really -- whatever works. We also had .debug, .identity, and .id
Damian Conway writes:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
> $obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
How universal are universal methods?
That is, can a programmer override .id() in a user-defined class? If so,
simpl
Simon Cozens <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Dave Whipp) writes:
>> There is a difference between verbs and noun. Sometimes you don't want
>> to associate a verb with an object: you want to associate it with the
>> subject:
>
> Verbs are almost always associated with their subject
Luke Palmer <[EMAIL PROTECTED]> writes:
>> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>> Date: Wed, 11 Dec 2002 19:21:35 -0500
>> From: John Siracusa <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>>
>> On 12/11/02 6:16
I'd like to help write some test cases for Perl6 to deliver on that
part of this group's charter.
I'm having problems getting Perl 6 working, and I'd like help. This
may be off-charter for this group, but there's hardly a better place,
and the info is probably generally useful to others also seek
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #18745]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18745 >
I did put in a patch based on #18745
- jit/i386 tes
[EMAIL PROTECTED] wrote:
Dan --
We were talking earlier about Jako supporting native calls. I have looked
at PDD 6 and PDD 3, and here's what I think so far...
I don't think I can get the native call stuff working until I have IMCC
support
for PDD 3. IMCC is totally in charge of what goes into
On 12/10/2002 5:46 PM, Smylers wrote:
OK. There was something on MJD's QOTW recently where using the current
Perl 5 Memoize module slowed code down -- that gave me the impression
that caching had the potential.
It does. In fact, all caching has that potential. Specificly, if the
time to look
[EMAIL PROTECTED] (Stephen McCamant) writes:
> Simon> I'm afraid I can't tell whether or not I'm being serious any
> Simon> more.
>
> I don't know if this has been discussed before, but there are
> completely serious parsing algorithms that work this way
Morale: If you can come up with a crazy en
Michael Lazzaro asked:
> foo $a, $b, $c, $d; # how many args?
Damian Conway wrote:
> Yep. Can't be known unless predeclared and hence compile-time discernible.
> And methods can't be discerned in the presence of run-time dispatch.
Is that not the purpose of an interface? That is, to specify at
On 12/12/2002 5:50 AM, Aaron Crane wrote:
Damian Conway writes:
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal C method is *for*.
How universal are universal methods?
That is, can a programmer override .id() in a
On Thursday, December 12, 2002, at 10:49 am, Piers Cawley wrote:
Luke Palmer <[EMAIL PROTECTED]> writes:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Wed, 11 Dec 2002 19:21:35 -0500
From: John Siracusa <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http:
On Tue, 10 Dec 2002 13:02:18 -0800, Brent Dax wrote:
> Peter Haworth:
> # @b = @a.grep { /\S/ }, $c;
> #
> # how does the compiler know whether $c is an argument to grep,
> # or another element to be assigned to @b?
>
> The same way it does when it sees a normal sub?
>
> I know, late binding
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 11 Dec 2002 17:24:54 -0800
> From: Dave Storrs <[EMAIL PROTECTED]>
> Mail-Followup-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Thu,
Stabs gdb support now can show parrot registers.
e.g. complicated program:
set I0, 10
set N1, 1.1
set S2, "abc"
(gdb) p I0
$2 = 10
(gdb) p N1
$3 = 1.1001
(gdb) p *S2
$4 = {bufstart = 0x815ad30, buflen = 15, flags = 336128, bufused = 3,
strstart = 0x815ad30 "abc"}
(gdb
Simon Glover wrote:
On Wed, 11 Dec 2002, Dan Sugalski wrote:
Are in. You can now get, set, delete, and get a hash of PMC
properties. (Hopefully)
Alas, no tests. Working on that, but if someone wants to beat me to
it, feel free.
I would expect this:
new P0, .PerlInt
new P1
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > On Wed, 11 Dec 2002, Dan Sugalski wrote:
> >
> >
> >>Are in. You can now get, set, delete, and get a hash of PMC
> >>properties. (Hopefully)
> >>
> >>Alas, no tests. Working on that, but if someone wants to beat me to
> >>it,
Steve Fink <[EMAIL PROTECTED]> writes:
> Heads up. The weather report indicates a feature freeze on Sat
> 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to
> a release on Wed 2002-Dec-18. So if you have any feature changes that
> you want to get into 0.0.9 (and it isn't too de
At 10:47 AM -0500 12/12/02, Simon Glover wrote:
This still doesn't answer my question, though: is the fact that the keys
are passed by reference a bug or a feature?
Feature. The crashing, though, is a bug. And (D'oh!) I know where,
too--the GC doesn't know about the prop hash member so it's n
At 4:51 PM +0100 12/12/02, Juergen Boemmels wrote:
Steve Fink <[EMAIL PROTECTED]> writes:
Heads up. The weather report indicates a feature freeze on Sat
2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to
a release on Wed 2002-Dec-18. So if you have any feature changes that
At 8:30 AM + 12/11/02, Jerome Quelin (via RT) wrote:
Thanks to bf's example, I'm now writing Befunge Makefile while
configuring Parrot. I hope that I did not miss sthg important. Please
note that $PARROT/languages/befunge/Makefile should go (the patch only
empties it AFAICT) - and I removed it
At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote:
Changes #6.
- PMC_*_FLAGs are history.
- I did remove the bogus looking, unused, untested and superfluous
from core.ops
It's not actually superfluous. If for some reason someone wants to
write part of the GC cleanup sweep in pasm, they'll need
Simon Glover wrote:
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
This still doesn't answer my question, though: is the fact that the keys
are passed by reference a bug or a feature?
hash.c works like this. If it's a bug or feature WRT properties - I
don't know.
Also, the above code (an
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > Also, the above code (and the original version) still segfaults if I run
> > it with --gc-debug.
>
>
> With my recent changes in dod.c/headers.c checked out from CVS?
Yep. I've just double-checked with a completely fresh
Dan Sugalski wrote:
At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote:
Changes #6.
- PMC_*_FLAGs are history.
- I did remove the bogus looking, unused, untested and superfluous
from core.ops
It's not actually superfluous. If for some reason someone wants to write
part of the GC cleanup swe
At 11:29 AM -0500 12/12/02, Simon Glover wrote:
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
> Also, the above code (and the original version) still segfaults if I run
> it with --gc-debug.
With my recent changes in dod.c/headers.c checked out from CVS?
Yep. I've j
Simon Glover wrote:
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
Simon Glover wrote:
Also, the above code (and the original version) still segfaults if I run
it with --gc-debug.
With my recent changes in dod.c/headers.c checked out from CVS?
Yep. I've just double-checked with a complete
On Thu, 12 Dec 2002, Dan Sugalski wrote:
> At 11:29 AM -0500 12/12/02, Simon Glover wrote:
> >On Thu, 12 Dec 2002, Leopold Toetsch wrote:
> >
> >> Simon Glover wrote:
> >>
> >> > Also, the above code (and the original version) still segfaults if I run
> >> > it with --gc-debug.
> >>
> >>
> >
On Thu, 12 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > On Thu, 12 Dec 2002, Leopold Toetsch wrote:
> >>Simon Glover wrote:
>
> >>> Also, the above code (and the original version) still segfaults if I run
> >>> it with --gc-debug.
>
> >>With my recent changes in dod.c/headers.c ch
Dan Sugalski wrote:
At 11:29 AM -0500 12/12/02, Simon Glover wrote:
Weird. It doesn't die for me, which is annoying. We'll work it into a
test and see where it does fail in the tinderbox.
The newly added test case #2 was -hmmm- somewhat wrong.
leo - no segfault
Dan Sugalski wrote:
What I'd like is for folks to take the next day or three to think of the
things that they need parrot to do that aren't working or designed yet,
and throw them at the list.
TODO:
- badly needed: line numbers in packfile (implying PBC extensions)
- run through KNOWN_ISSUE
On Tue, 10 Dec 2002 16:08:25 -0500, Joseph F. Ryan wrote:
> Peter Haworth wrote:
>
> >On Thu, 05 Dec 2002 15:17:57 -0500, Joseph F. Ryan wrote:
> >
> >>Again, C<< "STRING".split(' ') >> is different than
> >> C<< "STRING".split(/\s+/) >>. The latter will add an empty element to the
> >>beginning of
On Wed, 11 Dec 2002, Jared Rhine wrote:
> In languages/perl6/t/compiler/1_1.err, I get:
>
> Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc: undefined
> symbol: Parrot_DynOp_core_0_0_7
>
> which is suspicious for the 0_0_7 when I actually checked out 0_0_8.
You're right on the mark her
On 12/11/02 11:41 PM, Luke Palmer wrote:
>> More generally, I really don't want to have too many (any?) "system" object
>> method names squatting in "my" all-lowercase object method namespace. It's
>> not hard to think of many kinds of objects that would naturally have an "id"
>> attribute, but mu
Piers Cawley:
# Luke Palmer <[EMAIL PROTECTED]> writes:
# > Theoretically, there are sufficiently few Object methods to warrant
# > normal names.
#
# Right now there are 'sufficiently few' Object methods, but
# I'm betting that before the game is over there's going to a
# be a whole pile more,
> It seems to me that the simplest disambiguating rule is to require the
> parentheses on methods.
The way I see it, any sort of matching of what [multi-]?method is to be called,
is automatically doomed to failure. But I don't think that means we need to
require parentheses, except to override th
On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
> So basically we can leave off the parentheses in the usual
> cases, but they're still required when you're doing something unusual
> or that would otherwise be hard to read.
Which is simpler? "You don't need parentheses except in
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> We seem happy to structure objects (using
> attributes, etc.), but verbs remain flat and uninteresting: just
> arbitrary names.
>
> As a result of this lack of expressiveness in the grammar, we find
> ourselves saying that if a concept doesn't fit the
(This is a reply to a mail accidently sent to me personaly instead of
the list. Buddha, care to resend your other mail? I havn't quoted it
in total.)
On 12/12/2002 9:43 AM, Buddha Buck wrote:
James Mastros wrote:
Here's my basic defintion of ID: Two things should have the same ID
if-and-on
(resent as requested)
James Mastros wrote:
Here's my basic defintion of ID: Two things should have the same ID
if-and-only-if they will behave exactly the same, now and forevermore.
Thus, there should be one ID for all constants of the same value, which
is different from all constants of diff
On Thu, Dec 12, 2002 at 12:20:18PM -0500, James Mastros wrote:
: (This is a reply to a mail accidently sent to me personaly instead of
: the list. Buddha, care to resend your other mail? I havn't quoted it
: in total.)
:
: On 12/12/2002 9:43 AM, Buddha Buck wrote:
:
: >James Mastros wrote:
:
On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
Wel... yes and no. You can make the same argument for operators
upon scalars, for example, since 'scalar' is arguably no more
universal than 'array'. And we could easily use that a
On 12/12/02 12:55 PM, Larry Wall wrote:
> As for namespace pollution and classes that use .id in Perl 5, I
> don't think it's going to be a big problem. Built-in identifiers
> do not have a required prefix, but they have an optional prefix,
> which is C<*>. I think we can probably parse
>
> $a
On Wednesday, December 11, 2002, at 06:48 PM, Dave Storrs wrote:
Hopefully, this thread has been settled by Damian's pointing out the
existence of id(), but could I put in a strong vote against the use of
'===' for anything? It is far too easy to misread as ==, IMHO.
Yes, I think it's settled
John Siracusa wrote:
> On 12/12/02 12:55 PM, Larry Wall wrote:
> > As for namespace pollution and classes that use .id in Perl 5, I
> > don't think it's going to be a big problem. Built-in identifiers
> > do not have a required prefix, but they have an optional prefix,
> > which is C<*>. I think
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> TODO:
> - badly needed: line numbers in packfile (implying PBC extensions)
I have some toughts about PBC file extensions and some half working
code. Unfortunaltly my day time job consumes an enormous amount of
time at the moment. Lets see what i can t
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
TODO:
- badly needed: line numbers in packfile (implying PBC extensions)
I have some toughts about PBC file extensions and some half working
code. Unfortunaltly my day time job consumes an enormous amount of
time at the mom
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #19090]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19090 >
The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
to pointers
One possibility for R-to-L pipelines that would also solve the
namespace issues associated with reserving lots of keywords like "map"
and "grep" and "part" would be to have a quite literal inverse-C<.>
grammar. So instead of saying
$a.foo(args)
you could _always_ say an equivalent
fo
> Date: Thu, 12 Dec 2002 10:11:00 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> >> Wel... yes and no. You can make the same argument for operators
> >> upon scalars, fo
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: John Siracusa wrote:
: > On 12/12/02 12:55 PM, Larry Wall wrote:
: > > As for namespace pollution and classes that use .id in Perl 5, I
: > > don't think it's going to be a big problem. Built-in identifiers
: > > do not have a requi
On 12/12/02 4:01 PM, Larry Wall wrote:
> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
> : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;
>
> If you wish to be precise, yes. But $a.id eq $b.id should work for most any
> class that uses the the term "id" in t
Larry Wall:
# Hmm. Those don't really stand out enough. Maybe we should go with
# OBJECT:: and GLOBAL:: just for a little more visual punch.
How about CORE:: instead of GLOBAL::? This helps stick with tradition
and minimize the number of reserved packages.
# : And what will:
# :
# : main.*c
"John Siracusa" <[EMAIL PROTECTED]> wrote:
> memory addresses is so infrequent that warrants a much
> less common and/or longer method name than "id".
Another reason for not making these synonymous:
Is the address of an object constant? Or might it be
remapped during the life of an object. For ex
On 12/12/02 4:41 PM, Dave Whipp wrote:
> "John Siracusa" <[EMAIL PROTECTED]> wrote:
>> memory addresses is so infrequent that warrants a much
>> less common and/or longer method name than "id".
>
> Another reason for not making these synonymous:
>
> [...]
> If memory addresses can change over tim
Dave Whipp:
# Is the address of an object constant? Or might it be
# remapped during the life of an object. For example,
# arrays might move when they grow too big; distributed
# objects may move as they transfer onto different hosts;
# a persistent object might have a new address when
# retrieved
"Brent Dax" <[EMAIL PROTECTED]> wrote in message
00f901c2a22a$50417b30$6501a8c0@deepblue">news:00f901c2a22a$50417b30$6501a8c0@deepblue...
> Under all systems I can think of, the memory address of an object's
> header is constant. The data may move, but the header stays constant.
> This is to minim
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Dave Whipp:
> # Is the address of an object constant? Or might it be
> # remapped during the life of an object. For example,
> # arrays might move when they grow too big; distributed
> # objects may move as they transfer onto different hosts;
> # a persist
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no obje
Jonathan Scott Duff wrote:
> On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote:
>
> > So basically we can leave off the parentheses in the usual cases,
> > but they're still required when you're doing something unusual or
> > that would otherwise be hard to read.
>
> Which is simp
[EMAIL PROTECTED] (Larry Wall) writes:
> Which basically comes down to this: an id represents a location in
> memory for any objects that don't override the .id method.
Aiee! No! Please don't let things override the address-in-memory method,
as that makes foo.id == bar.id comparisons dubious at b
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> The only encompassing solution would seem to be to find a grammar rule
> by which map,grep,etc are unambiguously methods of Array, but can
> still be called in a fashion similar to [1]. That would, I suspect,
> satisfy everyone.
Right. And that's what
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a
Michael Lazzaro wrote:
> I would still like to be able to do things in Perl6 like:
>
> @out = sort map {...} grep { ... } @in;# [1]
>
> The only encompassing solution would seem to be to find a grammar rule
> by which map,grep,etc are unambiguously methods of Array, but can
> still be c
"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message
news:a05200f00ba1ebb73c6d2@[63.120.19.221]...
> There'll definitely be memory address reuse. If .id returns the
> current object's memory address, it shouldn't be cached any place, as
> otherwise you'll find things going bang with some regularity.
On Wed, Dec 11, 2002 at 06:53:20PM -0800, Randal L. Schwartz wrote:
> > "Rich" == Rich Morin <[EMAIL PROTECTED]> writes:
>
> Rich> On occasion, I have found it useful to cobble up a "little language"
> Rich> that allows me to generate a list of items, using a wild-card or some
> Rich> other sy
At 2:42 PM -0800 12/12/02, Dave Whipp wrote:
"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message
news:a05200f00ba1ebb73c6d2@[63.120.19.221]...
There'll definitely be memory address reuse. If .id returns the
current object's memory address, it shouldn't be cached any place, as
otherwise you'll
On Thu, Dec 12, 2002 at 10:40:20PM -, Smylers wrote:
> What if the thing being Ced (or whatever) is not an array but a
> list?
>
> @out = sort $scalar, @array, result_of_calling_function($param);
>
> Would the list have to be stored in an array before it could be sorted?
I would hope Perl
On Thursday, December 12, 2002, at 02:40 PM, Smylers wrote:
What if the thing being Ced (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
I hope and expect that t
On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote:
: Larry Wall:
: # Hmm. Those don't really stand out enough. Maybe we should go with
: # OBJECT:: and GLOBAL:: just for a little more visual punch.
:
: How about CORE:: instead of GLOBAL::? This helps stick with tradition
: and minimize
On Thu, Dec 12, 2002 at 04:17:44PM -0800, Michael G Schwern wrote:
: On Thu, Dec 12, 2002 at 10:40:20PM -, Smylers wrote:
: > What if the thing being Ced (or whatever) is not an array but a
: > list?
: >
: > @out = sort $scalar, @array, result_of_calling_function($param);
: >
: > Would the
On Wed, Dec 11, 2002 at 06:50:12PM -0800, Michael Lazzaro wrote:
:
: On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote:
: > print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?)
: > reverse @a; # ILLEGAL; use @a.reverse;
: > map {...} @a; # ILLEGAL; use @a
On Wed, Dec 11, 2002 at 11:36:17PM +, Simon Cozens wrote:
: [EMAIL PROTECTED] (Michael G Schwern) writes:
: > If you want a tactile grasp of the "Everything is an object" concept, try
: > some Ruby.
:
: If you want a tactile grasp of Perl 6, try some Ruby. But I'll be saying
: a lot more on th
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's "Main", not "main". And it's a module, not a class,
so probably it fails, unless someone can think of something useful
On 12/12/2002 8:07 PM, Larry Wall wrote:
Ordinarily you'd test for subs with one of
exists &Main::foo
&Main::foo.exists
I thought that was now spelt exists %Main::{&foo} -- that the symbol
tables were now just plain hashes? (And what's the methody syntax for
testing for hashkey exista
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I t
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I rea
86 matches
Mail list logo
