Re: Arrays: Default Values
Aaron Sherman wrote: On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote: Arrays (or hashes) don't grow on reading - never. But for less pure forms of reading: foo(@a[0]); auto-vivification will have to happen in some cases. e.g. if foo requires a lvalue parameter. A lvalue param is not strictly reading, but here has to happen something differently - yes: IMHO some sort of proxy could be passed here, saying: if you write to me, this will be at @a[0]. Or auto-vivify the entry. leo
What's core? (was Re: Arrays: is computed)
On Thursday, January 30, 2003, at 10:44 PM, Leopold Toetsch wrote: Michael Lazzaro wrote: [EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. If you want such 'is computed' thingy, then tie it or wrap it in your own - IMHO. Everyone seems to need different things, so the simplest and by far the safest way is to make this explicit in your code. Yep. Sigh. This is all quite frustrating, because everyone has different ideas on what's valuable enough to be a builtin, but it's the design team that finalizes that, and the information is sort of scattered piecemeal through the A's/E's/p6l. If you look around enough, there's a pile of builtin stuff that's obliquely referred to, but never quite spelled out. And even the simplest ones -- what default means, for example -- aren't necessarily obvious at first glance. All I want is a list of what the already-known builtins *are*, or what other things people *demand* should be there, and the gist of what they do. Even if I have to change it later. Even if they're not in core, but they're things that people are going to immediately build because they're so obvious. Something to make me feel that the precise behaviors have really been pinned down -- and can be reliably extrapolated from -- preferably *before* people spend a lot of time coding them. Lord, this is just *arrays*. Not even *hashes*, yet... So, is it obvious that I'm a little discouraged lately? Don't suppose anyone can come up with some numbingly inspirational words to cheer us (well, me) up... MikeL
summarizing the obvious (was: arrays, hashes unified ...)
From: Piers Cawley [mailto:[EMAIL PROTECTED]] Garrett Goebel [EMAIL PROTECTED] writes: $idx_of_foo = $queue['foo']; # named lookup $nth_foo= $queue[600]; # ordered lookup One is SvPOK the other SvIOK... Can't we handle both and still have the ordered lookup be fast? [...] YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As Dan pointed out ages ago. Got it. Conflating indexed and named lookups (creating a syntactic homonym), isn't desirable or reasonably feasible. If we went down that route, it'd wind up being more confusing, self-limiting, breed complexity in a response to resolve the over-simplification, and drag down performance. Or probably better left at not desirable. Or for the extremely thick: GOOD: Separate syntax for indexed vs. named lookups BAD: Same syntax with = 2 contextual meanings Apologies for revisiting the graveyard of bad ideas and contributing negatively to the signal to noise ratio. I too have great difficulty in keeping up with the list. For the most part, I tend to read the replies of the more enlightened to others' questions, comments, and proposals. How Damian, our most prolific, found the time to sift through so much I don't know. out-of-place-rant I'm disappointed that The Perl Foundation (TPF) has been so quiet and unresponsive on support for our core language designers and architects. I dropped a note to all the TPF contacts over a week ago, and have yet to receive a reply. It is a sad state of affairs when a language as prevalent as Perl and with such a strong sense of community can be so disorganized and lacking when it comes to financial sustenance. /out-of-place-rant
Re: summarizing the obvious
On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote: Or for the extremely thick: GOOD: Separate syntax for indexed vs. named lookups BAD: Same syntax with = 2 contextual meanings Seriously, everyone read Damian's Seven Deadly Sins thing, if ya haven't read/heard it already. It's quite short, and quite good at pointing out Things That Suck about programming languages. http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf out-of-place-rant I'm disappointed that The Perl Foundation (TPF) has been so quiet and unresponsive on support for our core language designers and architects. I dropped a note to all the TPF contacts over a week ago, and have yet to receive a reply. It is a sad state of affairs when a language as prevalent as Perl and with such a strong sense of community can be so disorganized and lacking when it comes to financial sustenance. /out-of-place-rant It's worse than that, IMO. Think of all the businesses that benefit from Perl... it's bloody *everywhere*. It's the, what, fourth most popular language, after C/C++/Java, according to that monster-job-search-based-statistic on slashdot. And yet the entire population of the Perl-using planet can't support 4 or 5 full time designers/developers? Have we just not been effective in getting the word out, or are businesses truly that cheap? Does Perl need to be made into a commercially supported product, w/ venture capital, a'la other recent open source pkgs, in order to get funded? MikeL
Re: Arrays: Default Values
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
A lvalue param is not strictly reading, but here has to happen something
differently - yes:
IMHO some sort of proxy could be passed here, saying: if you write to
me, this will be at @a[0]. Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
SV = PVLV(0x8177118) at 0x8166a74
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x816e7e0
MG_VIRTUAL = PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
TYPE = y
TARGOFF = 9
TARGLEN = 1
TARG = 0x817ad88
SV = PVAV(0x8183bd4) at 0x817ad88
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x0
FILL = -1
MAX = -1
ARYLEN = 0x0
FLAGS = (REAL)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
--
There's something wrong with our bloody ships today, Chatfield.
Admiral Beatty at the Battle of Jutland, 31st May 1916.
out-of-place-rant (was: summarizing the obvious)
Michael Lazzaro wrote: On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote: out-of-place-rant I'm disappointed that The Perl Foundation (TPF) has been so quiet and unresponsive on support for our core language designers and architects. I dropped a note to all the TPF contacts over a week ago, and have yet to receive a reply. It is a sad state of affairs when a language as prevalent as Perl and with such a strong sense of community can be so disorganized and lacking when it comes to financial sustenance. /out-of-place-rant It's worse than that, IMO. Think of all the businesses that benefit from Perl... it's bloody *everywhere*. It's the, what, fourth most popular language, after C/C++/Java, according to that monster-job-search-based-statistic on slashdot. And yet the entire population of the Perl-using planet can't support 4 or 5 full time designers/developers? Have we just not been effective in getting the word out, or are businesses truly that cheap? Does Perl need to be made into a commercially supported product, w/ venture capital, a'la other recent open source pkgs, in order to get funded? Don't forget giving credit where credit is due. YetAnother has accomplished a good deal. I don't understand the current relative silence, but they did setup and administer The Perl Foundation (TPF). Quite a number of companies and individual did fund TPF's 2002 grants (http://donate.perl-foundation.org/index.pl?node=Fund+Drive+Detailsselfund= 2). O'Reilly and ActiveState have for a long time employeed a substantial number of people who spend a significant amount of time improving Perl. And don't forget the folks and hardware donations behind CPAN. There are doubtlessly many other organizations which support people like ValueClick has Ask. I just don't follow the lack of active and organized financial support for Perl6... I may not have the time, knowledge, and ability to contribute much to Perl6 language design or Parrot. But, point me where I can send a check that'll support Larry, Damian, and Dan. That for the moment, I can still manage... I'll shut up now. No need to mention that this belongs on advocacy. -- 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: What's core? (was Re: Arrays: is computed)
--- Michael Lazzaro [EMAIL PROTECTED] wrote: So, is it obvious that I'm a little discouraged lately? Don't suppose anyone can come up with some numbingly inspirational words to cheer us (well, me) up... Go us.
Re: Arrays: Default Values
Dave Mitchell wrote:
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
IMHO some sort of proxy could be passed here, saying: if you write to
me, this will be at @a[0]. Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
Ah, same idea ;-)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
It's probably not too complex, it's IMHO the same, what we would need to
implement the multi_keyed opcodes like:
@a[$x] = @b{$y} - @c[2;$i]
We can't implement all the opcodes per se, this would need ~64K ops, so
one of my proposals (some time ago) was, to split this operation in 3
keyed fetch ops and one plain subtraction. The LHS whould need - as I
can set it now - a very similar treatment like above's example.
To come back to the array example:
- when the sub param is ro, you said it, no autovifiy should happen
- for rw (the default?) there is always a chance, that no write will
occur, and for the case nothing gets written, we have a volatile PMC
(the proxy) collected with the next DOD run. With autovivification we
create an anchored value, that is more expensive.
A (of course) constructed example could check in a subroutine, if
one/some/all elements exist
sub e() {return exists shift;}
for ([EMAIL PROTECTED]) - $i { do_some($i) if e($a[$i]); }
# modulo syntax, operator and other errs :)
And, from DWIM POV, autovivification was not the clearest things in the
docs, when it could happen or not. I would just expect: when I don't set
this very elememt in this array, why is something there.
leo
