"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote:
> >
> > Agreed, it's not pretty. The fundamental problem is that a primitive
> > like an C simply cannot be undefined... there'
On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
>
> On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > That would make the rule very simple indeed:
> >
> > Assigning C to an array element causes that element to take
> > the
> > array's default value.
> >
> > The
On Wed, Jan 29, 2003 at 02:37:04PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> > On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> >
> > > Can someone give me a realish world example of when you would want an
> > > array that can sto
> Date: Mon, 27 Jan 2003 13:24:23 -0800
> From: Damian Conway <[EMAIL PROTECTED]>
>
> Dave Whipp suggested:
>
> > The size constraints are probably C properties, as is C. The
> > exception behavior probably deserves to remain an C property.
>
> Nope. They're all C properties. C properties only a
At 2:18 PM -0800 1/29/03, Austin Hastings wrote:
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
>Now: Does this require a "fake undef" and a "real undef"?
>
>WHO CARES?
Very good answer. Leave the details to me and the p6i folks. (Though
do pl
Stéphane Payrard wrote:
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
Yes, I would expect that. In my opinion there is no difference between
an array and a hash other than the underlying storage and the
type-management of the key. I'm increasingly of the opinion that a)
there
On Wed, Jan 29, 2003 at 09:44:27AM -0500, Aaron Sherman wrote:
>
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key. I'm increasingly of the opinion that a)
> there should be no @ vs
On Wed, Jan 29, 2003 at 02:13:34PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote:
> > In my opinion, default values for arrays should only come into play
> > for array elements that have NEVER been assigned to or that have
> > been explicity undef'e
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
> >Now: Does this require a "fake undef" and a "real undef"?
> >
> >WHO CARES?
>
> Very good answer. Leave the details to me and the p6i folks. (Though
> do please, everyone, pay attention when we tel
At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
Elements of a has ARE ordered, just not the way you may expect.
Just to nip this one in the bud...
If people start assuming that there's *any* ordering to hashes, I
promise I *will* make sure that parrot's external hash class starts
returning ke
Sorry I've not been much in evidence the past week or so (I know, I'm
behind in the object draft). Job hunting and writing commitments have
been getting in the way. I should have the backlog cleared out soon,
and get at least a second object draft out, and then we can address
the bytecode issue
On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
That would make the rule very simple indeed:
Assigning C to an array element causes that element to take
the
array's default value.
The effects of this are:
* Assigning a particular integer to an array of int or Int always
do
On Wed, Jan 29, 2003 at 12:40:21PM -0500, Aaron Sherman wrote:
> Elements of a has ARE ordered, just not the way you may expect.
Quite:
$ perl5.8.0 -le '%a = (small => 1, large =>2); %b = %a; print foreach keys %a; print
"--"; print foreach keys %b'
large
small
--
small
large
$ perl5.8.0 -le '
On Wed, Jan 29, 2003 at 02:12:01PM +0100, Leopold Toetsch wrote:
> The variable layout of interpreter->code (actually the packfile) doesn't
> fit very good for multiple code segments. There is only one ->byte_code
> pointer, the byte_code_size is in bytes and converted zig times into
> opcode_t'
On Wed, Jan 29, 2003 at 03:48:18PM -0500, Dan Sugalski wrote:
> (Though do please, everyone, pay attention when we tell you that what
> you want is slow or awkward)
Just be sure to reiterate in case we miss it the first time :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
Now: Does this require a "fake undef" and a "real undef"?
WHO CARES?
Very good answer. Leave the details to me and the p6i folks. (Though
do please, everyone, pay attention when we tell you that what you
want is slow or awkward)
--
On Wed, 2003-01-29 at 14:53, Austin Hastings wrote:
> Leaving out the whole "is default()" bit, what happens when I:
>
> my int @a;
> @a[4] = 100;
> @a[2];
>
> What does @a[2] return? It must return something, and that something
> can't be undef, because ... So, what is it? Whatever it
> i
> Agreed, it's not pretty. The fundamental problem is that a primitive
> like an C simply cannot be undefined... there's no flag for that
> (which is they're primitive.)
Certainly there's no way of _storing_ C.
> So it having a 'default value' at all is perhaps a bit of a misnomer.
Why does tha
On Wed, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
>
> > Can someone give me a realish world example of when you would want an
> > array that can store both undefined values and default values and those
> > values are different?
On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> Can someone give me a realish world example of when you would want an
> array that can store both undefined values and default values and those
> values are different?
my @send_partner_email is default(1);
while $websignups.getline {
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> > Solution 3: The autoset sets the value to the default value.
> >
> > my Int @a is default(5);
> >
> > @a[3] = 3; # there are now 4 items in the array
> >
Michael G Schwern wrote:
> On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
>
> > Has anyone considered removing with the syntactic distinction
> > between numeric and string indexing -- that is, between array and
> > hash lookup?
>
> PHP works this way.
Well, for some definit
On Wed, Jan 29, 2003 at 09:07:37PM +0100, Juergen Boemmels wrote:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> > Can someone give me a realish world example of when you would want an
> > array that can store both undefined values and default values and those
> > values are different?
>
> Ok
On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote:
> In my opinion, default values for arrays should only come into play
> for array elements that have NEVER been assigned to or that have
> been explicity undef'ed. If an assigment is made to an array element
> then the array element shou
In my opinion, default values for arrays should only come into play
for array elements that have NEVER been assigned to or that have
been explicity undef'ed. If an assigment is made to an array element
then the array element should end up the assigned value (modulo
necessary type conversions) and
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> > Solution 3: The autoset sets the value to the default value.
> >
> > my Int @a is default(5);
> >
> > @a[3] = 3; # there are now 4 items in the array
> > @a
On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote:
>
> 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,
> >> .
On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> Solution 3: The autoset sets the value to the default value.
>
> my Int @a is default(5);
>
> @a[3] = 3; # there are now 4 items in the array
> @a[2]; # was autoset 5 so returns 5
> @a[4];
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> 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,
> >> .
> >
> > Loo
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty
> value', 5
>
> @a[5] = undef;
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty
> value', 5
>
> @a[5] = undef;
On Wed, 2003-01-29 at 05:29, Leopold Toetsch wrote:
> John Williams wrote:
>
> > I think you are still overlooking the autovivification behavior.
> > i.e. What is the difference between these:
> >
> >1) $a{1234567} = 1;
> >
> >2) $a[1234567] = 1;
> >
> > Answer: #1 creates 1 element
Ok, stepping back...
there are three questions:
* Can a type be undefined
* What does an array say when asked for an element that doesn't exist
* What happens when you try to undefine something
I really think you need an attribute to clarify these.
For example, you would not say:
my in
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,
.
Looks like a maintenance nightmare to me.
Agreed, it's not pretty. The fundame
On Wed, Jan 29, 2003 at 10:23:26AM -0800, Michael Lazzaro wrote:
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.) When
> you overlay a real hash on top of your default values, the default
> values "show through
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.)
> When
> you overlay a real hash on top of your default values, the default
> values "show through the holes".
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
>
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to
> 5
>
On Jan-29, Steve Fink wrote:
> More weirdness. It gave me error messages, but claims to have
> committed. Look near the end for a timestamp (which is probably ~30
> seconds after the commit).
It looks like everything really did make it in, but the cvs commit
message did not include the parts that
On Jan-28, Leopold Toetsch wrote:
> Robert Spier wrote:
>
> >Odd.
> >
> >There's not enough information in the logs to figure out what's going
> >on. (And the code shouldn't have this kind of failure mode.)
> >
> >If it keeps happening, please keep me in the loop.
>
>
> Did it again. This tim
On Jan-29, Jonathan Sillito wrote:
> 1) coroutine.t (which should be put in t/pmc/) exposes some errors in our
> coroutine code.
>
> 2) coroutine.patch fixes those errors by saving and restoring more of the
> coroutine's context. More specifically the user_stack, control_stack and
> pad_stack.
>
OK, I think we agree that 'default' refers to what to put in the
'holes' of an array (or hash, but that's a separate discussion.) When
you overlay a real hash on top of your default values, the default
values "show through the holes". So now we just have to define what
"holes" are.
An asser
On Wed, Jan 29, 2003 at 03:52:22PM +, Nicholas Clark wrote:
> On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
> > Obviously, values are pure and therefrom spring "virtues," while
> > objects are but vile clay -- fallible constructs of a sinful man,
> > pathetically trying to re
Ok, I'll respond to a couple of points, below, but I think a lot of
folks are confusing some operational concepts here, and it's getting
hard to un-peel them.
A container has many attributes, even if Perl won't let us control them.
Those include:
1. Storage
2. Conversion of the wh
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
> > Obviously, values are pure and therefrom spring "virtues," while
> > objects are but vile clay -- fallible constructs of a sinful man,
> > pathetically trying to recreate an envisio
Leopold Toetsch wrote:
>
> Anyway:
> - are there platforms with quad precision floats out there?
Several documents refer to quad precision hardware, but I can't find direct
references to any.
> - or should 12 byte long doubles get converted to 8 byte IEEE doubles.
Perhaps the following quote f
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
> On Tue, 2003-01-28 at 17:12, Garrett Goebel wrote:
> >
> > There are 3 standard binary IEEE 754 derived formats:
> >
> > Single Precision: 4 bytes
> > Double Precision: 8 bytes
> > Quadruple Precision: 16 bytes
>
> Actually, Quads
On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
> Obviously, values are pure and therefrom spring "virtues," while
> objects are but vile clay -- fallible constructs of a sinful man,
> pathetically trying to recreate an envisioned ideal. Ergo, they have
> naught but "vices."
>
> C
On Wed, Jan 29, 2003 at 03:41:33PM +, Nicholas Clark wrote:
> On Wed, Jan 29, 2003 at 07:36:07AM -0800, Robert Spier wrote:
> > > Also I can't work out how to search the list archive at develooper.com.
> >
> > Patches welcome.
> >
> > (Really. I have several archive management tasks that nee
At 1:15 PM +0100 1/28/03, K Stol wrote:
Hi there,
didn't have time to reply earlier, had to do some research on Lua and had to
get approval for the project, so couldn't let you know earlier. sorry about
that.
But now, I have it (the approval, that is) so I'll be implementing a
compiler for Lua->p
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 28, 2003 at 09:17:36AM -0800, Damian Conway wrote:
> > Errno. That's rather the whole point of C properties [*].
>
> > [*] People, we just *have* to find better names for these things!
> > I'd suggest we henceforth call them "val
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Can I flame you for being too preemptive? :-)
In all honesty, I just wanted to be able to use "absquatulate" in a
real post. ;-)
=Austin
On Wed, Jan 29, 2003 at 07:36:07AM -0800, Robert Spier wrote:
> > Also I can't work out how to search the list archive at develooper.com.
>
> Patches welcome.
>
> (Really. I have several archive management tasks that need to get
> done, and if anyone wants to volunteer)
I'm quite happy to s
--- Sam Vilain <[EMAIL PROTECTED]> wrote:
> =head2 includes( [ I, ] [ I ])
Where the and/or are obviously junctions.
if ($container.includes(any("ant", "beaver", "cow", "duck"))(
...
This is *SO* cool.
=Austin
On 2003-01-29 at 10:32:58, Mark J. Reed wrote:
> (What their value should be is the subject of the
> parallel thread on array defaults).
Whups, that would be THIS thread, actually. The sidebar on
removing the syntactic distinction between arrays and hashes
made me think I was over in the "Spare
> Also I can't work out how to search the list archive at develooper.com.
Patches welcome.
(Really. I have several archive management tasks that need to get
done, and if anyone wants to volunteer)
-R
On 2003-01-29 at 09:44:27, Aaron Sherman wrote:
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key.
Perhaps it is your opinion that those should be the only differences,
but the actua
On Tue, 2003-01-28 at 19:24, Paul Johnson wrote:
> > If that's not the case, I need to get my head around why, since Perl
> > *does* distinguish between defined and exists.
>
> But I wish it wouldn't for arrays. That only came about to support
> pseudo-hashes which are going / have gone away.
>
On Wed, 2003-01-29 at 04:56, Nicholas Clark wrote:
> On Wed, Jan 29, 2003 at 06:53:25AM +0100, Leopold Toetsch wrote:
> > Garrett Goebel wrote:
>
> > Many thanks for the links (searching for this stuff is a pain, there are
> > too many results ;-)
> >
> > Anyway:
> > - are there platforms with q
On Tue, 2003-01-28 at 17:12, Garrett Goebel wrote:
> Leopold Toetsch wrote:
> >
> > - 8/12 byte float issues are still the same - are these
> >formats really portable, or should we try to store
> >ASCII equivalents?
>
> No?
>
> ? Because my knowledge here approaches zero, so I'm just ap
The variable layout of interpreter->code (actually the packfile) doesn't
fit very good for multiple code segments. There is only one ->byte_code
pointer, the byte_code_size is in bytes and converted zig times into
opcode_t's and so on.
so:
1) rename interpreter->code to interpreter->pf (the pa
On Wed, Jan 29, 2003 at 09:20:33AM +, Thomas Whateley wrote:
> one more quick question.. would it be possible to play linker games
> to redirect syscalls (from compiled c) to wrapper functions that check
> permissions? Would that allow us to secure dynamicly linked libs??
When I said "as soo
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
Not currently: 2) does
- generate a sparse hole be
On Wed, 29 Jan 2003 18:04, Michael G Schwern wrote:
> On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
> > This may sound like a silly idea but ...
> >
> > Has anyone considered removing with the syntactic distinction between
> > numeric and string indexing -- that is, between arr
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20597]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20597 >
Here is a corrected version, which handles obscure t
>> In particular, it would seem that
>> %foo[$key]
>> would be just as easy for the compiler to grok as
>> %foo{$key}
On Mon, 27 Jan 2003 15:39:19 -0800, Damian Conway <[EMAIL PROTECTED]> wrote:
> Sure. But then is this:
>
> $ref[$key]
>
> an array or hash look-up???
Yes, well I suppose t
On Wed, Jan 29, 2003 at 08:22:05AM +, Leopold Toetsch wrote:
> # New Ticket Created by Leopold Toetsch
> # Please include the string: [perl #20597]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=20597 >
>
>
> Next t
On Wed, Jan 29, 2003 at 06:53:25AM +0100, Leopold Toetsch wrote:
> Garrett Goebel wrote:
> Many thanks for the links (searching for this stuff is a pain, there are
> too many results ;-)
>
> Anyway:
> - are there platforms with quad precision floats out there?
sparc Solaris and Irix both have 1
* Dan Sugalski <[EMAIL PROTECTED]> [030128 19:30]:
> Ah, I've been hoping to avoid this for a while for sheer, screaming
> lack of tuits, but... Here's the deal for 'safe mode'. (For
> background, as everyone in the Unix world seems to be happy
> reinventing security wheels,
Hey! I wasn't try
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
> This may sound like a silly idea but ...
>
> Has anyone considered removing with the syntactic distinction between
> numeric and string indexing -- that is, between array and hash lookup?
PHP works this way.
http://www.php.net/m
On 28 Jan 2003, Aaron Sherman wrote:
> I'm not sure I recall the sufficient, yet irrelevant technical reasons.
> I certainly can't think of anything. It also helps in the case of
> objects that are non truly arrayish or hashish:
>
> my SuperTree $foo;
> $foo["Munge"]; # Returns the nod
: -Original Message-
: From: Jonathan Sillito [mailto:[EMAIL PROTECTED]]
[snip]
: 1) I was thinking of writing a couple of short "how to" documents aimed at
: compiler writers. Is there interest in something like this?
yes please
--cal henderson
---
** For great Emap magazine subscrip
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #20597]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20597 >
Next try. This patch obsoletes #20584.
- more wordsize fixes
- routine for convertin
72 matches
Mail list logo
