Re: Properties and stricture and capabilities
On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote: > > Symbol table manipulation will work as long as your mucking about > > doesn't alter the strict class's signature. ie. you can shove a code > > ref onto the symbol table as long as a stub for that method was > > defined at compile time. > > a read-only hash of any kind makes it more safe > > we could overload C to make a hash read-only This makes about as much sense as using keys() as a cryptographic operator. > That would prevent further shoving of anything onto the symbol table > without "proper authorization" as defined by holding the capability. Getting into details about this doesn't make much sense as we don't yet know what the new symbol table interface will look like. -- Michael G Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
it is perl5 but...
~/perl/perl-5.7.1$ ./perl -le '%a=(1..10); print it; exists $a{1} and print
it'
2
--
David Nicol 816.235.1187
The toad doesn't know it has ten toes.
Re: hash and array variables vs. references
On Fri, 8 Jun 2001 14:05:44 -0400, Mark J. Reed wrote:
>My question/suggestion: why not get rid of @arrays and %hashes as
>separate variable types? Have all variables be scalar - with,
>of course, the ability to hold a reference to an anonymous array
>or hash. Keep the funny characters around, but only as dereference
>operators - and let @foo be equivalent to @$foo and %bar to %$bar.
>That would bring back the relationship between @foo/$foo[$i]
>and %bar/$bar{$key} and would also let the Perl5 slice notation
>stay intact.
This looks like the idea of Highlander variables to me -- so called
after the movie Highlander: "There Can Be Only One". That will be RFC 9.
--
Bart.
Re: hash and array variables vs. references
> > I have done a quick scan of the archives for a > > discussion on this topic and didn't see it; if I > > just missed it, I'd appreciate it if someone > > could send me a link to the thread or > > applicable RFC[s]. Futhermore, this is still a topic of active discussion, so just stay tuned. -- John Porter
suggested properties of operator results
Currently, this expression:
VALUE1 < VALUE2
is functionally equivalent to this:
$v2 = VALUE2;
$v1 = VALUE1;
return ($v2-$v1 == abs($v2-$v1));
After reading the Apocalypse & Exegesis articles, and seeing some examples
of properties and the "is" operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to "left") would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo < $bar < $baz) { ... }
It should be obvious how "> <= >= lt gt le ge" can similarly
be modified. Then even this would make sense...
if ($foo <= $bar > $yak lt $wak) { ... }
"== != eq ne" could be similarly modified (with the addition of a valueL
property to deal with precedence) but I haven't convinced myself it's a
good idea -- too many people like using == in place of xor...
if (($foo < $bar) == ($yak < wak)) { ... }
(I haven't even begun to consider <=> and cmp, but I'm sure there's
someone smarter then me out there with an idea on how/why they could
be modified as well (if for no other reason then to make obfuscated perl
contests even more interesting))
--
---
"Oh, you're a tricky one."Chris M Hostetter
-- Trisha Weir[EMAIL PROTECTED]
Re: hash and array variables vs. references
> I have done a quick scan of the archives for a > discussion on this topic and didn't see it; if I > just missed it, I'd appreciate it if someone > could send me a link to the thread or > applicable RFC[s]. I suspect you didn't use the all search, right? Just in case: http://www.mail-archive.com/perl6-all%40perl.org/ Happy hunting (there's LOTS on your chosen topic). (I posted to the list in case anyone else reading it doesn't know about the all search.)
hash and array variables vs. references
I'm sure this has been brought up before, but I'm a latecomer who
didn't see anything on the Perl6 design until the first Apocalypse.
I apologize for the redundancy. I have done a quick scan of the
archives for a discussion on this topic and didn't see it; if I
just missed it, I'd appreciate it if someone could send me a link
to the thread or applicable RFC[s].
My question/suggestion: why not get rid of @arrays and %hashes as
separate variable types? Have all variables be scalar - with,
of course, the ability to hold a reference to an anonymous array
or hash. Keep the funny characters around, but only as dereference
operators - and let @foo be equivalent to @$foo and %bar to %$bar.
That would bring back the relationship between @foo/$foo[$i]
and %bar/$bar{$key} and would also let the Perl5 slice notation
stay intact.
I appreciate any comments (new or old). Thank you for your time.
--
Mark J. REED<[EMAIL PROTECTED]>
