Re: state vs my
On Fri, 3 Dec 2004 21:25:39 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
I've emulated state vars like this:
instead of
for (...) {
my $a = ...;
...
}
i've written:
{ my $a;
for (...) {
$a = ...;
...
}
}
I think, effect is the same, (of course only if state vars declared at the
top of the block)
(second variant IS faster in perl5. slightly:)
perl timeit { my $a; for (1..10_000_000) { $a=10 } }
3.149s
perl timeit { for (1..10_000_000) { my $a=10 } }
4.709s
)
P.S.
btw, what about
my @rray;
# i'm starting to like that sigil is a part of name idea :)
for 1..10 {
{
push @rray, \( state $calar )
}
}
say @rray[0] == @rray[1]
what is the scope of state vars exactly? Common sense tells me that it
should be exactly the same as i've shown in second snippet above.. and
latter snippet would say undef.. so Cstate is just a syntactic sugar for
Cmy, which also allow us to remove redundant outer block. is it?
P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed
now? we have an ambiguity otherwise:
sub test {
...
{ #some bare block
...
}
}
looks like test() could return that block as closure in scalar context,
but would execute it immediately in void. wow:)
I should reread apocalypses, definitely..
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
hmm.. looks like heavy magic is involved here. Because perl5 makes a
feeling that every _block_ has it's own lexical pad. so, does it mean that
my $vars deallocated only on exit from surrounding subroutine, not from
nearest surrounding block? my experience show opposite, but I could be
wrong..
(or I just misunderstood conception of lexical pads)
Re: state vs my
On Sat, Dec 04, 2004 at 08:03:45PM +0300, Alexey Trofimenko wrote:
: P.S.
: btw, what about
:
: my @rray;
: # i'm starting to like that sigil is a part of name idea :)
Too cute. But what about %ash and unction? Or is it ubroutine? losure?
: for 1..10 {
: {
:push @rray, \( state $calar )
: }
: }
:
: say @rray[0] == @rray[1]
:
: what is the scope of state vars exactly? Common sense tells me that it
: should be exactly the same as i've shown in second snippet above.. and
: latter snippet would say undef.. so Cstate is just a syntactic sugar for
: Cmy, which also allow us to remove redundant outer block. is it?
No, it's not syntactic sugar for a Cmy. It's semantic sugar for
an Cour. The semantic sugar is that, while Cour is a lexically
scoped alias to a global, permanent package variable, Cstate is a
lexically scoped alias to a unique, permanent, anonymous variable.
You could implement Cstate using Cour with an autogenerated and
hidden package variable name, for instance.
If Cstate were based on Cmy, it would lose its value when you exited
the current routine. The whole point of a Cstate variable is that it
never loses its state regardless of the control flow.
In general, any Cstate declaration refers to a single, permanent storage
location. I say in general, because if you clone a closure, you get a
separate state location for each clone, in which case a single Cstate
declaration represents multiple states. In that sense it's a little
more like Cmy than Cour.
: P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed
: now? we have an ambiguity otherwise:
: sub test {
: ...
: { #some bare block
: ...
: }
: }
:
: looks like test() could return that block as closure in scalar context,
: but would execute it immediately in void. wow:)
: I should reread apocalypses, definitely..
You have to say Creturn {...} or some such if you want to return
a closure.
: Perl 5 already stores all the lexicals in the pad for the entire
: subroutine. There is no separate pad for the inside of the loop.
: Any differences in performance would be related to the actual
: reinitialization of the lexical, not allocation.
:
: hmm.. looks like heavy magic is involved here. Because perl5 makes a
: feeling that every _block_ has it's own lexical pad. so, does it mean that
: my $vars deallocated only on exit from surrounding subroutine, not from
: nearest surrounding block? my experience show opposite, but I could be
: wrong..
: (or I just misunderstood conception of lexical pads)
It looks like every block has its own lexical pad because entries
in the sub's pad are tagged with the range of statements over which
the declaration is valid. But Cmy $vars is *not*, repeat *not*,
deallocated on exit from the subroutine. Only the variable's
*contents* are deallocated (and that only if there's no external
reference generated to the data). If you call a function recursively,
it generates a new pad for each recursion level. On exit, that stack
of pads is *not* deallocated, on the assumption that if you called a
function recursively once, you're likely to do it again, and why do
all that work again?
It's kinda funny to watch the Parrot folks reinventing a similar scheme.
(Er, no pun intended. Really!)
Larry
Re: state vs my
On Sat, 4 Dec 2004 11:33:10 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 08:03:45PM +0300, Alexey Trofimenko wrote:
: P.S.
: btw, what about
:
: my @rray;
: # i'm starting to like that sigil is a part of name idea :)
: for 1..10 {
: {
:push @rray, \( state $calar )
: }
: }
:
: say @rray[0] == @rray[1]
still your answer doesn't make it clearer. would this print 1 or undef?
I assumed it would say undef, but you said that state vars are reallocated
only on function cloning, whatever it is.. so state vars are owned by
functions, not bare blocks. If so, then it DOES print 1, doesn't it?
ah, that was a bad example, I can see now..
I thought, its primary use is for closures:
sub test {
my $a=10;
return sub { $a++ }
}
vs
sub test {
return sub {state $a=10; $a++ }
}
$func1 = test;
$func2 = test;
would closures in $func1 and $func2 share the SAME $a?
or is it that function cloning you said?
oh! that it. I've found example which could make it clear to me
sub test {
return sub {
for 1..3 {
state $var = 1;
print $var++
}
}
}
$a = test; $a() for 1..3; print ';'
$b = test; $b() for 1..3;
that could print, for different possible definitions of state:
1) 123123123;123123123
2) 123456789;123456789
3) 123456789;101112131415161718
looks like you meant third(!) variant.. but it doesn't make any sense for
me.
Re: state vs my
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: I thought, its primary use is for closures:
:
: sub test {
: my $a=10;
: return sub { $a++ }
: }
:
: vs
: sub test {
: return sub {state $a=10; $a++ }
: }
:
: $func1 = test;
: $func2 = test;
:
: would closures in $func1 and $func2 share the SAME $a?
No, they're separate.
: or is it that function cloning you said?
Yes, except it'd be better to call it closure cloning.
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of state:
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense for
: me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time through.
Certainly that one doesn't, since it doesn't refer to any external lexicals.
Perhaps statehood should be limited to official subs just like return is.
Larry
Re: state vs my
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
No reassignment either, since assignment to a state declaration only
happens at first time. If you expect $a, $b, and $c to get new values
each time through the loop, you'll be disappointed.
: I've read an advice somewhat like that in Ruby docs, tried it on perl5,
: and it really makes a difference, especially on very short loops.
: could it be done some tricky optimisation, so if some variable in loop
: isn't going to have references on it, stored somewhere outside the block,
: than Cmy before it will be changed to Cstate?
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
So optimizing to a state variable won't necessarily help your loop
overhead, but it could help your subroutine overhead, at least in Perl
5, if Perl 5 had state variables. Best you can do in Perl 5 is an
our variable with an obscure name.
Larry
Re: state vs my
Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: Wrappers vs. efficiency - quick comment
On 3/12/03 1:50 AM, Mark Biggar wrote: John Siracusa wrote: From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) I don't see how a sub being inline-able prevents being wrap-able. I did say may... :) (anyway, my original point still stands) -John
Re: Wrappers vs. efficiency - quick comment
--- John Siracusa [EMAIL PROTECTED] wrote: From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. Hmm. In this area, I'm surprised that Larry didn't know better. My confidence in the implementation team's ability to produce fast functions, regardless of wrappage, is pretty high. I agree with you, John -- make this fast and make this inline aren't the same thing by a long shot. =Austin
Re: Wrappers vs. efficiency - quick comment
On Wed, Mar 12, 2003 at 10:04:47AM -0500, John Siracusa wrote: : On 3/12/03 1:50 AM, Mark Biggar wrote: : John Siracusa wrote: : From A6: : I worry that generalized wrappers will make it impossible to compile fast : subroutine calls, if we always have to allow for run-time insertion of : handlers. Of course, that's no slower than Perl 5, but we'd like to do : better than Perl 5. Perhaps we can have the default be to have wrappable : subs, and then turn that off with specific declarations for speed, such as : is inline. : : I think there's a lot of room between allow this subroutine to be wrapped : and inline this subroutine. Whatever the specific declaration for speed : is that forbids runtime wrapping of a subroutine, it should not be spelled : inline. : : (although inline may imply dontwrapmeplease or whatever :) : : I don't see how a sub being inline-able prevents being wrap-able. : : I did say may... :) Just like I did say such as. :-/ Larry
Re: Wrappers vs. efficiency - quick comment
John Siracusa wrote: From A6: I worry that generalized wrappers will make it impossible to compile fast subroutine calls, if we always have to allow for run-time insertion of handlers. Of course, that's no slower than Perl 5, but we'd like to do better than Perl 5. Perhaps we can have the default be to have wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) I don't see how a sub being inline-able prevents being wrap-able. In most langausges an inline declaration is only a suggestion and often there is a real version of the sub in addition to any inlined copies. Besides a wrapped inline sub is in no different situation as a inlined sub being called in another inlined sub, this seem to be all part of what the compiler has to be able to do to deal with a recursive sub that is also declared inline. -- Mark Biggar [EMAIL PROTECTED]
Re: SM vs. BD (apoc6)
--- Uri Guttman [EMAIL PROTECTED] wrote: But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the SM folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch. shouldn't that be BD and not SM? I believe that depends on whether you consider strongly typed compile-time semantics as being restrictive or painful. I also suspect that showing too much acumen about the classification may come back to haunt you at a Perl Conference ... ;- =Austin
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote: -- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: As near as I can tell, the only problem with the nice flow of: A Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray is a variable that holds a list. is the Rvalue-assign list, which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. -Erik Ah, I'm a compete fool. I meant Lvalue, not Rvalue. If you could do a mental s:e/Rvalue/Lvalue on that last message, I would appreciate it. Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray is a variable that holds a list.
is the Rvalue-assign list, which takes the form of:
($r1, $r2, $r3) = (1, 2, 3);
I don't see a problem here. The list on the right is still just
value, unmodifiable. It is a list of rvalues. When you use a variable
on the right hand side it is a rvalue. Similarly, a list of variables
doesn't flatten to it's values - it is the list itself that it is
immutable. It's individual members still retain asignibility in
rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
You're completely right. See my last message :-)
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs lists; A possible solution?
--
On Thu, 13 Feb 2003 16:03:41
Joseph F. Ryan wrote:
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray is a variable that holds a list.
is the Rvalue-assign list, which takes the form of:
($r1, $r2, $r3) = (1, 2, 3);
I don't see a problem here. The list on the right is still just
value, unmodifiable. It is a list of rvalues. When you use a variable
on the right hand side it is a rvalue. Similarly, a list of variables
doesn't flatten to it's values - it is the list itself that it is
immutable. It's individual members still retain asignibility in
rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
You're completely right. See my last message :-)
I *am*? Mark it on your calender!
-Erik
Joseph F. Ryan
[EMAIL PROTECTED]
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs. Lists
On 2003-02-11 at 16:52:36, Dave Whipp wrote:
Mark J. Reed [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element,
leaving two elements in the array - which is irrelevant since
the array is then discarded completely.
Minor correction: we don't know how many elements are left in the
array - it depends on how many elements were in @a, @b, and @c to
start with. One less than that. :)
These days you need the splat operator to flatten lists: so the above starts
out as a list of 3 array-refs, and the pop returns 1 array-ref, leaving 2 in
the anon-array -- which then becomes garbage, to be collected sometime.
That may be true in Perl6, but my example was in Perl5 - to demonstrate
that the equivalent of [@a,@b,@c].pop currently works, despite the
previous poster's statement that it doesn't make sense.
But I didn't think it was true in Perl6 either - [@a,@b,@c] supplies
list context, so each of the arrays should be automatically flattened.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
Mark J. Reed wrote:
On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
I don't see any reason to change this behavior for Perl6.
Apologies; when I meant same as above, I meant same answer that I gave
for:
[1..10].map {...
I think this *should* work, although I'm not sure *how*.
Meaning that I think this should be possible, but I'm not
sure if that syntax is correct, because it would mean that
the arrayrefs would need to be their own class to allow
a method to be called on it, and this class would need to be
a wrapper around the real array class.
Re-reading my original message, I can see the reason for
the confusion. In fact, I don't even know what I was thinking
when I thought people would make that connection that I wanted,
as it doesn't even make sense to me now :-)
Hmm... now that I think more about it, making array references
their own class and wrapping it around the real array
class would make it pretty easy to cause all of the auto
dereferencing when necessary behaivor that is causing
so many problems, since auto-dereferencing wouldn't have to
happen, it would only seem that way.
Does this sound feasible?
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
On 2003-02-12 at 11:07:45, Joseph F. Ryan wrote: Meaning that I think this should be possible, but I'm not sure if that syntax is correct, because it would mean that the arrayrefs would need to be their own class to allow a method to be called on it. No, they wouldn't, unless I'm missing something. All methods are called via references, right? So [@a,@b,@c].pop automatically invokes Array#pop with the invocant as the anonymous array. In fact, the only reason @foo.pop works is because @foo automatically referencizes in scalar context. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
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 all this . . .
snip
I think some of this is in A2, but not all of it.
Here are some of the answers from my own notes. These behaviors have
all been confirmed on-list by the design team:
An @array in list context returns a list of its elements
An @array in scalar context returns a reference to itself (NOTE1)
An @array in numeric (scalar) context returns the number of elements
An @array in string (scalar) context returns a join of its elements
An $arrayref in list context returns an arrayref (NOTE2)
An $arrayref in scalar context returns an arrayref
An $arrayref in numeric (scalar) context returns ??? (NOTE3)
An $arrayref in string (scalar) context returns ???
Note that that's pretty consistent with how it works now.
(NOTE1): This is the big change. It's what allows us to treat arrays
as objects, and call methods on them like @array.length. I don't think
anyone will argue that's not a good thing.
(NOTE2): Note that this is a non-change. If we changed it so that an
arrayref flattened itself in array context, you could never have
complex data structures, because [[1,2],[3,4]] would always be the same
as [1,2,3,4].
(NOTE3): I have not been able to find explicitly confirmed behaviors
for these two. It has been implied that they return $arrayref.length
and $arrayref.string (or whatever those methods are called). Maybe.
--- List Flattening ---
The confusing behavior is, of course, that the list
(@a,@b,@c)
is seen as being treated differently in different syntactic contexts.
In the case of:
sub foo(@p1,@p2,@p3);
foo(@a,@b,@c);
the arrays @a, @b, and @c are NOT flattened, but are passed as @p1,
@p2, and @p3. Likewise, in:
my(@d,@e,@f) := (@a,@b,@c);
the same is true. But in ALL other circumstances, like
my(@d,@e,@f) = (@a,@b,@c);
an array in list context simply returns it's elements, such that @d =
(@a,@b,@c), @e=(), @f=(). So what's the deal?
My own two-sentence explanation for why this is is that in the first
two examples, Csub and C:=, you're binding one variable to another,
NOT dealing with the array-ness of those variables at all. E.G.
@a := @b
makes @a refer to the same array object as @b refers to, whereas
@a = @b
simply says to copy all elements _contained within_ @b into @a. So
it's not that arrays are behaving differently in different situations,
because they're NOT... the same rules always apply. It's just that
Csub and C:= are specific, binding-style operations... they do the
same thing for scalar variables, too.
There, how convincing did that sound?
MikeL
Re: Arrays vs. Lists
--
On Tue, 11 Feb 2003 12:28:23
Luke Palmer wrote:
Date: Tue, 11 Feb 2003 10:34:57 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
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 writing about scalars. A
variable is more like a name of a container for a value, e.g. there's
three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
Maybe I'm confused about why there is
confusion. An array is an object (in fact
all containers are objects, or
implementations thereoff). We can call
methods on it, and dispatch functions
differently based on it's type - which is
why we can treat lists and arrays
differently.
A list is not a object - it is a value,
immutable. It is the data that the array
object wraps around.
The name @array names arrays which Perl can
autovivify. The '@' is part of it's name. If
Perl sees a name begining with @ is hasn't
seen before is creates the array object
automatically. So
@array = (1,2,3,4);
really means
@array := Array.new (1,2,3,4)
or possibly (treating = as an overloaded
operator on the type Array)
(@array := Array.new) = (1,2,3,4)
the commas being operators which construct
the list value.
Or am I confused?
-Erik
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
Well, that doesn't assume the definition of the variable includes a
namespace entry. So, yes, I suppose container would be better. The
thing the namespace entry points to, but not the value.
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one
I'd agree.
-- it's just an anonymous container. So I'd rewrite the definition
to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
I think that's a pretty good one.
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Yes, from my perspective, the container is the one that knows
read/write. Basically, the only you can't modify lists is that they
have no operations defined that can modify them. Arrays on the other
hand, do.
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
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 {...}
I don't really know here. I'm not sure whether this should work
I think if lists don't have the Cmap method, that shouldn't work.
(@a,@b,@c).pop
[@a,@b,@c].pop
Why would you suppose the former to work? Or do you mean that to mean
(@a.pop,@b.pop,@c.pop)? Can lists have methods?
This clear distinction that I once had in my mind is getting blurrier
and blurrier. :(
Luke
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
-- On Wed, 12 Feb 2003 18:29:29 Joseph F. Ryan wrote: As near as I can tell, the only problem with the nice flow of: A Iliteral is a piece of data. A Iscalar is a variable that holds a literal. A Ilist is a sequence of literals and scalars. An Iarray is a variable that holds a list. is the Rvalue-assign list, which takes the form of: ($r1, $r2, $r3) = (1, 2, 3); I don't see a problem here. The list on the right is still just value, unmodifiable. It is a list of rvalues. When you use a variable on the right hand side it is a rvalue. Similarly, a list of variables doesn't flatten to it's values - it is the list itself that it is immutable. It's individual members still retain asignibility in rvalue context. -Erik Well, what if an Rvalue-assign list is simply decoupled from a normal data list. The confusion would end. The concepts themselves are separate, so why shouldn't the names be? data lists become The One True List Type, and Rvalue-assign lists become something like Rvalue sequences (or a catchier name). Peace would reign on earth, or at least p6-lang and p6-doc. (I hope I'm not missing something obvious here, at any rate :) Joseph F. Ryan ryan.311@osu Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays vs lists; A possible solution?
--
On Wed, 12 Feb 2003 17:14:17
Erik Steven Harrison wrote:
--
On Wed, 12 Feb 2003 18:29:29
Joseph F. Ryan wrote:
As near as I can tell, the only problem with the nice flow of:
A Iliteral is a piece of data.
A Iscalar is a variable that holds a literal.
A Ilist is a sequence of literals and scalars.
An Iarray is a variable that holds a list.
is the Rvalue-assign list, which takes the form of:
($r1, $r2, $r3) = (1, 2, 3);
I don't see a problem here. The list on the right is still just
value, unmodifiable. It is a list of rvalues. When you use a variable
on the right hand side it is a rvalue. Similarly, a list of variables
doesn't flatten to it's values - it is the list itself that it is
immutable. It's individual members still retain asignibility in
rvalue context.
Okay, pardon me for replying to myself, but that was _really_ badly
worded. An example
foreach ($foo, $bar, $baz) {
.zoomdingle;
}
The objects in the list retain full status qua objects even though
they are in a list, which is why we can call methods on them.
Similarly, the fact that a scalar variable acts as a value on the
lefthand side and a rvalue on the right hand side is retained even
though it is in a list. It is the list itself which is immutable.
Python programmers will grasp this real fast - it's just a tuple.
-Erik
-Erik
Well, what if an Rvalue-assign list is simply decoupled from
a normal data list. The confusion would end. The concepts
themselves are separate, so why shouldn't the names be? data
lists become The One True List Type, and Rvalue-assign lists
become something like Rvalue sequences (or a catchier name).
Peace would reign on earth, or at least p6-lang and p6-doc.
(I hope I'm not missing something obvious here, at any rate :)
Joseph F. Ryan
ryan.311@osu
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Arrays, lists, referencing (was Re: Arrays vs. Lists)
Here are some of the answers from my own notes. These behaviors have all been confirmed on-list by the design team: An @array in list context returns a list of its elements An @array in scalar context returns a reference to itself (NOTE1) An @array in numeric (scalar) context returns the number of elements An @array in string (scalar) context returns a join of its elements An $arrayref in list context returns an arrayref (NOTE2) An $arrayref in scalar context returns an arrayref An $arrayref in numeric (scalar) context returns ??? (NOTE3) An $arrayref in string (scalar) context returns ??? Note that that's pretty consistent with how it works now. (NOTE1): This is the big change. It's what allows us to treat arrays as objects, and call methods on them like @array.length. I don't think anyone will argue that's not a good thing. (NOTE2): Note that this is a non-change. If we changed it so that an arrayref flattened itself in array context, you could never have complex data structures, because [[1,2],[3,4]] would always be the same as [1,2,3,4]. (NOTE3): I have not been able to find explicitly confirmed behaviors for these two. It has been implied that they return $arrayref.length and $arrayref.string (or whatever those methods are called). Maybe. 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 (scalar) context returns (?) A %hash in string (scalar) context returns (?) A $hashref in list context returns a hashref (NOTE2) A $hashref in scalar context returns a hashref A $hashref in numeric (scalar) context returns (?) A $hashref in string (scalar) context returns (?) (NOTE4): Or is it a flattened list of key-values? And how would it extend to the finer-grained contexts we're getting in Perl6 (integer numeric scalar context, hashref context, ...)? Our complete list of contexts now is quite a hierarchy. --- List Flattening --- My own two-sentence explanation for why this is is that in the first two examples, Csub and C:=, you're binding one variable to another, NOT dealing with the array-ness of those variables at all. E.G. [...] There, how convincing did that sound? Pretty convincing. In fact, it sounds like this binding mode is nothing more than another facet of context (i.e., difference in meaning imposed by surrounding code). Sort of like this: An @array in nonbinding list context returns a list of its elements. An @array in binding list context returns the symbol table reference for itself An @array in nonbinding scalar context returns a reference to itself. An @array in binding scalar context returns the symbol table reference for itself Would that fly? If so, I'd expect the new generic want() operator to be able to detect it. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Games people play, you take it or you leave it, things that they say just don't make it right. If I'm telling you the truth right now, do you believe it? Games people play in the middle of the night. - _Games People Play_, APP
Re: Arrays vs. Lists
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 writing about scalars. A
variable is more like a name of a container for a value, e.g. there's
three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container. So
I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
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 {...}
(@a,@b,@c).pop
[@a,@b,@c].pop
MikeL
Re: Arrays vs. Lists
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 always lists in Perl6?) I think so, unless its possible to do crazy things like reference part of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5], \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps that behaivor, then @array[4..8] is always a list. What is the utility of the perl5 behavior: \($a,$b,$c) meaning (\$a, \$b, \$c) Do people really do that? I must say, given that it looks *so obviously* like it instead means [$a,$b,$c], I wonder if attempting to take a reference to a list should be a compile-time error. Note that this is still OK: \($a) # same as \$a because as previously discussed, it's the commas making the list, not the parens. But \($a,$b,$c) seems like a bug waiting to happen. I don't use it. Can someone give an example of an actual, proper, use? What joy I'll have explaining that one to my students . . . Groan. Yeah. I feel your pain. :-| MikeL
RE: Arrays vs. Lists [x-adr]
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
Exactly. It's still up in the air...
Apoc 2, RFC 175:
So it works out that the explicit list composer:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3));
Depending on whether we continue to make a big
deal of the list/array distinction, that might
actually be spelled:
scalar(array(1,2,3));
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 array reference.
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous
container. So
I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
I'd just stick with Uri's explanation. Arrays are allocated. Lists are on
the stack...
It doesn't need improving... The only question is whether it is still
accurate in the _context_ of Perl6 ;)
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 {...}
(@a,@b,@c).pop
[@a,@b,@c].pop
There's only one person who can answer that... and he's not reading ;)
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Arrays vs. Lists [x-adr]
[Recipients trimmed back to just p6-language; the Cc: list was getting a bit large.] On 2003-02-11 at 12:56:45, Garrett Goebel wrote: I'd just stick with Uri's explanation. Arrays are allocated. Lists are on the stack... Nuh-uh. Those are implementation details, not part of the language definition. From the standpoint of the Perl6 language, in the magical world where that language is executed directly with no need of interpreters, compilers, etc., what (if anything) is the distinction between an array and a list? I like the arrays are containers that hold lists explanation, assuming it's valid. Also, I would be very surprised if \@array returned a reference to a reference. I would assume that the \ forces scalar context and therefore interpretation as a reference. So these two statements would be equivalent: $ref = @array; $ref = \@array; As would these: print \@array; print scalar(@array); -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists [x-adr]
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 array reference. I understand the logic, but: my $r = @a; # ref to @a my $r = \@a; # ref to ref to @a ??? my @array = (\@a,\@b,\@c); # array of three arrayrefs Boy howdy, I think that would freak people. But making '\' put them in list context would of course be far worse: @array = (\@a); # means @a = ( \@a[0], \@a[1], ... ) ??? So I think '\' just puts things in CRef context, which solves the problem and always does The Right Thing, I think. So the context rules for arrays are: - in scalar numeric context, returns num of elements - in scalar string context, returns join of elements - in scalar ref context, returns a ref - in generic scalar context, returns a ref IMO. MikeL
Re: Arrays vs. Lists
Michael Lazzaro wrote:
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 writing about scalars. A
variable is more like a name of a container for a value, e.g.
there's three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
They're definately variables. The container is a PerlArray,
which is a distinctly different object compared to a
PerlUndef.
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
I'd say it is an array reference.
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container
There should be a variable attached, but just no name
attached to the variable.
So I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Maybe :-)
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
But is it OK for a list to be silently promoted to an array when used
as an array
But this would mean that an implicit anonymous array would need
to be created, which isn't always possible in the middle of a
statement. So, that would mean the compiler would need to be
smart enough to figure out when this will happen, and then
create the anonymous array beforehand, and then somehow
alias the list contents to the array. Thats a heck of a lot
of magic going on there.
So that all of the following would work, and not just 50% of them?
(1..10).map {...}
I think this should be an error. What object is the method
getting called on?
Is forcing the functional syntax on lists really that horrible?
[1..10].map {...
I think this *should* work, although I'm not sure *how*.
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
I don't see any reason to change this behavior for Perl6.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
Minor correction: we don't know how many elements are left in the
array - it depends on how many elements were in @a, @b, and @c to
start with. One less than that. :)
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
JFR == Joseph F Ryan [EMAIL PROTECTED] writes:
(@a,@b,@c).pop
JFR This doesn't make any sense, since pop modifies the pop-ee.
JFR What do you expect should happen here?
[@a,@b,@c].pop
JFR Same as above.
there is a subtle distinction in those two. the first should be a syntax
error. the second isn't an error but isn't needed. you could just
as easily do ( @a, @b, @c )[-1].
and the equivilent works in perl5. dumb, but it works.
perl -le 'print pop( @{[qw(a b c)]} )'
c
and i haven't seen anything in perl6 that drastically changes the
semantics of lists and arrays from perl5. so the current definitions we
have been tossing about should suffice.
minor variation:
an array (anon or named) is a container that holds a list. the
array container itself can be modified. containers can stay
alive as long as you want.
a list is a ordered bag of values. it is alive
only where it is created in the current expression. the list
cannot be modified.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Arrays vs. Lists
Michael Lazzaro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... What is the utility of the perl5 behavior: \($a,$b,$c) meaning (\$a, \$b, \$c) Do people really do that? I must say, given that it looks *so obviously* like it instead means [$a,$b,$c], I wonder if attempting to take a reference to a list should be a compile-time error. If you make the ListRef an error, can we hyper- the reference operator to achieve the Perl5 behavior?
RE: Arrays vs. Lists
Dave Whipp:
# Minor correction: we don't know how many elements are left in the
# array - it depends on how many elements were in @a, @b, and @c to
# start with. One less than that. :)
#
# These days you need the splat operator to flatten lists: so
My understanding was that arrays would flatten implicity in list
context, and the splat was only to be used in cases like subroutine
calls, when an array would normally ref-ify.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Arrays, lists, referencing (was Re: Arrays vs. Lists)
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 all this . . .
Let's assume for the moment that there's still a functional version of
the Cmap operator (I think Larry indicated that it probably wouldn't
be going away, despite ~ and friends). I'm also going to use $_ in the
code block, even though things like $^a exist. Lowest common
denominator and all that.
Let's also assume:
@count = (1, 2, 3, 4, 5);
@smallcount = (2, 3, 4);
$#array works like in Perl5 (if not, you can mentally change my
notation below)
What's the result of these statements in Perl6?
@a = map { $_ + 1 } @count; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } @count[0..$#count]; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } (1, 2, 3, 4, 5); # my guess: @a = (2, 3, 4, 5, 6)
All fair enough. Now how about these?
@a = map { $_ + 1 } (1, @smallcount, 5); # Three or five elements?
@a = map { $_ + 1 } (1, @smallcount[0..$#smallcount], 5); # Array slices appear to
be lists
@a = map { $_ + 1 } \@count; # Map the array or its reference?
@a = map { $_ + 1 } [1, 2, 3, 4, 5]; # one-element list or five-element array?
$ref = @count;
@a = map { $_ + 1 } $ref; # Map the scalar or the array it refers to?
@a = map { $_ + 1 } @count;# Am I sure about this one any more, given the one
above?
There's a slippery slope here that needs propping up.
It's things like this that make me worry a great deal about implicit
dereferencing, something which is going to be happening a lot more in
Perl6 than in Perl5.
Where's the list of rules that state:
- when implicit referencing happens
- when implicit dereferencing happens
- when arrays are flattened into lists, and
- how to stop this from being the default, and
- how to make it happen when it isn't the default
- how arrays of pairs, lists of pairs (i.e., hash literals)
and hashes are related, and when one can be substituted for
another (and when one is implicitly converted to another)
?
I think some of this is in A2, but not all of it.
I'm prepared to summarize the outcome of this discussion if we actually
arrive at anything definite.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Oh, she's got it bad. What? What has she got? Isn't it obvious, Daddy?
Ariel's in *love*. - _The Little Mermaid_
Re: Arrays vs. Lists
Michael == Michael Lazzaro [EMAIL PROTECTED] writes: Michael Do people really do that? I must say, given that it looks *so Michael obviously* like it instead means [$a,$b,$c], I wonder if attempting to Michael take a reference to a list should be a compile-time error. Michael Note that this is still OK: Michael \($a) # same as \$a Michael because as previously discussed, it's the commas making the list, not Michael the parens. But \($a,$b,$c) seems like a bug waiting to happen. I Michael don't use it. Can someone give an example of an actual, proper, use? It was to make pass by reference easier, before prototypes if I recall: myfunc \($a, @b, %c); which means the same as if we had said: sub myfunc (\$ \@ \%); myfunc($a, @b, %c); Except that the prototyped version mandates the specific types. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Arrays vs. Lists [x-adr]
Uri Guttman wrote: arrays are allocated and lists are on the stack. so arrays can have references to them but lists can't. Apoc 2, RFC 175: scalar(list(1,2,3)); [...] scalar(array(1,2,3)); Which would imply one could take a reference to either. can anyone see any changes in perl6 to invalidate that separation of lists and arrays? Immediately thereafter, Larry left room to imply list may actually be spelled a-r-r-a-y... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Arrays vs. Lists
While I like the glib Arrays are variables that hold lists explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true.
Like what?
Well, like the builtin switch statement, which was what I was trying to
show in my bad example below.
What I meant was: In Perl5, pretty much anywhere you have a list, you
can write an array variable instead, and get much the same behaviour:
@a = (1, 2, 3);
func(@a);
func(1,2,3);
The exceptions appear to be builtin operators like Cpush,
functions that have Perl5-prototypes, and using lists/arrays as lvalues.
But all of those are caught by the Perl5 parser, and treated specially.
Everywhere else, naming an array automatically expands to a list
containing the array's contents. It's pretty much a universal, and
something which Perl programmers hold dear.
In Perl6, where there seems to be even more of a blur between
compile-time and runtime, I don't think it's always going to be possible
(i.e., easy) to know where naming an array or providing an actual list
would produce the same effect. The switch statement was my example.
Apocalypse 4 has a table (page 2 of the perl.com version) which bears
this out. Lists have their own entries on this table, separate from
arrays. So it's conceivable that a switch statement that switches on a
list and a switch statement that switches on an array containing the
same list produces different results.
Perhaps this just adds the switch statement to the set of Perl
constructs that require special compiler attention, like lvalues and
builtin operators.
(This suggests to me that it won't be possible to implement the switch
statement as a pure Perl6 function - as people were trying to do with
Cif - without greater-than-usual assistance from the Perl6 compiler.)
It also appears that we'll now be able to pass multiple arrays to
functions without the taking-references shenanigans that you have to go
through in Perl5. So there's another example where lists and arrays
appear to be going their separate ways, with lists almost being their
own data type, in a manner of speaking. I dare say that we'll have to
wait till Apocalypse 6 for the full story here.
(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 always lists in Perl6?)
For instance, the switch
statement has different rules for lists and arrays. So these don't
necessarily do exactly the same thing in Perl6:
# Please excuse syntax errors here, but you know what I mean
given (1,2,3)
{
when $x:
and
@a = (1, 2, 3);
given @a
{
when $x: ...
I don't understand the difference here. Could you elaborate?
See above.
Would there be any truth in this distinction:
- lists are ordered sets/bags/etc seen by the Perl parser
- arrays are ordered sets/bags/etc seen by the Perl interpreter
?
Where s/parser/compiler/, and s/interpretter/runtime engine/? I
do believe that's accurate.
What joy I'll have explaining that one to my students . . .
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Oh, she's got it bad. What? What has she got? Isn't it obvious, Daddy?
Ariel's in *love*. - _The Little Mermaid_
Re: Arrays vs. Lists
From: Deborah Ariel Pickett [EMAIL PROTECTED] Date: Tue, 11 Feb 2003 11:15:13 +1100 (EST) In Perl6, where there seems to be even more of a blur between compile-time and runtime, I don't think it's always going to be possible (i.e., easy) to know where naming an array or providing an actual list would produce the same effect. The switch statement was my example. Apocalypse 4 has a table (page 2 of the perl.com version) which bears this out. Lists have their own entries on this table, separate from arrays. So it's conceivable that a switch statement that switches on a list and a switch statement that switches on an array containing the same list produces different results. In these terms, I'd like to refer you to Apocalypse 2, under RFC 009. I belive this is one (perhaps the only :) thing that hasn't changed about Perl 6 sice A2. Particularly: ... If composite variables are thought of as scalar references, then the names @foo and %foo are really scalar variables unless explicitly dereferenced. That means that when you mention them in a scalar context, you get the equivalent of Perl 5's \@foo and \%foo. This simplifies the prototyping system greatly, in that an operator like push no longer needs to specify some kind of special reference context for its first argument -- it can merely specify a scalar context, and that's good enough to assume the reference generation on its first argument Indeed, this supports the distinction, which I will reiterate: - Arrays are variables. - Lists are values. Arrays are things that know about lists. They know how to get a particular element out of a list. They know how to *flatten themselves, interpolating themselves into the surrounding list. They know how to map, grep, sort, splice themselves. They know how to turn themselves into a scalar. Lists don't know how to do these things. Just like, for example, scalars. A scalar can hold a number. A scalar knows how to increment itself, but a number sure doesn't. I'm formulating new, wild ideas here... Another post coming in a minute. I hope I clarified the array/list thing at least a little bit. Luke
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote: While I like the glib Arrays are variables that hold lists explanation that worked so well in Perl5, I think that Perl6 is introducing some changes to this that make this less true. Like what? Well, like the builtin switch statement, which was what I was trying to show in my bad example below. What I meant was: In Perl5, pretty much anywhere you have a list, you can write an array variable instead, and get much the same behaviour: @a = (1, 2, 3); func(@a); func(1,2,3); The exceptions appear to be builtin operators like Cpush, functions that have Perl5-prototypes, and using lists/arrays as lvalues. But all of those are caught by the Perl5 parser, and treated specially. Everywhere else, naming an array automatically expands to a list containing the array's contents. It's pretty much a universal, and something which Perl programmers hold dear. In Perl6, where there seems to be even more of a blur between compile-time and runtime, Actually, I think they'll be more separated. In fact, the compiler will just be an extension to the runtime-engine. I don't think it's always going to be possible (i.e., easy) to know where naming an array or providing an actual list would produce the same effect. The switch statement was my example. Apocalypse 4 has a table (page 2 of the perl.com version) which bears this out. Lists have their own entries on this table, separate from arrays. So it's conceivable that a switch statement that switches on a list and a switch statement that switches on an array containing the same list produces different results. I see what you mean now; Cgiven topic-alizes what it is, well, given. This would cause it to work differently for variables and other. Perhaps this just adds the switch statement to the set of Perl constructs that require special compiler attention, like lvalues and builtin operators. I think you might be right; however, it would be nice if this wasn't the case, as then user-defined functions could act similarly. (kinda like how perl5-prototypes allow user-defined functions to act like perl5- bultins, without the yeehh of perl5-prototypes.) (This suggests to me that it won't be possible to implement the switch statement as a pure Perl6 function - as people were trying to do with Cif - without greater-than-usual assistance from the Perl6 compiler.) It also appears that we'll now be able to pass multiple arrays to functions without the taking-references shenanigans that you have to go through in Perl5. So there's another example where lists and arrays appear to be going their separate ways, with lists almost being their own data type, in a manner of speaking. I dare say that we'll have to wait till Apocalypse 6 for the full story here. (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 always lists in Perl6?) I think so, unless its possible to do crazy things like reference part of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5], \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps that behaivor, then @array[4..8] is always a list. Would there be any truth in this distinction: - lists are ordered sets/bags/etc seen by the Perl parser - arrays are ordered sets/bags/etc seen by the Perl interpreter ? Where s/parser/compiler/, and s/interpretter/runtime engine/? I do believe that's accurate. What joy I'll have explaining that one to my students . . . Better you than me. :-) Joseph F. Ryan [EMAIL PROTECTED]
Re: Arrays vs. Lists
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.
While I like the glib Arrays are variables that hold lists explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true. For instance, the switch
statement has different rules for lists and arrays. So these don't
necessarily do exactly the same thing in Perl6:
# Please excuse syntax errors here, but you know what I mean
given (1,2,3)
{
when $x:
and
@a = (1, 2, 3);
given @a
{
when $x: ...
Would there be any truth in this distinction:
- lists are ordered sets/bags/etc seen by the Perl parser
- arrays are ordered sets/bags/etc seen by the Perl interpreter
?
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Oh, she's got it bad. What? What has she got? Isn't it obvious, Daddy?
Ariel's in *love*. - _The Little Mermaid_
Re: Arrays vs. Lists
Deborah Ariel Pickett wrote:
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.
While I like the glib Arrays are variables that hold lists explanation
that worked so well in Perl5, I think that Perl6 is introducing some
changes to this that make this less true.
Like what?
For instance, the switch
statement has different rules for lists and arrays. So these don't
necessarily do exactly the same thing in Perl6:
# Please excuse syntax errors here, but you know what I mean
given (1,2,3)
{
when $x:
and
@a = (1, 2, 3);
given @a
{
when $x: ...
I don't understand the difference here. Could you elaborate?
Would there be any truth in this distinction:
- lists are ordered sets/bags/etc seen by the Perl parser
- arrays are ordered sets/bags/etc seen by the Perl interpreter
?
Where s/parser/compiler/, and s/interpretter/runtime engine/? I
do believe that's accurate.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
--- Michael Lazzaro [EMAIL PROTECTED] wrote: 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. How's this? A number is a literal (e.g., 3) that can be used as the initializer for a scalar. A string is a literal (e.g., Hello, world) that can be used as the initializer for a scalar. A list is a literal (e.g., '(3, Hello, world)') that can be used as the initializer for an array. With one exception, places in perl that require a scalar can be given a literal number or string. Likewise, places in perl that require an array can be given a list. The exception is lvalues -- you can't say 3 = Hello, world; -- the left-hand side of an assignment operation requires an assignable thing, not a literal. So the difference between a list and an array is one of assignability - a list can be indexed, examined, copied, iterated over using for, etc. But in order to make changes you have to have an array -- a container for a list. Because arrays can do all the things above, plus shift, pop, append, delete, etc. ==? =Austin
Re: Arrays vs. Lists
On 2003-02-07 at 11:13:07, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: I'm trying, and failing, to accurately and definitively answer the question what's the difference between an array and a list in Perl6? How's this? A list is a literal (e.g., '(3, Hello, world)') that can be used as the initializer for an array. [...] places in perl that require an array can be given a list. The exception is lvalues -- you can't say 3 = Hello, world; -- the left-hand side of an assignment operation requires an assignable thing, not a literal. So the difference between a list and an array is one of assignability. Not really, though. A list can be an lvalue, provided it is a list of lvalues: ($a, $b, $c) = 1,2,3; Although this may reasonably be regarded as a special case; you certainly can't pop a list: (1,2,3).pop = error But there's also the case of anonymous arrays, constructed through reference via [ . . . ]. These are pop'able: [1,2,3].pop = 3 But they certainly aren't lvalues: [$a,$b,$c] = 1,2,3 = error Unless some magic autoconversion happens. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
On 2003-02-07 at 14:26:42, Mark J. Reed wrote: Not really, though. A list can be an lvalue, provided it is a list of lvalues: ($a, $b, $c) = 1,2,3; Forgot the parens on the right side, there: ($a, $b, $c) = (1,2,3); But they certainly aren't lvalues: [$a,$b,$c] = 1,2,3; = error [$a, $b, $c] = (1,2,3) = still an error Just to flesh it out: [$a, $b, $c] = [1,2,3] = still an error ($a, $b, $c) = [1,2,3] = not an error; $a is [1,2,3], $b and $c undef. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
--- Mark J. Reed [EMAIL PROTECTED] wrote: On 2003-02-07 at 11:13:07, Austin Hastings wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: I'm trying, and failing, to accurately and definitively answer the question what's the difference between an array and a list in Perl6? How's this? A list is a literal (e.g., '(3, Hello, world)') that can be used as the initializer for an array. [...] places in perl that require an array can be given a list. The exception is lvalues -- you can't say 3 = Hello, world; -- the left-hand side of an assignment operation requires an assignable thing, not a literal. So the difference between a list and an array is one of assignability. Not really, though. A list can be an lvalue, provided it is a list of lvalues: ($a, $b, $c) = 1,2,3; Hmm. You're kind of weaseling there because that's DWIM magic for 3 lines of code, but I don't know how to get there. Although this may reasonably be regarded as a special case; you certainly can't pop a list: (1,2,3).pop = error But could you do it the other way (function instead of method)? pop (1,2,3) = ? But there's also the case of anonymous arrays, constructed through reference via [ . . . ]. These are pop'able: [1,2,3].pop = 3 But they certainly aren't lvalues: [$a,$b,$c] = 1,2,3 = error Actually, they're literal array references, not arrays. I'm unsure how the mechanics are going to act in p6, since we're hiding the - on refs. But in my heart of (c coding) hearts, it's a pointer. =Austin
Re: Arrays vs. Lists
On 2003-02-07 at 12:18:21, Austin Hastings wrote: Although this may reasonably be regarded as a special case; you certainly can't pop a list: (1,2,3).pop = error But could you do it the other way (function instead of method)? pop (1,2,3) = ? Nope. At least, not in Perl 5: Type of arg 1 to pop must be array (not list) But there's also the case of anonymous arrays, constructed through reference via [ . . . ]. These are pop'able: [1,2,3].pop = 3 But they certainly aren't lvalues: [$a,$b,$c] = 1,2,3 = error Actually, they're literal array references, not arrays. You can't have an array reference without an array; the reference has to refer to something. :) The referred-to-array in this case has no name, hence anonymous arrays, constructed through reference. I'm unsure how the mechanics are going to act in p6, since we're hiding the - on refs. But in my heart of (c coding) hearts, it's a pointer. A reference is fundamentally a pointer, but that doesn't help. My point was that if you're talking about lists vs. arrays, you have at least three different syntaxes to distinguish: (1,2,3) @arrayName [1,2,3] These all do different things, and autoconversion just adds to the confusion - for instance, @arrayName is normally an array, but in certain contexts it will be automatically turned into a reference ($aRef = @arrayName) or flattened into a list (print @arrayName). -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
MJR == Mark J Reed [EMAIL PROTECTED] writes: MJR A reference is fundamentally a pointer, but that doesn't help. My point MJR was that if you're talking about lists vs. arrays, you have at least MJR three different syntaxes to distinguish: MJR (1,2,3) MJR @arrayName MJR [1,2,3] one simple explanation still works i think. arrays are allocated and lists are on the stack. so arrays can have references to them but lists can't. this works with both lvalue and rvalue. a list of lvalues is on the stack and can be assigned to. you can't push/pop/splice a list on the stack. you can take slices from a list on the stack. 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. can anyone see any changes in perl6 to invalidate that separation of lists and arrays? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Arrays vs. Lists
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 lines, the closest I've been able to come so far to a usable two-sentence definition is: -- A list is an ordered set of scalar values. -- An array is an object that stores a list. But I'm not sure that holds water. MikeL
Re: Arrays vs. Lists
ML == Michael Lazzaro [EMAIL PROTECTED] writes: ML 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. ML Along those lines, the closest I've been able to come so far to a ML usable two-sentence definition is: ML -- A list is an ordered set of scalar values. ML -- An array is an object that stores a list. but you can't derive the rules about allowing push/pop/splice/slice from that pair of defintions. you can simplify my pair to: a list is temporary ordered set of scalar values that lives only in a single expression an array is an ordered set of scalar values that is allocated and can live between expressions. note that i said expression and not statement. you can't have the same list in two parts of an expression while you can with an array (ref or plain). that implies you can't change a list since it only exists once. another (and shorter pair) is this: (note that this is from the whole list point of view, not its elements) lists are read only arrays are read/write that allows slices on lists but not push/pop/splice. the lvalueness of their elements doesn't matter. the two sets of pairs above can be combined for clarity: (again these are from the whole list/array point of view) a list lives in a single place in a single expression and can't be modified. an array can live in multiple places in multiple expressions and can be changed the single place makes it impossible to take a ref to a list. the multiple places for an array implies references are possible. the array can be changed since it has state that will store the change. a list has no such state as it will die when the expression is done. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Arrays vs. Lists
Michael Lazzaro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Along those lines, the closest I've been able to come so far to a usable two-sentence definition is: -- A list is an ordered set of scalar values. quibble: that's an ordered bag, isn't it? ;) -- An array is an object that stores a list. My phrasing of the distinction is that a list is a lexical entity, whilst an array is a variable. Anonymous array constructors are just special syntax for passing a list to an array (or Array) constructor.
Re: Arrays vs. Lists
On Fri, Feb 07, 2003 at 02:30:47PM -0500, Mark J. Reed wrote: On 2003-02-07 at 14:26:42, Mark J. Reed wrote: Not really, though. A list can be an lvalue, provided it is a list of lvalues: Note that to avoid the burden of writing an explicit slice, 'undef' is considered as a lvalue in such a context. I see no reason for that behavior to change in perl6: ($a, undef, $b) = (1, 2, 3); # equivalent to ($a,$b) = (1, 3) Note this is only true of undef. You can't stick any literal in its splace. ($a,1,$b) = qw(1,2,3) Can't modify constant item in list assignment at (eval 5)[/usr/lib/perl5/5.8.0/perl5db.pl:17] line 2, at EOF -- stef
Re: Arrays vs. Lists
ML == Michael Lazzaro [EMAIL PROTECTED] writes:
ML 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.
ML Is there any syntactic reason why both of the following cannot be
ML allowed?
ML (1,2,3).pop
that is no different than saying (3). as the list can't be modified nor
a ref taken, the pop is illegal.
ML [1,2,3].pop
ML I don't know that one is any more/less useful than the other, and it
ML would seem a list could be silently promoted to an array where it is
ML used as an array. For example,
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
list but sugar for a new anon array and more like:
do{ \my @foo = ( 1, 2, 3 ) }
but we only need [] for all that.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Arrays vs. Lists
On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote: ML == Michael Lazzaro [EMAIL PROTECTED] writes: ML Along those lines, the closest I've been able to come so far to a ML usable two-sentence definition is: ML -- A list is an ordered set of scalar values. ML -- An array is an object that stores a list. but you can't derive the rules about allowing push/pop/splice/slice from that pair of defintions. 1) A list is an ordered grouping of scalar values. 2) An array is an object that stores a list. 3) Assignment and splices can be performed on both lists and arrays. 4) Operators like push/pop/splice/shift/unshift operate only on arrays. lists are read only Not quite: ($a, $b, $c) = 1..3; Z.
Re: Arrays vs. Lists
Date: Fri, 7 Feb 2003 14:46:37 -0800 From: Michael Lazzaro [EMAIL PROTECTED] 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 lines, the closest I've been able to come so far to a usable two-sentence definition is: -- A list is an ordered set of scalar values. -- An array is an object that stores a list. But I'm not sure that holds water. Rather, -- An array is a variable. -- A list is a value. It's just a special kind of value, that distributes certain operators over its elements. It's still a value. The discrepancy about Array's methods is simple. Can you Cchop a string literal? That's why you can't Cpop a list. Luke
Re: Arrays vs. Lists
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 thread. I remember (vaguely) now... can't do what I suggested because it's something like \($x) should never be a list ref, which means we would have to treat parens differently depending on how many things are inside them, etc, which pointedly won't work. If someone remembers when that damn thread happened, or better still remembers the outcome (if any), drop me a pointer? MikeL
Re: Arrays vs. Lists
AT == Adam Turoff [EMAIL PROTECTED] writes: AT On Fri, Feb 07, 2003 at 06:38:36PM -0500, Uri Guttman wrote: ML == Michael Lazzaro [EMAIL PROTECTED] writes: ML Along those lines, the closest I've been able to come so far to a ML usable two-sentence definition is: ML -- A list is an ordered set of scalar values. ML -- An array is an object that stores a list. but you can't derive the rules about allowing push/pop/splice/slice from that pair of defintions. AT 1) A list is an ordered grouping of scalar values. AT 2) An array is an object that stores a list. AT 3) Assignment and splices can be performed on both lists and arrays. you can't assign to a list. you can assign to lvalues in a list. the list doesn't change. it is a list of lvalues before and after the assignment. AT 4) Operators like push/pop/splice/shift/unshift operate only on arrays. lists are read only AT Not quite: ($a, $b, $c) = 1..3; that list is still unmodified, same size, no elements are changed. the elements are lvalues which have their values changed, but the list itself is still read only. only my two definitions are needed, not 4. simpler is better. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Primitive Vs Object types
Mark J. Reed wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
You will. But they won't be entries of a hash. They'll be
separate variables and associated accessor methods.
So maybe something like this:
foreach my $attr (qw(foo bar baz))
{
print $attr: $self.$attr()\n;
}
Damian
Re: Primitive Vs Object types
Luke Palmer wrote:
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
I'm not sure either of those works, exactly. The scope of attributes isn't
precisely lexical in nature. Perhaps instead of a CMY method, an object
would have a (private!) CHAS method, allowing something like:
for $this.HAS - $attr {
print $attr.key(): $attr.value()\n
}
Or maybe not. ;-)
Damian
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote:
Basically anything you can potentially find in a symbol table or
lexical scratchpad will potentially be able to have a property
attached to it. The only way that we'll be able to reasonably
restrict (and optimize) the use of low-level data types is to keep
them out of the symbol tables, which then makes using them in string
evals and suchlike things somewhat problematic. (And not allowing
properties on them will require us to throw runtime errors) It'll
also make passing them in as parameters interesting, as we'd then
need to construct temporary full variables that held them, which'd be
somewhat interesting to deal with.
But surely there should be no problem passing things as parameters - with a
bit of mundane magic even taking reference to a bit should work quite nicely.
After all, perl5 can already handle the idea of not autovivifying hash lookups
passed as subroutine parameters, and assigning to substrings and substring
references:
#!/usr/local/bin/perl -w
use strict;
use Devel::Peek;
sub rroll {
Dump $_[0];
$_[0] x= 6;
}
sub oll {
Dump $_[0];
${$_[0]} x= 4;
}
$a = Mordor;
rroll (substr ($a, 2, 1));
print '$a'\n;
oll (\substr ($a, -1));
print '$a'\n;
__END__
SV = PVLV(0x1138c0) at 0x1332e8
REFCNT = 1
FLAGS = (PADMY,GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x133d98 r\0
CUR = 1
LEN = 2
MAGIC = 0x10e8f0
MG_VIRTUAL = PL_vtbl_substr
MG_TYPE = PERL_MAGIC_substr(x)
TYPE = x
TARGOFF = 2
TARGLEN = 1
TARG = 0x132f10
SV = PV(0xf4580) at 0x132f10
REFCNT = 2
FLAGS = (POK,pPOK)
PV = 0x10c398 Mordor\0
CUR = 6
LEN = 7
'Morrdor'
SV = RV(0x11dee8) at 0xf4284
REFCNT = 1
FLAGS = (ROK)
RV = 0x13336c
SV = PVLV(0x1138f0) at 0x13336c
REFCNT = 2
FLAGS = (PADMY,GMG,SMG,pPOK)
IV = 0
NV = 0
PV = 0x1137e0 r\0
CUR = 1
LEN = 2
MAGIC = 0x10e060
MG_VIRTUAL = PL_vtbl_substr
MG_TYPE = PERL_MAGIC_substr(x)
TYPE = x
TARGOFF = 10
TARGLEN = 1
TARG = 0x132f10
SV = PV(0xf4580) at 0x132f10
REFCNT = 3
FLAGS = (POK,pPOK)
PV = 0x10c398 Morrdor\0
CUR = 11
LEN = 12
'Morrdo'
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Primitive Vs Object types
Larry Wall wrote: ... I can see ways of binding properties to a location without growing the location itself, but I think stuffing a junction of ints into a single location is somewhat problematical. We are still talking about native types - these with lowercase names in the docs? Why should they have runtime properties? (E2/A2 state, they have none) ... As for undef, it *could* just be a property, but for efficiency it would be nice to represent it in-band for those types that can so represent it, and it ought to be possible to tell the million bit array whether or not it is willing to store undef properties off to the side. We can argue whether the default should be yes or no... Adding properties to individual Cbits is a PITA as well as appending extra information, e.g undef. A CBIT array could start as a packed array of bits, adding runtime properties would promote this array to an array of PMCs, i.e. objects, which handle these properties. Larry leo
Re: Primitive Vs Object types
--- Michael Lazzaro [EMAIL PROTECTED] wrote: Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. It can't even be undef, because that would take an extra bit, minimum, to store. This just ain't so. I once worked on a CPU simulator, and in order to set watch values on arbitrary memory we used a key value that, if present in simulated memory, indicated that a search of the watches table was in order. That key was chosen empirically, based on histogramming the ROM images and active program state, and choosing the lowest frequency value. Thus, the fetch byte primitive would automatically check and notify whenever a 0xA9 was seen. (Sometimes it really meant 0xA9, other times it meant 0x00, but halt execution.) The same can be done here, if the internals folks can make the assumption that the case is really uncommon. To wit: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of C + Num_undef_bits * sizeof(addr_t) Which will be greater than one extra bit when few or no bit objects are used, and will be very much smaller than one extra bit when many bit objects are used. In short: It's possible, even easy, to implement ANY feature (properties, undef, etc) for primitive types in this manner. It absolutely *IS* correct to say That's an implementation detail and leave it to the internals team to figure out HOW they want to do it. So what's the difference REALLY? =Austin __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
Re: Primitive Vs Object types
On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of Right. So it's a question of having a little extra storage (at least 1 bit, somewhere, for each undef), but more importantly a question of whether or not there are primitive types that circumvent that check. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. In cases where it is allowed, the intrinsic type must generally be promoted to its corresponding object type (or wrapped in an object that delegates back to the original intrinsic for the actual value). But you really don't want to promote an array of a million bits to an array of a million objects just because you had the hankering to put a sticky note on one of those bits, so in those cases it's likely to be disallowed, or the bit is likely to be cloned instead of referenced, or some such thing. If internals says that there's no runtime speed issue, that's awesome. I think we just have to be aware of one of our implied goals -- that Perl6 can be used for giant data-munging tasks without speed penalties so horrific as to send people to other languages. MikeL
Re: Primitive Vs Object types
Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. My interpretation: A CINT my start as as Cint as long as the compiler/optimizer doesn't see any attributes/tie/bless or whatever, that would need an object. If so, it promotes to an object. More important: how big is Cmy bool bit_ar is dim(1000,1000). It will be 10^6 / (sizeof(int) * CHAR_BIT) + list_overhead. leo
Re: Primitive Vs Object types
At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. Basically anything you can potentially find in a symbol table or lexical scratchpad will potentially be able to have a property attached to it. The only way that we'll be able to reasonably restrict (and optimize) the use of low-level data types is to keep them out of the symbol tables, which then makes using them in string evals and suchlike things somewhat problematic. (And not allowing properties on them will require us to throw runtime errors) It'll also make passing them in as parameters interesting, as we'd then need to construct temporary full variables that held them, which'd be somewhat interesting to deal with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
Dan Sugalski wrote: At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 03:56:04PM -0600, Garrett Goebel wrote:
Dan Sugalski wrote:
At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote:
Michael Lazzaro wrote:
On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote:
For 'bit', the key value is (eenie, meenie, ...) '1'.
From A2 we have:
Run-time properties really are associated with the object in
question, which implies some amount of overhead. For that reason,
intrinsic data types like Cint and Cnum may or may not allow
run-time properties.
From E2: a Cint will never have attributes or promote to an object.
Attributes aren't properties.
I thought:
'attributes' :Perl5 == 'properites' isa Perl6
Yeah. Where the Apocalyses and Exegeses say attributes they are
referring to data members of an object:
class Foo {
has $.bar is friendly;
}
$.bar is an attribute (of Foo-ish objects), friendly is a property (of
the $.bar attribute).
Can someone point me to Perl6 definitions for both terms?
It's probably in Michael Lazzaro's documentation somewhere ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Primitive Vs Object types
At 3:56 PM -0600 11/7/02, Garrett Goebel wrote: Dan Sugalski wrote: At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like Cint and Cnum may or may not allow run-time properties. From E2: a Cint will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? Short(ish) answer: perl 6 attributes are much like the hash entries in a perl 5 object (assuming you use a hash as your object), only the keys are fixed at class definition time, and each parent/child/grandchild class can only see its own slots in the objects. And slot names don't collide, so every class in a 47-class inheritance chain can have an attribute Foo. perl 6 properties are more on the order of runtime notations on a variable. (Damian likes the properties-as-PostIt-note metaphor. As do I, come to think of it) Properties will be global to a variable, and queryable at runtime. Attributes are class-specific for a variable (okay, class instance specific, if you do Evil Things with multiple copies of a single base class in different legs of the inheritance tree and override the default behaviour of the engine) and not queryable at runtime without really nasty parrot assembly code. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
[Recipients list trimmed back to just the list - it was getting ridiculous.
So everyone will get only get one copy and it may take a tad longer to
get there . . .]
On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
Will something like that not be possible in Perl6?
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Thu, 7 Nov 2002 17:19:28 -0500
From: Mark J. Reed [EMAIL PROTECTED]
Content-Disposition: inline
X-Julian-Day: 2452586.42675
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
[Recipients list trimmed back to just the list - it was getting ridiculous.
So everyone will get only get one copy and it may take a tad longer to
get there . . .]
On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print $attr: $this-{$attr}\n;
}
Will something like that not be possible in Perl6?
I'm afraid that statement is false for all values of something :)
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
Luke
Re: Primitive Vs Object types
On 2002-11-07 at 15:28:14, Luke Palmer wrote:
From: Mark J. Reed [EMAIL PROTECTED]
Will something like that not be possible in Perl6?
I'm afraid that statement is false for all values of something :)
Good point. Erratum: for possible, read easy. :)
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
Either of those would be sufficiently easy. Thanks.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote: : At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: : Michael Lazzaro wrote: : : : On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: : : For 'bit', the key value is (eenie, meenie, ...) '1'. : : : From A2 we have: : : Run-time properties really are associated with the object in : question, which implies some amount of overhead. For that reason, : intrinsic data types like Cint and Cnum may or may not allow : run-time properties. : : : From E2: a Cint will never have attributes or promote to an object. : : Attributes aren't properties. : : Basically anything you can potentially find in a symbol table or : lexical scratchpad will potentially be able to have a property : attached to it. The only way that we'll be able to reasonably : restrict (and optimize) the use of low-level data types is to keep : them out of the symbol tables, which then makes using them in string : evals and suchlike things somewhat problematic. (And not allowing : properties on them will require us to throw runtime errors) It'll : also make passing them in as parameters interesting, as we'd then : need to construct temporary full variables that held them, which'd be : somewhat interesting to deal with. I don't much care about single scalar bits or ints, but I do care that an array of a million bits be represented by a million bits or so, especially in the absence of any properties. I can see ways of binding properties to a location without growing the location itself, but I think stuffing a junction of ints into a single location is somewhat problematical. As for undef, it *could* just be a property, but for efficiency it would be nice to represent it in-band for those types that can so represent it, and it ought to be possible to tell the million bit array whether or not it is willing to store undef properties off to the side. We can argue whether the default should be yes or no... Larry
Re: Primitive Vs Object types
At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? I was sure up until the time that I read your reply :). Why? I guess its a case of ass/u/me; plus reading other people's assumptions (e.g. Michael Lazzaro's initial Chapter, at cog.cognitivity.com/perl6/val.html). If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? Dave.
RE: Primitive Vs Object types
At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Primitive Vs Object types
David Whipp wrote: Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? Why? I guess its a case of ass/u/me; plus reading other people's assumptions (e.g. Michael Lazzaro's initial Chapter, at cog.cognitivity.com/perl6/val.html). Oh, no you don't... don't pin this one on me. :-) If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? It has been stated multiple times that primitive types can't take runtime properties or other object-like features, so that they may be as lightweight as possible -- flyweight classes, as it were. Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. It can't even be undef, because that would take an extra bit, minimum, to store. Promoted types, on the other hand, can do all that stuff -- that's the whole reason there are two separate versions of each type. It allows some credible possibility of optimal runtime efficiency in Perl6, when it's important to you. It is not necessarily a given that the behavior will hold true for superpositions. In fact, it is hypothetically possible (tho almost certainly unworkable) that typechecking on primitives wouldn't really enforce true primitiveness at all, but merely acts as a suggested type, trading optimal efficiency for more moderate efficiency (but meaning you _could_ store an undef, etc. in a hole meant for a primitive: it'll just have to assume more runtime checks then it originally would for a true primitive.) Or it may be that storing in primitive type does indeed enforce maximal efficiency, and that you should use the promoted types when you don't want that. Dunno. MikeL
RE: Primitive Vs Object types
Dan Sugalski [mailto:dan;sidhe.org] wrote: At 8:24 PM -0800 11/6/02, David Whipp wrote: If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? The big difference is there's no way you can ever truly get a primitive type in perl 6. (At least so primitive that you can't hang properties off it) I hope I'm not being stupid here, but isn't that a lack-of difference. Michael has just confirmed that 'It has been stated multiple times that primitive types can't take runtime properties or other object-like features', so now I'm confused. Here's a list of things that ints/Ints might do, and my previous understanding of if they can: int Int 1 store 32-bit number YY 2 store larger number NY 3 store undef NY 4 have properties NY 5 be junctions NY It appears that you're saying that (4) is incorrect; and if this is wrong, then (3) is probably wrong too. I wouldn't be surprised if this means that (5) is wrong also, so this would just leave (2): Ints are bigger than ints. My original proposal still stands: represent these differences as a (compile-time) property, not a new type. Failing that, use typenames that are more distinctive (e.g. BigInt, or int32). Dave.
Re: Primitive Vs Object types
I gotta admit that this issue is bugging me too. Larry mentions (in http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.44.0210140927520.20533-10%40london.wall.org) that all-uppercase is ugly and has boundary conditions. Maybe it would be helpful to know what conditions are causing problems. All-lowercase implies that we want them to be used *more* than the object types. But it seems like we should encourage the use of the object types. Maybe that's because we want to discourage undef values, but I've been programming databases too long, so I like undefs now. We certainly don't want to discourage using the autopromoting Int - Long - Bignum features of the object types, do we? Also the typecasting functions have been defined in all lower case, which would suggest to the naive user that they will typecast to primitive types, and perhaps even throw an exception when an undef is cast. On Wed, 6 Nov 2002, Michael Lazzaro wrote: David Whipp wrote: Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? It has been stated multiple times that primitive types can't take runtime properties or other object-like features, so that they may be as lightweight as possible -- flyweight classes, as it were. Primitive types were originally intended for runtime speed, thus an int or a bit is as small as possible, and not a lot of weird runtime checking has to take place that would slow it down. I don't think the point is to store them as small as possible, but as efficiently as possible. That is, in whatever register size the hardware works best on. We don't want to compact unrelated bits into a single hardware address, because then we are forced to do extra masking and shifting everytime we want to use the value. ~ John Williams
Re: eq Vs == Vs ~~ ( was Re: Primitive Boolean type?)
See http://archive.develooper.com/perl6-internals;perl.org/msg11308.html for a closely-related discussion. /s On Fri, 1 Nov 2002, David Whipp wrote: In Perl6, everything is an object. So almost everything is neither a number nor a string. It probably doesn't make sense to cast things to strings/ints, just to compare them. We probably want a standard method: .equals(), that does a class-specific comparison. The question is, will we be modifying the definnitions of == and eq, so that one will call the .equals method explicity. And what does the other do? Do we want to define them in terms of identity vs equality? Then, is identity a class-specific thing (i.e. a .identical() method); or is it an address-in-memory kind of thing? Did I miss a previous discussion of this? Dave.
Re: vector vs. hyper
On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
damian's syntax table and his use of the term vectorizing made me wonder
why we call his [op] thing a hyperoperator? the word hyper i assume came
from hyperdimensional. but calling [] the vectorizing (or just vectored)
op variant makes much more sense.
I vote for 'vector' too. I also really like the [] idea.
--
print+qq$}$$/$s$,$*${$}$g$s$$.$q$,$:$.$q$^$,$$*$~$;$.$q$mif+map{m,^\d{0\,},,${$::{$'}}=chr($+=$||1)}q10m22,42}6:17*2~2.33;^2$g3q/s=~m*\d\*.*g
Re: XOR vs. Hyper (was Re: Perl6 Operator List)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Sat, 26 Oct 2002 23:01:31 -0700
From: Michael Lazzaro [EMAIL PROTECTED]
X-Accept-Language: en,pdf
Cc: Damian Conway [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12-dev, http://develooper.com/code/qpsmtpd/
FWIW, if people are really eager to keep ^ for xor (I don't think
anything's clicking great as a replacement), we could of course switch
hyper to ~. That would give us, in part:
What about smart match, then? Would that go back to =~ ?
To be personally honest, my favorite (still) is:
^Hyper
\\ Xor
unary ! Not (screw parallelism: it was never there before)
~Cat
_ nada ahora
binary ! niente ora
~~ Smart match
I have no preferences for the bitops, as I don't find them remotely
useful in my work.
Modifying your table:
? ! + - _ # unary prefixes
+ - * / % ** x xx# binary
+=-= *= /= %= **=x=xx=
^+^- ^* ^/ ^% ^**^x^xx# hyper
^+= ^-=^*=^/=^%=^**= ^x= ^xx=
and or xor err# logical ops
|| \\// # logical ops
b b| b\ # No biterr??! :)
|\# No superr either...
all any one none # none? Seriously :)? Fun.
I dunno, that's just me. The only problem with \\ is will people
remember which way is which? It'd be a shame to see
$fh = open('/etc/passwd') \\ die Can't open /etc/passwd: $!
And have it always die. But honestly, that's not too much of a
problem. A mnemonic might be that \\ has negative slope, and \\
kindof negates... kindof. Well, forget that.
As for unary \, who cares? ! is fine for negation. C didn't make the
connection, so why must we?
Or we could make ! the reference op 8-P
Luke
Re: Attribute vs. Property
David Wheeler wrote: I just want to verify that I properly understand the use of these two terms in Perl 6. and in the wider OO community, BTW. * An attribute is a data member of a class. Yes. * A property is a piece of metadata on a...uh...thing -- e.g., on an attribute, on a class, or on a method. or on a subroutine, closure, or value. Do I have it right? Yes. So do I just need to turn myself around (at least when talking about Perl), or is there a chance that the language designers would decide that the way I use the terms is ever-so-much-better? ;-) Well, I suppose there's always a *chance* that we'd both completely reverse our careful thinking on this issue and ignore the common usage of attribute in the OO literature. But I do think it would be easier all round if you just went with our chosen terminology for Perl 6. ;-) Damian
Re: Attribute vs. Property
On 5/11/02 2:48 PM, Damian Conway [EMAIL PROTECTED] claimed: Well, I suppose there's always a *chance* that we'd both completely reverse our careful thinking on this issue and ignore the common usage of attribute in the OO literature. But I do think it would be easier all round if you just went with our chosen terminology for Perl 6. ;-) Damn. I was afraid you were going to say that! :-) Thanks for the reply. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Curious: - vs .
Buddha Buck [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Oops, meant anonymous array. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Hmm... I plead posting late at night. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error Apart from the fact that we're adding one more meaning to [], one which has no mnemonic relationship with arrays, no reason at all. -- Piers Cawley www.iterative-software.com
Re: Curious: - vs .
On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. -- Bart.
Re: Curious: - vs .
Bart Lateur [EMAIL PROTECTED] writes: On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. Yes, well, some people want to get rid of the indirect object syntax, not require it. I don't use it myself, but my understanding is that $bar = method $obj() is legal right now, and that your second example isn't a special-case but just one example of the general case. -- Bart.
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Oops, meant anonymous array. To be overly pedantic I thought [$one, 2, 3] was a ref to an anonymous array... Other than severe dependence on the comma, is there any reason why we couldn't have the following? [snip] Apart from the fact that we're adding one more meaning to [], one which has no mnemonic relationship with arrays, no reason at all. Since it looks like we are going to be getting $object.method() anyway, it doesn't matter much. It was more of a facetious suggestion to begin with -- although that doesn't mean that it wouldn't work, it's just not going to happen, and I know it. Piers Cawley www.iterative-software.com
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.
It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.
Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.
Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.
--
Bart.
Re: Curious: - vs .
the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.
So you want a method invocation syntax that doesn't remind people of
references. OK. But why does it have to be the dot? It is already taken.
Sorry. Use an operator that doesn't exist yet in Perl. For example, old
style VB used ! to connect objects and their properties:
$object!method(foo, bar);
It doesn't have to be the dot. But the plain fact is that the dot is
generally recognized in this way; why is making Perl syntax more
recognized a bad thing? If what we're after is making Perl better, then
one of the primary improvements should be making objects more readable for
the multi-language programmer. I'm really not against '-', but then
again, I *like* that
an-object-is-a-reference-which-means-I-can-poke-and-prod-it-and-embed-it-etc.
Even so, I recognize that it doesn't make Perl more readable, especially
when glob syntax is used to manipulate the reference table.
A traditionally negating symbol ('!') is the last character I would want
to see. As for VB ;)
Re: Curious: - vs .
Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. -- Piers Cawley www.iterative-software.com
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error -- Piers Cawley www.iterative-software.com
RE: Curious: - vs .
$foo = [$one, $two, $three]; # creates an anonymous list. $foo = [$object method(foo, bar)]; This would interpret as $foo[0] == $object, etc... Ilya -Original Message- From: Buddha Buck [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:20 PM To: Piers Cawley Cc: Bart Lateur; [EMAIL PROTECTED] Subject: Re: Curious: - vs . Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error -- Piers Cawley www.iterative-software.com
Re: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur writes: : Yeah. But no cheers then. The problem still remains: you can access a : hash in the normal way in plain code, but inside a sub, you can mainly : only access a passed hash through a reference. Won't be a problem. : It's annoying to basically having two ways of doing something, and one : of them can't be used half of the time. : : Even though @foo and %foo may be two different structures, a scalar $foo : can only reference one of them at a time. : : Are you going to provide a simpler aliasing mechanism to turn a hash : reference, for example as passed to a sub as an argument, back into the : full-blown hash? Simpler (and safer) than the much frowned upon : assignment to a tyeglob, that is. Yes. In fact, a %hash prototype will provide a scalar context, forcing a %foo arg to return a reference, and that ref will be aliased to %hash. You will be required to do something explicit to declare an argument that supplies list context and slurps the rest of the args. (There will also be an explicit way to slurp a list of items but supply scalar context.) Larry
Re: Strings vs Numbers (Re: Tying Overloading)
At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
Edward Peschko writes:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
I was teaching an intro class yesterday and as usual, there were several
people who typed just that instead of what I'd taught, so there is
obviously some intuitive merit to it.
Re: Strings vs Numbers (Re: Tying Overloading)
John Porter wrote: We could y/$@%/@%$/ ... ... and create an alternate parser able to handle the full internal internals API. I have finally figured out the main motivation behind the whole perl6 effort: the obfuscated perl contests were getting repetitive. Good night.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), Larry Wall wrote:
Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
:
: $hashref.{ }
:
: be that desirable? I really like -{ } in that case..
It won't be either of those. It'll simply be $hashref{ }.
Er... hip hip hurray?!?!
This is precisely the reason why I came up with the raw idea of
highlander variables in the first place: because it's annoying not being
able to access a hash passed to a sub through a hash reference, in the
normal way. Not unless you do aliasing through typeglobs. A highlander
variable would get you that: that if a hash %foo exists, the scalar $foo
would automatically be a reference to that hash.
But, if there won't be full blown highlander variables, how does Perl
know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
hash referenced by the hashref $foo?
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimensional hash, going to go? Otherwise %hash{$a, $b} is going to
be ambiguous.
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs. A highlander
: variable would get you that: that if a hash %foo exists, the scalar $foo
: would automatically be a reference to that hash.
:
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Likewise, bare @foo, %foo, foo in function prototypes will default
to supplying a scalar context, so they don't eat arguments. The final
argument will have to be specifically marked if you want it to eat
up arguments. And we'll probably distinguish eating a list in list
context from eating a list of scalars, so you could pass a list of
arrays easily to a variadic function with each variable name in
scalar context so as to produce a reference.
This is a little hard to explain, but I intuit that it will turn out to
be intuitive.
Larry
Re: Strings vs Numbers (Re: Tying Overloading)
Nathan Wiger wrote: Here's something I was thinking about at lunch: $concated_number = $number + $other_number; $numerical_add = $number + $other_number; One major, MAJOR pet peeve I have wrt Javascript is that it uses + to mean concatenation as well as addition, and that it (like perl) allows scalars to contain strings or numbers. One is continually forced to jump through hoops to do simple arithmetic. User has entered a number -- ah, but it comes in as a string. Want to add 666 to it? You have to do this nonsense: $sum = $addend - 0 + 666; You constantly have to subtract zero in order to force a numeric context. Asinine. Whatever the final Perl 6 solution to string concatenation/addition is, don't let it become the ambiguous mess that Javascript is. My two cents. Thanks for listening. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Strings vs Numbers (Re: Tying Overloading)
On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote: Doesn't ~ look like a piece of string to you? :-) It looks like a bitwise op to me, personally. That's because every time you've used it in Perl, it's been a bitwise op. Sapir-Whorf, and all that. -- So what if I have a fertile brain? Fertilizer happens. -- Larry Wall in [EMAIL PROTECTED]
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote: On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote: Doesn't ~ look like a piece of string to you? :-) It looks like a bitwise op to me, personally. That's because every time you've used it in Perl, it's been a bitwise op. Sapir-Whorf, and all that. Not just Perl. Many other languages use ~ the same as Perl does now. Graham.
