Re: Properties and stricture
"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs. No dynamic inheritance. No autoloading. No
> > dynamic method calls. No symbol table manipulation. No eval. No
> > automatic method generation. (That's off the top of my head).
>
> You don't loose all of these. Java has interfaces, and then any
> class, even loaded at compile time, that satisfies an interface is
> allowed to be used in its place. This is as good as subroutine refs
> (and in general object refs) that are checked at compile time, but
> where the implementation shows up at run time.
Um... how is this as good as a subroutine reference? I confess that I
fail to see it.
You do realise that not having subroutine references kills all sorts
of useful stuff. Apache::Registry springs to mind.
> Dynamic inheritance, is that messing with the inheritance tree at
> runtime? I've never found a need for that. I think a lot of these
> features are just bad habits that people may use but they don't
> realize that they don't really need (like computd gotos). I've never
> used that, if I'm understanding you.
Dynamic inheritance is definitely scary. Fun, but scary. Using it in
production code would definitely be scary. Then again, having a state
token which you rebless to change the state has some good stuff going
for it...
> Java allows you to load classes at runtime. The interface /
> implementation matching is checked then. No, you can't do many of
> the tricks that you can in Perl, like having autoload implement
> methods for you that don't really exist lexically, etc. Again, this
> would only not be allowed in "strict-type-checking". So, you give it
> up only if you want to.
Hopefully, with strict-type-checking on you'd be able to predeclare
subroutines that are implemented via AUTOLOAD:
sub foo ();
> Not sure what a dynamic method call is. Virtual method calls,
> perhaps? Java has these.
What's a 'virtual method call'?
A dynamic method call looks something like:
my $method = compute_methodname(@_);
$object->$method();
Remarkably useful sometimes.
> Symbol table manipulation is for me another "computed goto"
> something I don't think I'll ever want. Again, you only give it up
> in the special mode.
You never use a modules that use the Exporter? Wow. Or wrote an
AUTOLOAD that loaded deferred methods into the module symbol table?
> No eval of strings, you mean. eval of blocks is fine: eval {}; if
> ($@) { etc.}. Eval of strings seems like a very local thing that I
> would rarely want to eval large chunks of code in. Perhaps it could
> throw a "type checking failed" exception that you could catch
> outside the eval.
No eval of strings kills things like the Template Toolkit (Assuming it
hasn't been killed big time by the 'no subroutine refs' thing...),
which definitely evals 'large chunks of code' within strings.
> Automatic method generation. Again, never found the need, and you
> only give it up if you want to.
Personally I reckon that having Automatic method generation is *way*
better than violating the DRY principle to build a maze of twisty
little accessor methods, all different.
> > Every class in the hierarchy has to be defined and loaded
> > completely at compile time (well, at least their method
> > signatures) and defined strictly. If there's a class which isn't
> > strictly defined anywhere in your hierarchy, no go.
>
> Yes, that's the point.
Hmm... I think you just killed mod_perl.
> > Also, since you're doing so much more work at compile time, any
> > strictly typed code will probably have to be pre-compiled or else
> > be sluggish to startup (this is just a guess).
>
> Again, for large applications, one expects them to be pre-compiled.
Does one? Are you using perl for large applications? I am and they're
definitely not precompiled.
> > An optional strict typing system would be nice, but I just want
> > you to be aware how difficult it will be to do right, and what you
> > give up by using it. This isn't just a "let's toss this in" sort
> > of feature.
>
> Yes, its not easy to do right, and it is very helpful. Certainly
> worth it in my opinion.
The system you proposed doesn't appear to be doing it right. Too many
babies get thrown out with the bath water. I love the compile time
optimization possibilities that come with static type checking, but
there has to be some way of allowing us keep Perl's flexibility whilst
still seeing some of those gains.
Personally, what I'd like to see is a system that does as much type
based optimization as it can at compile time. If dangerous ops happen
later that could affect all the optimizations, then the various
optimization caches (yeah, I'm being *very* fuzzy here, I'm not
enormously up on the technology so let me wave my hands a bit)
affected need to get flushed and perl has to go back to doing things
the old, slow way.
However, I would hope that some optimizations will be of the
'calculate once, use many' typ
Re: Properties and stricture
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Consider the following... Foo is a poster-child for a strict class.
> Everything is predeclared and typed. Its entire hierarchy is rock
> solid. Someone uses Foo in their script and calls Foo->bar. They
> also use Bar, a module you installed a long time ago. Bar does this:
>
> package Bar;
> eval "sub Foo::bar { 23 }";
>
> Oh crap! All the wonderful compile-time checking we did on Foo has
> just been blown to pieces.
Well, if Damian's suggestions for strict classes in perl 5+i becomes
anything more than fiction then that eval will throw an exception.
--
Piers Cawley
www.iterative-software.com
Re: Properties and stricture
Michael G Schwern wrote: > It will have to go for strict classes. @ISA will have to be locked. "strict classes"? > my $meth = "foo"; > $obj->$meth(); # $obj->foo(); > > This definately can't work if $obj is of a class which is strongly > typed. "strongly typed class"? > This can still work with strong typing if: > 1) The class only plays with its own symbol table > 2) It does it at compile time. I agree that an (optional) strong-typing mechanism would be nice to have in perl6. However, I don't think it should not have a run-time component. I.e. "strong typing can only be done at compile time". We'll do what we can at compile time, but this is Perl... -- John Porter
Coupla Questions
I've been working on, uh, let's call it a "Perl 6 emulator" recently,
and I've come unstuck about a few things.
I'm sure I'll think of some more questions, but here we go for now:
Should properties interpolate in regular expressions? (and/or strings) I
don't suppose they should, because we don't expect subroutines to.
(if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)
What should $foo = (1,2,3) do now? Should it be the same as what
$foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
$foo = \@INC; does now.) Putting it another way: does a list in scalar
context turn into a reference, or is it just arrays that do that? If
so, how can we disambiguate hashes from lists?
Currently I have:
% ./perl -l
printf "This is Perl version %vd\n", $^V;
%foo = (test=>"ok 1", test2=>"ok 3");
print %foo{test};
print "ok 2" if ref ($a=%foo);
print $a->{test2};
print "ok 4" if ref @INC;
print "ok 5" unless ref ($a=(1,2,3))'
This is Perl version 6.0.0
ok 1
ok 2
ok 3
ok 4
ok 5
Does that look right?
--
Every little bit of seaweed kelps.
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote:
> print $a->{test2};
Oh, hrm. Shouldn't it be $a{test2}? That works too, at any rate.
Does that mean that arrow between variable and subscript is optional,
or should this be some kind of error? Or should it mean something else
altogether?
--
It starts like fascination, it ends up like a trance
You've gotta use your imagination on some of that magazine romance
And these bones--they don't look so good to me
Jokers talk and they all disagree
One day soon, I will laugh right in the face of the poison moon
Re: Properties and stricture
> [strict typing] > > Not a negative, but realize that many people find it > of less value than the annoyances it brings with it > (myself included) Michael, I don't know which is more impressive; the fact that use of a strictly typed language implies that a copy of you would land on the poor unsuspecting programmer's desk, or that you are self-deprecating enough to acknowledge that this would probably be an annoyance (at least in the first seconds or so prior to recognition of the rather cool magic involved). > > It could work in perl when perl is being used in an > > FP manner; that would indeed be very Perlish. > > Yes! That would be a magic trick I'd love to see. Indeed.
Re: 1 until defined(getvalue()); return $^d;
Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of C as a shorthand for the thing that last
had C or C queried of it.
It (by which I mean C, isn't this fun) would be a side-effect of
non-autovivifying queries. It allows redundant descents into arbitrarily
complex data structures to be optimized out.
A new bareword is too heavy an invasion of this idea into the language:
a new LNV is preferable. C could alias $^d and $^e to
C<$DEFINED_TARGET> and C<$EXISTS_TARGET>, respectively. Autoviv would be
deferred until ond of them gets assigned to.
Damian Conway wrote:
>
> David wrote:
>
>>defined $thing and return $thing
>
> Why not use the existing mechanism? Namely:
>
> return $_ for grep{defined} $thing;
although meeting the specified criteria of looking $thing up
once, this is a confusing hack that might not save any cycles.
Setting up the C construct and reassigning C<$_> might be
longer than referring to a defined-specific magic variable.
> which also scales rather nicely:
>
> return $_ for grep{defined} $thing, $otherthing, $somethingelse;
This does not help in the case of a long, unrolled routine which is to
return the first sensible parse of something. Although with a
short-circuiting
grep this would work, and be a nice controlling abstraction too.
> As for the original problem of:
>
> 1 until defined(getvalue()); return it;
>
> You can already write:
>
> 1 until defined($_=getvalue()); return $_;
>
> which doesn't seem a huge extra burden.
I want the assignment done behind-the-scenes, rather
than by explicit programmer action.
I hereby revise my proposal from a bareword to a Line Noise Variable,
so that this interesting but rarely used feature, like other similar ones,
for instance $?.
Re: 1 until defined(getvalue()); return $^d;
On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote: > this is a confusing hack that might not save any cycles. Please don't try defending "it" or "$^d" in terms of efficiency; any variable that Perl has to keep track of magically takes a performance hit. Remember $`, $', and $&? -- You advocate a lot of egg sucking but you're not very forthcoming with the eggs. - Phil Winterbottom (to ken)
Re: Coupla Questions
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we need m//e)
Err. I *would* expect sub call iterpolation in regexes, since they will
interpolate in qq{...} contexts, and that's what a regex basically is.
But what you showed is not the syntax for it:
/bar($baz,$quux)/; # match bar then match-and capture
# matches of interpolated value of $baz,
# a comma, interpolated value of $quux
/&bar($baz,$quux)/;# match interpolated value of call to
# bar with two args
> What should $foo = (1,2,3) do now? Should it be the same as what
> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
> $foo = \@INC; does now.) Putting it another way: does a list in scalar
> context turn into a reference, or is it just arrays that do that?
Just arrays, I believe.
> Currently I have:
>
> % ./perl -l
> printf "This is Perl version %vd\n", $^V;
> %foo = (test=>"ok 1", test2=>"ok 3");
> print %foo{test};
Yes
> print "ok 2" if ref ($a=%foo);
Yes. Though C would be a better test
> print $a->{test2};
die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"
> print "ok 4" if ref @INC;
Yes
> print "ok 5" unless ref ($a=(1,2,3))'
No. Equivalent to ref($a=3), I believe
> Does that look right?
60% right, at least. ;-)
> > print $a->{test2};
>
> Oh, hrm. Shouldn't it be $a{test2}?
Yes. Or $a.{test}
> That works too, at any rate.
> Does that mean that arrow between variable and subscript is optional,
There is no arrow. Only dot.
And yes, it's optional anywhere the dot acts like a /\b/ boundary:
$ref.[1]can be $ref[1]
$ref.{a}can be $ref{a}
$ref.(@args)can be $ref(@args)
$ref.meth() CAN'T be$refmeth()
Disclaimer: Rules #1 and #2 apply to all of the above.
Damian
Re: Coupla Questions
Thanks *very* much for your answers; I still have a lot of work left
to do, it seems. But I'm still a little confused:
On Thu, Jun 07, 2001 at 06:08:23AM +1000, Damian Conway wrote:
>> Should properties interpolate in regular expressions? (and/or strings)
> Do you mean property look-ups via the pseudo-method syntax?
> In that case, yes they should
So, to match $foo's colour against $bar, I'd say
$bar =~ /$foo.colour/;
Great, but how do I match $foo followed by any character followed by the
literal "colour"? Would I have to use "\Q"?
> Err. I *would* expect sub call iterpolation in regexes, since they will
> interpolate in qq{...} contexts, and that's what a regex basically is.
Fair enough.
> /&bar($baz,$quux)/; # match interpolated value of call to
Ah, good. Much easier to parse.
> Just arrays, I believe.
Good, that's what was planning on.
>> print $a->{test2};
> die "Unexpected > after subtraction operation. Did you mean $a.{test2}???"
Urgh. OK, arrow is dead. That also makes things easier. Probably.
>> print "ok 5" unless ref ($a=(1,2,3))'
^^
> No. Equivalent to ref($a=3), I believe
Since ref($a=3) is undef, that should print "ok 5".
>> Oh, hrm. Shouldn't it be $a{test2}?
> Yes. Or $a.{test}
So "." isn't necessarily the "property" operator, then? OK.
Time to spend more quality time with YACC. :(
--
"If you want to travel around the world and be invited to speak at a lot
of different places, just write a Unix operating system."
(By Linus Torvalds)
Re: Coupla Questions
> So, to match $foo's colour against $bar, I'd say
>
> $bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
> Great, but how do I match $foo followed by any character followed by the
> literal "colour"?
$bar =~ /$foo.colour/;
> Would I have to use "\Q"?
No. You could use the $(...) scalar interpolator instead:
$bar =~ /$($foo).colour/;
> >> print "ok 5" unless ref ($a=(1,2,3))'
> ^^
Sorry, in my haste I missed that twist. You are, of course, correct.
> >> Oh, hrm. Shouldn't it be $a{test2}?
> > Yes. Or $a.{test}
>
> So "." isn't necessarily the "property" operator, then? OK.
> Time to spend more quality time with YACC. :(
Now there's an oxymoron, if ever I heard one. ;-)
Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote: > >> So, to match $foo's colour against $bar, I'd say >> >> $bar =~ /$foo.colour/; > > No, you need the sub call parens as well: > > $bar =~ /$foo.colour()/; Hm, I thought Larry said you would need to use $() to interpolate a method call. So this would be $bar =~ /$($foo.colour)/; Graham.
Re: Coupla Questions
> >> So, to match $foo's colour against $bar, I'd say > >> > >> $bar =~ /$foo.colour/; > > > > No, you need the sub call parens as well: > > > > $bar =~ /$foo.colour()/; > > Hm, I thought Larry said you would need to use $() to interpolate > a method call. So this would be > > $bar =~ /$($foo.colour)/; That was not my understanding. At least not for (pseudo-)method calls. But many things are still in flux and I may well have missed a meeting. ;-) Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote: > >> >> So, to match $foo's colour against $bar, I'd say >> >> >> >> $bar =~ /$foo.colour/; >> > >> > No, you need the sub call parens as well: >> > >> > $bar =~ /$foo.colour()/; >> >> Hm, I thought Larry said you would need to use $() to interpolate >> a method call. So this would be >> >> $bar =~ /$($foo.colour)/; > > That was not my understanding. At least not for (pseudo-)method calls. But with the above you still have abiguity, for example what does this do $bar =~ /$foo.colour($xyz)/; I may be remembering about interpolation into strings as "$file.ext" is going to be common. But I do think the $() approach is clean and unambiguous Graham.
Re: Coupla Questions
> But with the above you still have abiguity, for example what does this do > > $bar =~ /$foo.colour($xyz)/; "Looks like a method call with parens, so *is* a method call with parens." > I may be remembering about interpolation into strings as "$file.ext" is > going to be common. But I do think the $() approach is clean and > unambiguous I agree wholeheartedly. But it's not as *convenient* as "unadorned" interpolation. Expecially if we expect method calls to be frequently interpolated. Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: >> But with the above you still have abiguity, for example what does this do >> >> $bar =~ /$foo.colour($xyz)/; > > "Looks like a method call with parens, so *is* a method call with parens." > > >> I may be remembering about interpolation into strings as "$file.ext" is >> going to be common. But I do think the $() approach is clean and >> unambiguous > > I agree wholeheartedly. Good. > But it's not as *convenient* as "unadorned" interpolation. Sometimes convenient has to give way > Expecially if we expect method calls to be frequently interpolated. I don't hear people screaming because it's difficult in perl5, so I doubt it will be very frequent. But even the $() is easier than the current perl5 way to do it. Graham.
Re: Coupla Questions
> > But it's not as *convenient* as "unadorned" interpolation.
>
> Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
> > Expecially if we expect method calls to be frequently interpolated.
>
> I don't hear people screaming because it's difficult in perl5,
Mainly because they use /$var->{raw_attribute}/, which we want to discourage.
And which won't be available on opaque objects.
> so I doubt it will be very frequent.
Perl 6's interface is likely to be far more OO than Perl 5's, so this may not
be the case. For example: Perl 5's $#array syntax becomes something
like @array.length (i.e. a method call)
> But even the $() is easier than the current perl5 way to do it.
There we definitely do agree :-)
Damian
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: > But it's not as *convenient* as "unadorned" interpolation. Disagree. "Adorning" a piece of syntax reminds the programmer that something out of the ordinary is happening. It's a mental speed limit sign - a traffic light, if you like - that forces you to slow down to work out what's really going on. Briefly: Complicated syntax is a GOOD THING for complicated semantics. /foo.$bar.baz/can be accidentally speed-read as /foo.bar.baz/ /foo.$($bar.baz)/ means "Uhoh, something's going on". -- Premature optimization is the root of all evil. -- D.E. Knuth
Re: Coupla Questions
[EMAIL PROTECTED] writes: :> What should $foo = (1,2,3) do now? Should it be the same as what :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what :> $foo = \@INC; does now.) Putting it another way: does a list in scalar :> context turn into a reference, or is it just arrays that do that? : : Just arrays, I believe. That hasn't actually been decided yet. There are good arguments on both sides. Larry
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote: > [EMAIL PROTECTED] writes: > :> What should $foo = (1,2,3) do now? Should it be the same as what > :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what > :> $foo = \@INC; does now.) Putting it another way: does a list in scalar > :> context turn into a reference, or is it just arrays that do that? > : > : Just arrays, I believe. > > That hasn't actually been decided yet. There are good arguments on > both sides. Can someone post a few ? I am open to what are the pros/cons but right now my mind is thinking " Whats the benefit of making $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something different, ie what it does in perl5" Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: > Can someone post a few ? I am open to what are the pros/cons > but right now my mind is thinking " Whats the benefit of making > $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something > different, ie what it does in perl5" A reason against making the behaviours ($foo=array vs. $foo=list) different would be that you're then making lists and arrays more distinct than necessary. Does this make $foo a reference, or the number of elements: $foo = (@bar=(1,2,3)); or this: $foo = @bar = (1,2,3); But on the other hand, what about? $foo = (1,2,3); @bar = (1,2,3); $foo = @bar; # Array in scalar context, so ref? @bar = (1,2,3); $foo = (@bar); # "List" in scalar context, so number? ($foo) = @bar; # Array in list context, ...? ($foo) = (@bar); # List in list context, ...? But then, what does this do? $foo = (3, 4, @bar, 5); Is the 2nd element treated as a "scalar context", so you get a reference to @bar in there, or does list flattening still apply? See, if you make $a=(1,2,3) take a reference just like $a=[1,2,3], this frees up [] for something else. You could have () for flattening and [] for non-flattening lists. (Something somehow seems LISP-like about that idea, but it's been too long...) So that's an argument for, uh, something me going to sleep, I think. Oh, one last thing: is $a = @foo; # Perl 6 equivalent to $a = [ @foo ]; # Makes a copy or $a = \@foo; # Takes a direct reference ? The former extends to lists, the latter doesn't. -- I don't understand how people can think SCSI is anything more quirky than a genius with peculiar dietary requirements in a world where the creators of Notes, and their new owners, are allowed to walk the streets without fearing for their very lives. - Graham Reed, asr
Re: 1 until defined(getvalue()); return $^d;
Simon Cozens wrote: > Please don't try defending "it" or "$^d" in terms of efficiency; > any variable that Perl has to keep track of magically takes a > performance hit. Remember $`, $', and $&? No, this datum is already known by defined() and exists() all I am suggesting is a name for the Perl API name for it. Well, it isn't currently in 5.6.1's bool Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen) function (contrary to what John Porter said) but adding it, as extended defined/exists that Only Gets Called When It Immediately And Obviously Precedes Use Of The Magic Variable, would save the later lookups. This is a "Little thing that can just be thrown in" and is nothing more than that. Making $', $`, and $& lexically scoped too could solve their performance hit issues too. They're convenient.
Re: Coupla Questions
Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo = \@INC; does now.) Putting it another way: does a list in
scalar
>> :> context turn into a reference, or is it just arrays that do that?
>> :
>> : Just arrays, I believe.
>>
>> That hasn't actually been decided yet. There are good arguments on
>> both sides.
>
>Can someone post a few ? I am open to what are the pros/cons
>but right now my mind is thinking " Whats the benefit of making
>$a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
>different, ie what it does in perl5"
I'm wondering if () should keep its functionality as a list composer at all.
Perhaps it should just be:
$foo=($a, $b); #$foo is equal to $b
$foo=[$a, $b]; #$foo is an array ref
$foo={$a, $b}; #$foo is a hash ref
@foo=($a, $b); #same as @foo=$b (what would that do?)
@foo=[$a, $b]; #@foo is an array containing $a and $b
@foo={$a, $b}; #@foo is an array containing $a, '', $b, '' (?)
%foo=($a, $b); #same as %foo=$b (what would that do?)
%foo=[$a, $b]; #%foo is a hash containing $a => $b (?)
%foo={$a, $b}; #%foo is a hash containg $a => '', $b => '' (?)
Thus,
($a, $b)=($c, $d); #$b=$d
[$a, $b]=[$c, $d]; #$a=$c; $b=$d; (except inline)
{$a, $b}={$c, $d}; # ???
This means that each of the wraparound things has exactly one meaning,
regardless of context. It also gives () back its C meaning, grouping stuff
together so it'll be evaluated first, instead of a meaning that can be
different in different contexts. (In general, I think that "syntactic
operators" like parenthesis and comma should behave the same regardless of
scalar/list context, while functions should behave differently. That's just
my bias, though. Feel free to laugh at me if I'm wrong here.)
--Brent Dax
[EMAIL PROTECTED]
Re: Coupla Questions
Damian Conway wrote:
> $ref.{a}can be $ref{a}
which can also be
$ref.a
can it not?
Re: Properties and stricture
Me wrote: > > > [strict typing] > > > > Not a negative, but realize that many people find it > > of less value than the annoyances it brings with it > > (myself included) > > Michael, I don't know which is more impressive; the > fact that use of a strictly typed language implies that > a copy of you would land on the poor unsuspecting > programmer's desk, or that you are self-deprecating > enough to acknowledge that this would probably be > an annoyance (at least in the first seconds or so > prior to recognition of the rather cool magic involved). Me: Oh please. If it makes no sense one way, reparse. I had no trouble at all binding Michael's "myself" into "many people" and neither did you, unless someone has recently lobotomized you with a guitar pick. OTOH, you may have been making a point about strict syntax-based parsing, in which case I may be in a minority in misperceiving your post as the worst case of smartassery I've seen this month.
"closed" property ((was Re: $foo.Foun ((was Re: Properties and stricture
Me wrote:
> I.Found your notion of a "sealed off namespace"
> intriguing. I have no idea what it meant just yet;
> I'm going to go read and think about it now.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow it like so:
%reflexive:: is not closed;
# determine its status like so:
unless (is closed %reflexive::) {
# add the subs
...
The above is modulo a new syntax for referring to a package's
symbol table.
What would be the limits on who or what would be allowed to open
a regular hash, that was made read-only by giving it a "closed"
property? This would need to be well defined. Possibly an
openswith property could be taken from a hash, before it is closed,
which could be invoked to open it again, by accessing the "open"
property while it is open.
my %SMERSH_agent_identities = sreadfile('identities/SMERSH.sd');
swallow(my $agent_list_mod_key = (is open %SMERSH_agent_identities);)
%SMERSH_agent_identities is closed;
Mallory can't defame a good agent by modifying this list of bad
agents without setting it to not closed, he can't do that without
getting the key, and the key has been swallowed (whatever that means.)
Even more compact would be the setting to closed returning the capability.
package reflexive;
# prevent modification to %reflexive:: like so:
my $opener = (%reflexive:: is closed);
# re-allow modification like so:
&$opener;
--
David Nicol 816.235.1187
Keep Dan Sugalski away from my stuffed animals
Re: $foo.Foun (was Re: Properties and stricture)
Me wrote:
>
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
>
> Right?
it is already detectable. from perldoc perlref:
Perl will raise an exception if you try to access
nonexistent fields. To avoid inconsistencies, always use
the fields::phash() function provided by the "fields"
pragma.
Although other discussion in the thread indicates that we may
be confusing properties and member fields.
as I understand it, .foo has been proposed to replace ->{foo} and
we're talking about fields, not properties.
Property access has got to be something else. Last year's code pitched
to the perl6-data list generally used a colon for that; use of "is" as the
property assignment operator invites and suggests
$foun_status_of_foo = (is $foo foun);
to access the status of the foun property of foo, should such exist and be
defined
et cetera. Maybe there will be a distinction between notexist and notdef.
I know the
SQL people want an explicit "unknown" value.
And we're in blue sky territory for the stricture.
--
David Nicol 816.235.1187
Keep Dan Sugalski away from my stuffed animals
Re: Coupla Questions
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote: > On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: > > Can someone post a few ? I am open to what are the pros/cons > > but right now my mind is thinking " Whats the benefit of making > > $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something > > different, ie what it does in perl5" > > A reason against making the behaviours ($foo=array vs. $foo=list) > different would be that you're then making lists and arrays more > distinct than necessary. Does this make $foo a reference, or the number > of elements: But if you change () consider, how do you do $min = (localtime(time))[1]; and if () creates a reference what does $x = (1 + 2) * 3; it's still () in a scalar context. IIRC when Larry covered this, he did not suggest changing (), but changing the meaning of the , in the scalar context. () is a grouping contruct, not a list generator. Graham.
Re: 1 until defined(getvalue()); return $^d;
David L. Nicol wrote: > it isn't currently in 5.6.1's > > bool > Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen) > > function (contrary to what John Porter said) Huh? What did I say?:: -- John Porter
Re: $foo.Foun (was Re: Properties and stricture)
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thinking about Perl 6 was correct.
> Although other discussion in the thread indicates that
> we may be confusing properties and member fields.
My concern was user defined variable and value properties.
(Though part of my reason for that concern was that whatever
limits on stricture might apply to any one member of the joint
property and method namespace might also have to apply
to the others.)
> as I understand it, .foo has been proposed to replace ->{foo} and
> we're talking about fields, not properties.
>
> Property access has got to be something else.
If that's so, I am totally confused.
Re: Properties and stricture
On Tue, 5 Jun 2001, Michael G Schwern wrote: > On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote: > > I cannot imagine running an enterprise critical application > > As a complete digression, can we please strike the term "enterprise" > from the English lexicon? Completely redundant and drives me up the > wall. Almost as bad as "ecommerce". But if we did, how could we hope to get a good new Star Trek series? :> Dave
Re: $foo.Foun (was Re: Properties and stricture)
Damian Conway wrote: > I very much doubt Perl is going to become significantly more statically > analyzable in general. Though static determinacy is obviously a > desirable thing, there are plenty of other B&D Bondage and Discipline? > languages that offer it > in abundance. And the dynamic power that Perl would have to lose would not > compensate for the static benefits gained. > > Damian > > PS: Of course, as always, Larry's MMV on that ;-) Main Man Vote? One of the major features of Perl is that it can cross between "data" and "code" so easily (eval, inserting into the namespace at runtime, changing the inheritance tree at runtime, computed method calls, computed gotos, etc.). I knew this, but it is rather amazing how many different examples of this people used against my arguments for "strong" type checking at compile time. What about a trade-off between compile time checking and run time checking? I think everyone agrees that if something is going to fail, it is better for you to find this out sooner rather than later. Compile time is sooner, run time is later, and when the IRS audits a customer who's taxes were done wrong because of a subtle data corruption bug you never caught in testing is even later. Can we move the time when you catch the type failure error at least somewhat sooner, even if we can't get it all the way to compile time? Perl already has other intermediate "times". For example, the BEGIN block code is run during compile time. I suggest that for most programs you could "factor out" all of the data-to-program bits of your code (that prevent compile time checking) into an initial phase of your program. After that phase is ended (all the autoloading is done, inheritance tree modified, whatever) you run the "compile time" checker on your own program, perhaps giving it a set of sentences to verify, such as "This class/package is sealed". If there is a type failure, at least you get the error right then, before you tell the robot to pick up the car. Assertions are good for checking that *data* has properties I expect. If data can be come program (as in Perl), I want assertions that my *program* has properties I expect. For those of you who love code that manipulates its own internals, you can see such "assertions about the program" are a kind of introspection into your own parse tree. People have written compilers that first parse and then allow your custom plug-in to check properties of the parse tree. These "assertions about the program" could be implemented that way. First you call "parse", which is used just like the current "eval", but instead returns the parse tree. Then have your own routines traverse over the tree and verify any properties your heart desires. A few standard ones implementing, say, sealed classes, would of course show up on CPAN. This strategy would of course require a "parse" to produce a nice parse tree data structure, with all the compile time properties conveniently attached. It would also be nice if afterward, you could turn off some/all of the data-to-program features, like namespace manipulation. Daniel
Re: Coupla Questions
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> Damian Conway wrote:
> > $ref.{a}can be $ref{a}
> which can also be
> $ref.a
Dereferencing a hashref is the same as accessing a property?
I hope not.
--
Did you know that 1 barn yard atmosphere = 9.2e-17 erg?
Re: 1 until defined(getvalue()); return $^d;
On Wed, Jun 06, 2001 at 07:21:19PM -0500, David L. Nicol wrote: > No, this datum is already known by defined() and exists() all I > am suggesting is a name for the Perl API name for it. Sorry, I didn't read your original post thoroughly enough; yes, one for defined and exists would be feasible, but IMHO ultimately pointless. And you could probably do it in pure Perl anyway by overloading the ordinary defined and exists operators, so there isn't much need for it in the core. > Well, it isn't currently in 5.6.1's > bool > Perl_hv_exists(pTHX_ HV *hv, const char *key, U32 klen) Eh, you probably mean pp_exists, since exists doesn't just act on hashes. > Making $', $`, and $& lexically scoped too could solve their > performance hit issues too. They're convenient. Could it really? Have you tried to implement this? -- This week I will definitely have passed the Administrative Event Horizon: when you spend quite a few more hours doing silly corporate bullshite than anything remotely technical or to do with the administration of systems. - Red Drag Diva
