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
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 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 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 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 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 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 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 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 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
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 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
"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.
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
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
[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
[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
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
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
--- 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
"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
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
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
"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
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
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
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
> 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
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
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
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
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: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 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:
:
(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
(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
--- 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
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
> 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
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,
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
> 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,
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
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 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
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
[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
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
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
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
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
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
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
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
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 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
> >
> 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
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
58 matches
Mail list logo
