Re: Does this mean we get Ruby/CLU-style iterators?
On Fri, Jan 18, 2002 at 08:03:41PM -0800, Larry Wall wrote:
: allow this:
:
: File.foreach('/usr/dict/words') { print }
File.foreach('/usr/dict/words', { print })
or even (presuming the prototype is available for parsing):
File.foreach '/usr/dict/words' { print }
Now I'm a little confused. The apoc talked about writing your own
while loop. A while loop looks like:
while($something) { do_this }
and a custom while loop would have to be
mywhile($something) { do_this }
and it doesn't seem much of a stretch for
Class.method($something) { do_this }
or is that what you ment by ignoring parser issues?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death was thought to be fatal.
-- Craig A. Berry in a05101002b8165afc6b62@[172.16.52.1]
Perl 6, now with 50% more NATO!
This just popped up from my sig file:
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
which, of course, we'll have in Perl 6:
loop {
.search .DESTROY;
}
Larry Wall: puppet of the military-industrial complex? Next on The
Conspiracy Zone. ;)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
MERV GRIFFIN!
Does this mean we get Ruby/CLU-style iterators?
Reading this in Apoc 4
sub mywhile ($keyword, condition, block) {
my $l = $keyword.label;
while (condition()) {
block();
CATCH {
my $t = $!.tag;
when X::Control::next { die if $t $t ne $l); next }
when X::Control::last { die if $t $t ne $l); last }
when X::Control::redo { die if $t $t ne $l); redo }
}
}
}
Implies to me:
A foo prototype means you can have a bare block anywhere in the
arg list (unlike the perl5 syntax).
Calling foo() does *not* effect the callstack, otherwise the
above would not properly emulate a while loop.
If that's true, can pull off my custom iterators?
http:[EMAIL PROTECTED]/msg08343.html
Will this:
class File;
sub foreach ($file, block) {
# yeah, I know. The RFC was all about exceptions and I'm
# not using them in this example.
open(FILE, $file) || die $!;
while(FILE) {
block();
}
close FILE;
}
allow this:
File.foreach('/usr/dict/words') { print }
or would the prototype be (file, block)?
And would this:
my $caller = caller;
File.foreach('/usr/dict/words') {
print $caller eq caller ? ok : not ok
}
be ok or not ok? It has to be ok if mywhile is going to emulate a
while loop.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
navy ritual:
first caulk the boards of the deck,
then plug up my ass.
-- japhy
Re: Ex4, Apo5, when ?
On Fri, Jan 18, 2002 at 03:35:59PM -0500, Dan Sugalski wrote: At 10:16 AM +0200 1/18/02, raptor wrote: Did u passed Bermuda Triangle :) It may be a bit before Ex4 is done. Damian's on a cruise ship at the moment, so even if he's got the time (and I don't think he does) he's likely lacking connectivity. I expect he'll give us word at some point what the schedule is. They've got connectivity all right. We've been getting plenty of drunken ramblings on IRC from folks on the cruise. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Your average appeasement engineer is about as clued-up on computers as the average computer hacker is about B.O. -- BOFH
Re: Perl 6's Exporter
On Mon, Dec 24, 2001 at 01:11:21PM +, Nicholas Clark wrote:
4. For modules, saying 'use Exporter' should be enough to get import.
If you don't want Exporter's import(), just Cuse Exporter().
Very nice. Exporter::Lite does just that.
What actually stops us retrofitting that onto perl5's exporter?
If we did everyone would still say @ISA = qw(Exporter) to be
backwards compatible, so I don't know what the benefits would be.
Also it would cause subroutine redefined warnings in this sort of
code:
use Exporter;
sub import {
...
Exporter::export_to_level(...);
}
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
Re: Perl 6's Exporter
I've rearranged the proposed features a bit to put the long objections
at the bottom.
Brent Dax wrote:
I've been thinking about improvements that could be made to Exporter for
Perl 6.
3. Warnings about conflicts:
use warnings 'Exporter';
sub Dumper { ... }
use Data::Dumper qw(Dumper);
#prints out a warning (not just 'redefined subroutine', either).
This would be nice. In fact, it could be retrofitted onto perl5's
Exporter.
4. For modules, saying 'use Exporter' should be enough to get import.
If you don't want Exporter's import(), just Cuse Exporter().
Very nice. Exporter::Lite does just that.
5. In addition to @EXPORT/@EXPORT_OK/%EXPORT_TAGS, provide a way to do
it on the 'use Exporter' line.
Getting rid of the @EXPORT* variables entirely would simplify both the
interface and the internals. Exporter could then do a lot more
caching and pre-calculating than it does now since it doesn't have to
worry Did they alter @EXPORT since the last time import() was
called?
However, shoving everything onto the use line seems of somewhat
dubious use. For starters, how do you say don't export import() and
export these variables please at the same time? You start getting
into special dont_export flags.
Why not just a regular function or method?
1. Choosing where to export to:
use Data::Dumper 'Dumper' = 'dumpvar';
#exports Data::Dumper::Dumper to Main::dumpvar (or whatever)
2. Built-in switch handling:
use Data::Dumper ('Dumper' : qw(+Indent=2 +Useqq));
#imports Dumper, sets $Data::Dumper::Indent=2, and
# does $Data::Dumper::Useqq is true
The above are both rare and of dubious practice. But that's not the
real problem I have with it.
What's the biggest problems with Exporter?
1) The man page is Big and Confusing to the first time module author.
2) Exporter is difficult to extend.
3) The internals are twisty and confusing.
And they all stem from one issue:
4) Exporter tries to do too much already.
The two biggest blocks to getting your first modules is figuring out
Makefile.PL (and thus MakeMaker) and figuring out how to export
functions. Both are confusing because the man pages are more
reference than tutorial. They have to be references because the
interfaces are big. The interfaces are big because they try to
implement lots of features. They try to implement every feature
because they're difficult to extend (ie. if you want to add to
Exporter you have to rewrite Exporter). They're difficult to extend
because it wasn't written to be extensible, there's lots of features,
and in Exporter's case, it does backflips to try and be lightweight if
you're only using a subset of its functionality (the Exporter::Heavy
hack).
Its interesting to look at who is using what bits of Exporter. Here's
a very rough breakdown (crude scanner attached, all praise forwarded
to Jeff Friedl).
1271 .pm files scanned
279 using or requiring Exporter
178 using anything beyond @EXPORT and @EXPORT_OK
125 anything beyond @EXPORT, @EXPORT_OK and %EXPORT_TAGS
83 using %EXPORT_TAGS
113 having their own import()
4 using @EXPORT_FAIL
which shows a few interesting things:
1) Exporter isn't being used as much as I'd thought.
2) More people use %EXPORT_TAGS than I'd thought.
3) A lot more people are finding it necessary to write their own
import() routine than I thought.
4) Almost nobody is using @EXPORT_FAIL (its just Carp and Exporter).
So here's the priority list I'd write out for Exporter::NG:
1) Support functionality equivalent to @EXPORT, @EXPORT_OK and
%EXPORT_TAGS and that's it.
2) Make the man page start with a quick tutorial.
3) Make it extensible.
The important thing being that Perl 6's exporter has a small, simple,
easy to explain interface. That it *doesn't* try to shove every
feature into one namespace. And that its easy for people to write
their own exporters.
Then I'd look at those 113 modules that found it necessary to override
Exporter's functionality (I've attached a list) and see what they're
doing. Once you've got a handle on that, move to step four:
4) Write seperate extensions based on the above.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
This is my sig file. Is it not nify? Worship the sig file.
http://www.sluggy.com
find /usr/local/share/perl/ /usr/share/perl*/ -name '*.pm' | wc -l
find /usr/local/share/perl/ /usr/share/perl*/ -name '*.pm' | xargs perl -0777 -ne 'print $ARGV\n if /(use|require) Exporter/' | wc -l
find /usr/local/share/perl/ /usr/share/perl*/ -name '*.pm' | xargs perl -0777 -ne '
$count++;
if( /EXPORT_TAGS/ || /sub\s+import\b/ || /export_to_level/ ||
/EXPORT_FAIL/ || /export_tags/ || /export_ok_tags/ ) {
$heavy_count++;
print $ARGV\n;
}' | wc -l
find /usr/local/share/perl/ /usr/share/perl
Re: Perl 6's Exporter
, though tags get a little weird because they don't automaticly populate @EXPORT_OK or something. That could be made easier. But it comes off as really complicated. Part of the problem is the @ISA = qw(Exporter) which initiates an I don't understand OO reaction. So that's going away. Part of it is how Exporter's manual is structured. Part of it is the size. The bigger the interface, the hard it is to explain. # 3) Make it extensible. How would you do this? My idea is that when you load Exporter::Whatever, it passes a couple coderefs to Exporter::register (or something). Those coderefs are given first whack at the parameter list. I think you're thinking of something wy more complicated than I am. Sounds like you want something that can add new functionality to Exporter. I was thinking just make Exporter easy to subclass. # The important thing being that Perl 6's exporter has a small, simple, # easy to explain interface. That it *doesn't* try to shove every # feature into one namespace. And that its easy for people to write # their own exporters. # # Then I'd look at those 113 modules that found it necessary to override # Exporter's functionality (I've attached a list) and see what they're # doing. Once you've got a handle on that, move to step four: I've removed the things from your list where the reason was blindingly obvious (pragma, source filter, interface is based on 'use'...) and reattached it; that brings it down to 68. Oddly enough, B::* and O.pm didn't appear on your list. B::* don't override import(), they use O for that. I missed O because it isn't in the directories I scanned. Debian scatters the perl installation all over the place. Your own Test::Simple and Test::More modules were on the list; unless I'm mistaken, that's because of 'use Test::More tests = N', which could be handled by options. ;^) Yeah, it was a good idea at the time. Don't fall into your own trap. # 4) Write seperate extensions based on the above. Just remember that some things are simply too weird. For example, I don't think we should try to accommodate Inline as an Exporter extension. :^) Look for commonalities. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Your words scratch the back of my eyes! http://sluggy.com/d/010204.html
Re: Stupid Newbie Question
On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
So, for example, lets say I have an object $foo, which is an instance of
Class A. In one method, foo tries to access an instance variable of
$bar, an instance of Class B (not inherited from Class A).
This is a naughty thing to do. $bar should have a set of accessor
methods if you're really worried. Read on.
If $bar's instance variables are somehow hidden
Looks like the whole an object is just a hash reference paradigm
might be mutating some to allow better data hiding. There was a big
thread on perl6-language about this just recently.
I could then have the Class B auto(vivify|glob) routine perform
checks on the identity and heritage of $foo, and then decide what to
do about the request.
There's a whole host of modules that make writing accessors cheap,
Class::Accessor and Class::Struct for example. Once you're inside an
accessor method you can do whatever access checking you like.
If I'm reading the tea leaves correctly, Perl 6 will address this sort
of thing with some variation on slots. So you can declare for *this*
list of instance variables, make me some simple accessors. So
C$foo-bar = 'this' == C$foo-{bar} = 'this'. So rather than
using AUTOVIVIFIY you'd use slots and accessor methods.
In theory, these slots should be closer to the speed of a regular
hash than accessor methods currently are in perl5.
That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc)
Last I checked Smalltalk had no privacy protection.
So, for Smalltalk type semantics, if $foo != $bar, the
request will throw some sort of exeption indicating that $foo isn't
allowed to see $bar's instance variables. But, if $foo == $bar, then
the actual value will be found and returned.
Smalltalk? not allowed? You sure about that? Or is this
something you hacked together with doesNotExist?
The question in my brain, since I don't know perl's internals in very
much detail, is how hard is it to figure out who the caller was?
caller(). Or is something more involved?
It's not just a matter of knowing what package the invoking
subroutine belonged to, because instances of the same class might
have have access to eachother's instance variables (ala Smalltalk).
It further complicates things if you want to extend it to include
C++ style friend functions (I don't, but others might).
die Sorry, private method unless caller eq ref $self;
die Sorry, protected method unless caller-isa(ref $self);
die Sorry, you're not my friend
unless exists $self-{_my_friends}{caller()};
That about covers basic method privacy.
(yes, I know you can emulate class variables via package globals like
$Class::blah, but I'm trying to look at it in a more uniform point of
view so that you can fully treat Classes themselves as being objects)
Class::Data::Inheritable anyone? :)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
You killed my fish?
Why does that pickle you?
http://sluggy.com/d/010204.html
Re: Stupid Newbie Question
On Thu, Nov 08, 2001 at 03:56:59PM -0800, John Rudd wrote: So, I'm reading various things about lots of changes for perl6, and some arcane things going away, and stuff like that.. and I suddenly wondered if one of my favorite features of Perl Objects (the one that keeps me from migrating to tcl or python, cuz I can never find clear information about whether such an analog exists in those languages) is going away: AUTOLOAD. Going away? No way, it's SPREADING! We might wind up with AUTOGLOB, too. http://dev.perl.org/rfc/324.pod -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One List context isn't dangerous. Misquoting Gibson is dangerous. -- Ziggy
Re: Stupid Newbie Question
On Thu, Nov 08, 2001 at 04:21:57PM -0800, John Rudd wrote: So, does this mean my other heart's desire of operator overloading might be coming forth? Yeah, that was mentioned in Apoc and Exewhatever 3. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One We're talkin' to you, weaselnuts. http://www.goats.com/archive/000831.html
Re: Indenting
On Tue, Oct 16, 2001 at 12:56:16PM +0200, Bart Lateur wrote:
Which reminds me... one of the less attractive features of here docs is
the fact that the quoted document always has to end in a newline. That
is annoying at times.
snip
If there was an easy way to chomp() that newline and return the
remainder of the string, that would solve this too. Like this?
sub chomped ($) {
chomp(my $s = shift);
return $s;
}
Given that you can write chomped() in two lines, and given that you
want the trailing newline in at least 90% of all cases, doesn't that
pretty much solve the problem without a built-in?
I don't really like this solution much. And it's not worth an extra
keyword, for chomped() to become a built-in.
Well, as discussed briefly in an earlier thread,
http:[EMAIL PROTECTED]/msg08514.html
if we allow ! in function names, we can distinguish between the normal
and in-place versions of functions without proliferating the number of
keywords.
chomp! $string;# how chomp() currently works
my $chomped_string = chomp $string;# like your chomped() function
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
at last, paste for all
citizens will proclaim me
paste enema god
-- imploded
Re: Indenting
On Wed, Oct 17, 2001 at 07:56:04AM +1000, Damian Conway wrote: Well, as discussed briefly in an earlier thread, http:[EMAIL PROTECTED]/msg08514.html if we allow ! in function names, we can distinguish between the normal and in-place versions of functions without proliferating the number of keywords. chomp! $string;# how chomp() currently works my $chomped_string = chomp $string;# like your chomped() function Or, rather than this over-excited syntax, perhaps we could distinguish the pure function: chomp $string; # return a chomped copy of $string from the method: chomp $string: ;# chomp the original $string # a.k.a. $string.chomp; That : doesn't really catch the eye well at all. It seems sort of odd to have a special syntax to disambiguate between a method call and a function call when we already have syntax to do so: chomp $string; # function call $string.chomp; # method call. Leaving that aside, making the method call work in-place and the function call work not will work *if and only if* it's consistently applied. Otherwise it's just going to get confusing to remember which method versions work like which functions and which don't. $string.chomp # in-place chomp @array.sort # sorts @array directly $string.chop# chops the last character off $string my $clean_string = chomp $string; my @sorted_array = sort @array; my $clean_string = chop $string; etc... Also, the methods should return their own objects to allow efficient chaining (ie. we're not copying, we're aliasing): print $string.chomp; And this should solve the trailing terminator here-doc problem nicely: print (FOO).chomp; blah blah blah blah blah more blah FOO Which leaves a small hole. chop() currently returns the character chop'd, and chomp() should probably do the same. But they can't, since we're already using the return value for something else. Considering how infrequently the return value of chop() and chomp() is really used, and how easy it is to emulate the current chop() and chomp() behavior with substr() and s///, I don't think it'll be a big loss. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do you actually think about what you are saying or is it an improvisational game of Mad Libs that you play in your head?
Re: Indenting
On Tue, Oct 16, 2001 at 08:53:07PM -0500, David M. Lloyd wrote: What about 'chomp?' for query but 'chomp' (no decoration) for operation? Is chomp? just a bad example, or is there some utility in asking if a string has already been chomped? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One How can I stoop so low? Years of practise, that's how. It's been hard going but now I can stoop lower than a pygmy limbo dancer. -- BOFH
Re: Indenting
On Tue, Oct 16, 2001 at 08:31:31PM -0700, David Whipp wrote: Is chomp? just a bad example, or is there some utility in asking if a string has already been chomped? The query is asking what the string would look like, if it were chomped. That's a weird use of a query method. In fact, that sounds like a normal method call. Applied to some other situations: # What would @list look like if it were sorted @sorted_list = @list.sort? # What would this filehandle look like if it were open $open_fh = $fh.open? I expect query methods to be simple yes/no questions that return true/false. @list.sort? should return whether or not the @list were sorted (not that this is particularly useful) and $fh.open? to tell me if the filehandle is open or not. I think the function/method distinction is a better seperation between what would this thing look like if it were acted on and act on this thing. # What would this look like if it were sorted? @sorted_list = sort @list; # Sort this list @list.sort -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Me? A robot? That's rediculous! For one thing, that doesn't compute at all!
Re: Indenting
On Sat, Oct 13, 2001 at 04:30:08PM +0200, raptor wrote:
I was looking at TPJ one-liners and saw this :
#32A trick for indenting here strings
($definition = 'FINIS') =~ s/^\s+//gm;
The five varieties of camelids are the familliar
camel, his friends the llama and the alpaca, and
the rather less well-known guanaco and vicuna.
FINIS
Courtesy of The Perl Cookbook
It is very cool if we have a way to set this RegEx so that it executes in
compile time I mean if we have the ability to set this, so that we have
any funny formating we want w/o loosing the speed of parsing it at
runtime...
There was a big hub-bub about this back when RFCs were flying around.
If I remember Apoc 2 correctly, it will work like so:
$definition = 'FINIS';
The five varieties of camelids are the familliar
camel, his friends the llama and the alpaca, and
the rather less well-known guanaco and vicuna.
FINIS
The here-doc text will be stripped up to the indented terminator. So
in this case, all the leading whitespace will be stripped off.
Not only is it a bit faster than the s/^\s+//gm regex, but it is also
more flexible.
if( $self-feeling_snooty ) {
print 'POEM';
Sometimes
form has to follow function
all over the page.
POEM
}
Rather than simply stripping the whitespace off the front, which would
lose the layout of the poem, it only strips as much as POEM is
indented. Like having s/^\s{4}//gm. So you get the equivalent of:
print
Sometimes\n.
form has to follow function\n.
all over the page.\n;
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Home of da bomb
Re: Just a thought...
On Tue, Oct 09, 2001 at 11:22:02AM +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier? I quite like the ruby/scheme idiom of
having boolean methods ending in a question mark. eg:
sub is_visible? {...}
I was gonna suggest that pre-Apoc 3 but ran into the same trouble with ?:
Hmm, $obj.meth! is a syntax error, but func! isn't. Damn.
For those of you that don't know, func! is another Ruby idiom that
differentiates between the version of a function that returns it's
results and the one which alters it's arguments in place. So, for
example:
# this would act like the perl5 chomp
my $num_chars = chomp! $string;
# this would leave $string alone and return the chomped string.
my $chomped_string = chomp $string;
Perhaps a little more useful:
# Sort as we know it.
my @sorted = sort @array;
# Sort in place.
sort! @array;
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: Hyper concat ^_ ?
On Fri, Oct 05, 2001 at 09:50:53AM +0100, Richard Nuttall wrote:
my @images = qw( pic1 pic2 pic3) ^_ ('.jpg');
my @images = map { $_ _ '.jpg' } qw(pic1 pic2 pic3);
Hmmm, that's visually unappealing.
Just thinking out loud.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
GOD made us funky!
Re: General Feelings on Apoc 3
On Thu, Oct 04, 2001 at 05:59:53PM +1000, Damian Conway wrote: Hyperoperators: I sort of understand it, but don't really grok it. I can sort of thing of ways it might eliminate the need for a few maps and foreaches. Damian, might I request some clarification in Exogenesis? Well, I'll probably clarify them in Exegesis instead. External birth would seem a bit extreme here. ;-) Sorry, didn't mean to imply that you'd laid an egg. ;) Backtracking: Ok, I don't get it at all. Damian, clarification? Nothing to clarify. Larry punted (to a later Apocalypse). Okay. That's a cop-out. He's basically saying that you can write Candthen and Corthen yourself as: snip I understand that much. What I don't quite get is the utility. There's some hand-waving in the RFC about making parsers easier. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Obscenity is the last resort of the illiterate, Mother Fucker -- KAL
Re: General Feelings on Apoc 3
On Thu, Oct 04, 2001 at 08:29:10PM -0500, David Nicol wrote: Binary // The analogy to || is probably a bit too clever. My first reaction was it's some sort of weird division operator. But it's servicable. It echoes the switch from | to / within the IETF RFC syntax declaration language. Apparently the global keyboard steering committee has deprecated the vertical bar. You don't know how many times I've heard people complain that Perl isn't catering enough to the needs of IETF RFC authors. :-P I have a feeling that echoing the IETF is just a coincidence. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One purl Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
Re: Custom iterators
On Wed, Oct 03, 2001 at 02:26:47AM +0200, Bart Lateur wrote:
foreach_line { print } 'some/file';
You really like underscores, do you?
If all you got out of that thread was Schwern likes underscores then I
explained iterators really, really, really badly.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
My breasts are arousing weapons.
Re: Math functions? (Particularly transcendental ones)
On Sun, Sep 09, 2001 at 02:33:17PM +1000, Jeremy Howard wrote: Uri Guttman wrote: BS == Benjamin Stuhl [EMAIL PROTECTED] writes: Can anyone think of things I've forgotten? It's been a while since I've done numeric work. BS ln, asinh, acosh, atanh2? dan mentioned log (base anything) but i don't recall ln. and definitely the arc hyberbolics are in after i pointed them out. dunno about atanh2. We only really need ln(). Then [log(y) base x] is simply [ln(y)/ln(x)]. There's no need to have separate functions for different bases. If we try to get away with just implementing ln(), we'll probably waste more time, space and effort answering FAQs about How do I do log base X in Perl? than we ever would just implementing log(y, base_x). Do ln(y) and log(y, base_x) and you pretty much cover everything. Besides, we have to have at least log(y) for backwards compatibility--and I don't think because it's mathematically redundant is a valid reason to bust compatibility for a tiny little function like log(). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One The desired effect is what you get when you improve your interplanetary funksmanship.
Re: Math functions? (Particularly transcendental ones)
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: pow : Raise x to the y power You forgot biff, zap and womp! -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One stretch your colon out, put some effort into it, and shit through that paste. -- japhy
Re: Labels
On Wed, Sep 05, 2001 at 09:02:00PM -0400, Bryan C. Warnock wrote:
Hmm is this such a good thing?
Using goto LABEL? No. ;)
Would be nice if Perl warned one about multiple labels of the same
name in the same call stack, though.
my $a = 0;
GORK: while( 1 ) {
print Rin ;
GORK: if ( 1 ) {
print Tin ;
goto GORK if $b ^= 1;
print \n;
next GORK;
}
}
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I blame myself. AND SATAN.
Re: Source/Program metadata from within a program
On Mon, Sep 03, 2001 at 04:56:28PM +0100, Nick Ing-Simmons wrote: The problem is, it appears DATA is only opened if there's an __END__ or __DATA__ tag. I don't remember it working this way... *shrug* We can fix that easy. :) No you can't - you run out of fd's pretty quick if every .pm file you touch leaves one open to be seekable... Simple, just tie it so it only opens upon being used. OR, and I have no idea why I never thought of this before, instead of magic filehandles, just peek in %INC and open that file. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: Multiple-dispatch on functions
On Sat, Sep 01, 2001 at 01:10:58PM -0400, Dan Sugalski wrote: At 10:03 PM 8/30/2001 -0400, Michael G Schwern wrote: Thinking about what Zhang was saying about multiple-dispatch not being inherently OO. I think he's sort of right. Multiple-dispatch need not be confined to method lookups. There is the potential for a pretty significant cost to this, since we'd need to evaluate the args at runtime for each call. (Possibly we could do some compile time optimization, but not in a lot of places, alas) H shouldn't be any worse than a multi-method call. And it'll only effect those functions with the 'multi' flag. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let's face it, said bearded Rusty Simmons, opening a can after the race. This is a good excuse to drink some beer. At 10:30 in the morning? Well, it's past noon in Dublin, said teammate Mike [Joseph] Schwern. It's our duty. -- Sure, and It's a Great Day for Irish Runners Newsday, Sunday, March 20, 1988
Re: Multiple-dispatch on functions
On Sat, Sep 01, 2001 at 03:12:17PM -0400, Dan Sugalski wrote: Nope, the cost will be paid on all sub calls. We at least need to check on every sub call to see if there are multiple versions of the functions. (We can't tell at compile time if it's a single or multi-method sub call, since it can change at runtime) Granted, it's not a huge expense for non-multi-method calls, but it does still impose an overhead everywhere. Sounds like it could be solved with a function call cache similar to the method call cache we have now. Just blow it away if anything touches that package's symbol table. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: Source/Program metadata from within a program
On Fri, Aug 31, 2001 at 10:04:00AM -0400, John Porter wrote: Brent Dax wrote: use Fcntl qw(:seek); seek DATA, 0, SEEK_SET; @code = DATA; IMHO, that's too hackish--just reading that doesn't make what you're doing obvious. It also can only get the main program, not any of the modules it loads. use Some::Module; use Fcntl qw(:seek); seek Some::Module::DATA, 0, SEEK_SET; @their_code = Some::Module::DATA; which only works if Some::Module has an __END__ block... but that shouldn't be hard to fix. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Lord of Kwalitee! Wearer of the CPANTS and Slayer of Pseudo-hashes!
Re: Source/Program metadata from within a program
On Fri, Aug 31, 2001 at 11:25:17AM +0100, Nicholas Clark wrote: Who said that my source file handle was seekable? The problem is, it appears DATA is only opened if there's an __END__ or __DATA__ tag. I don't remember it working this way... *shrug* We can fix that easy. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One purl Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING- LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR INNARDLYBITS!
Re: CLOS multiple dispatch
On Thu, Aug 30, 2001 at 06:34:31PM -0700, Hong Zhang wrote: None of them. That's why Class::Multimethods doesn't use CLOS's awful left-most argument first resolution mechanism. So what is the next step. How do you define the next most-matched methods. Please look at how Class::Multimethods works and what is described in http://dev.perl.org/rfc/256.pod before continuing. Play with Class::Multimethods, because I believe that's pretty much RFC 256. That is simply not correct. There is a considerably body of research on efficient dispatching. Dan is already aware of this. I don't like this statement. If it was not an issue, why we need considerable research on it. I think you misunderstood him. Damian ment that people have *already* done considerable research into efficient multimethod dispatch. All we (read 'Dan') have to do is read up on it. Let's say C is only 80% of Fortran on math, I still don't see the reason to put math into C language for the last 20% of speed. It may be my personal preference. The difference in speed between a pure-perl multimethods implementation and an in-core implementation should be considerable. If you're curious, benchmark the existing Class::Multimethods module against normal method calls. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm spanking my yacht.
Multiple-dispatch on functions
Thinking about what Zhang was saying about multiple-dispatch not being
inherently OO. I think he's sort of right. Multiple-dispatch need
not be confined to method lookups.
foo();
foo($bar);
foo($baz);
foo($bar, $baz);
sub foo () : multi {
...
}
sub foo (Bar $bar) : multi {
...
}
sub foo (Baz $baz) : multi {
...
}
...etc...
Obviously, there would be no inheritance. Otherwise, it's
just like multiple-dispatch where there's no superclass.
Handy, if it's not too hard to implement.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Let's face it, said bearded Rusty Simmons, opening a can after the
race. This is a good excuse to drink some beer. At 10:30 in the
morning? Well, it's past noon in Dublin, said teammate Mike
[Joseph] Schwern. It's our duty.
-- Sure, and It's a Great Day for Irish Runners
Newsday, Sunday, March 20, 1988
Re: Source/Program metadata from within a program
On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote:
Access to the source code.
Already got that.
use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
@code = DATA;
We're going to be carrying it around, unless we
strip it. We might as well put it to good use within error messages and the
like. If an error points me to foo:356, I want my DIE handler to dump the
code surrounding that.
snip
Compilation time. For each of my compilation units, I would like to know
when it was compiled. Compilation unit scoped.
You can already do that. Override CORE::GLOBAL::require/use/do.
Your overridden require/use/do can mark the time it was called *and*
remember the *DATA filehandles. On an error, you can do:
use Fcntl qw(:seek);
$SIG{__DIE__} = sub {
my($pack, $file, $line) = caller;
if( my $data_fh = $DATA{$file} ) {
my $orig_pos = tell $data_fh;
seek $data_fh, 0, SEEK_SET;
my @code = $data_fh;
print STDERR @_;
print STDERR @code[$line-2..$line+2];
seek $data_fh, $orig_pos, SEEK_SET;
}
}
When will we be seeing the CPAN module for this?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I know you get this a lot, but what's an unholy fairy like you doing in a
mosque like this?
Re: Source/Program metadata from within a program
On Thu, Aug 30, 2001 at 10:52:27PM -0700, Brent Dax wrote:
# Already got that.
#
# use Fcntl qw(:seek);
# seek DATA, 0, SEEK_SET;
# @code = DATA;
IMHO, that's too hackish--just reading that doesn't make what you're
doing obvious. An explicit $*CODE filehandle would make more sense to
the uninitiated.
sub my_code {
use Fcntl qw(:seek);
seek DATA, 0, SEEK_SET;
return DATA;
}
Stick that in a module, slap on some docs and you're all set. Geeez,
that's what modules are for!
I thought we actually wanted to get something done, not sit around
saying Everything will be perfect when Perl 6 comes!
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Let's face it, said bearded Rusty Simmons, opening a can after the
race. This is a good excuse to drink some beer. At 10:30 in the
morning? Well, it's past noon in Dublin, said teammate Mike
[Joseph] Schwern. It's our duty.
-- Sure, and It's a Great Day for Irish Runners
Newsday, Sunday, March 20, 1988
Re: Expunge implicit @_ passing
On Tue, Aug 28, 2001 at 09:10:40AM -0400, Ken Fox wrote: One of the cool things about Perl's OO system is that it lets us invent new type systems. This IMHO is its greatest strength. Perhaps this is also why some OO people hate Perl's OO? Yes, this sort of thing FRIGHTENS THE HELL out of non-Perl people. This is not a bad thing, it just means they have to stop expecting the language designer to dictate their whole universe. They can only see hordes of malicious hackers and irresponsible junior programmers blowing away their classes at run-time. As the pendulum swings in the other direction you get mind-bogglingly silly things like finalize which I just learned of today. I'm going to be giving a talk about just this sort of thing at JAOO to a room full of Java people. Should be interesting. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Your average appeasement engineer is about as clued-up on computers as the average computer hacker is about B.O. -- BOFH
Re: Expunge implicit @_ passing
On Tue, Aug 28, 2001 at 10:47:35AM -0700, Damien Neil wrote: On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote: As the pendulum swings in the other direction you get mind-bogglingly silly things like finalize which I just learned of today. What's so silly about finalize? Sorry, I ment final. final classes and methods. The idea that you can prevent someone from subclassing your class or overriding your methods. I've seen things that hinder reuse, but this is the first time I've seen one that violently blocks reuse! Wow. I'm reading the Sun tutorial on the subject. Interesting reading. http://java.sun.com/docs/books/tutorial/java/javaOO/final.html They list two reasons to make your class final. One is security (which might actually be valid, but I doubt it will hold up to determined attack), the other though... You may also wish to declare a class as final for object-oriented design reasons. You may think that your class is perfect or that, conceptually, your class should have no subclasses. The idea that a class is either 'perfect' or 'complete' has to be the silliest, most arrogant thing I've ever heard! Anyhow, just don't anyone suggest putting this in Perl 6. I know where you live. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Good tidings, my native American Indian friend! America will soon again be yours! Please accept 5th Avenue as an initial return!
Re: Expunge implicit @_ passing
On Mon, Aug 27, 2001 at 10:58:00AM -0400, John Porter wrote: You can, with C goto $foo; . Problem is, it's *slower* (in p5 anyway) than the plain sub call. By only 10%. Let's keep things in proportion here. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One It sure is fun masturbating. http://www.unamerican.com/
Re: Expunge implicit @_ passing
On Mon, Aug 27, 2001 at 06:50:35PM -0400, Ken Fox wrote:
Michael G Schwern wrote:
Any time you want to implicitly pass @_, you can just as easily
*explicitly* pass it or use goto.
I never thought of using goto actually. goto $method; actually
looks clearer than the code I'm using. (Although with re-directors
we want to minimize cost so the 10% penalty should be eliminated.)
Larry Wall has a quote about goto somewhere...
It would be possible to optimize some forms of goto, but I haven't
bothered.
-- Larry Wall in [EMAIL PROTECTED]
but I think he was refering to goto LABEL.
Anyhow, with a redirector it's more important for caller() to be
untouched than a little microptmization, so goto is the way to go.
If you *really* wanted to write an optimized redirector, you'd
have the redirector eliminate itself.
sub foo {
my $method = $_[0]-{_foo} || $_[0]-can(_foo);
{
no warnings 'redefine';
*foo = $method;
}
goto $method;
}
in the first call to foo(), the redirector will replace itself with
the real method. Thereafter, it's a normal method call. That's the
real savings.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
Re: Expunge implicit @_ passing
On Mon, Aug 27, 2001 at 06:02:50PM -0500, Garrett Goebel wrote:
From: Ken Fox [mailto:[EMAIL PROTECTED]]
Michael G Schwern wrote:
Any time you want to implicitly pass @_, you can just as easily
*explicitly* pass it or use goto.
goto does screw up caller... so I wouldn't say *anytime*
That's what 'or' means.
sub foo { { $_[0]-{_foo} || $_[0]-can(_foo) } }
works just as well as
sub foo { goto { $_[0]-{_foo} || $_[0]-can(_foo) } }
and doesn't mess up code which relies on caller...
A good redirector should be totally transparent. When _foo() asks for
it's caller() it should get foo()'s caller, not foo() itself.
So in this case, goto does the right thing.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
You see, in this world there's two kinds of people. Those with loaded
guns, and those who dig. Dig.
-- Blonde, The Good, The Bad And The Ugly
Re: Changes in addressing of package variables?
On Fri, Aug 24, 2001 at 09:20:26PM -0700, Brent Dax wrote: I was thinking about Perl 6 today, and thought of something: if the sigil is now part of a variable's name, does that mean that $Foo::bar should actually be Foo::$bar in Perl 6? Techincally 'bar' is shorthand for the complete name, 'Foo::bar'. So '$Foo::bar' would remain. Besides, Foo::$bar looks funny. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in $CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top. -- Ziggy
Expunge implicit @_ passing
Odd feature of perl5:
sub bar { foo }
sub foo { print @_ }
print bar(It's Magic!);
When foo() is called as foo with no parens and no arguments, it
inherits @_ from it's caller.
This might have been originally introduced as an efficient way to pass
huge sets of arguments without copying before references were
introduced, but that's not a problem anymore. foo(@_) or goto foo
works just fine.
I can't think of any reason why this feature is useful anymore, and it
can be a really confusing behavior, so what say we kill it in Perl 6?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
You see, in this world there's two kinds of people. Those with loaded
guns, and those who dig. Dig.
-- Blonde, The Good, The Bad And The Ugly
Re: if then else otherwise ...
On Sat, Jul 28, 2001 at 04:34:46PM +0300, raptor wrote:
if (cond)
{ }
else {}
otherwise {}
i.e.
if cond == 1 then 'then-block'
if cond == 0 then 'else-block'
if cond == -1 then 'otherwise-block'
Sounds like you need a switch, yes. The cases where cond will
be 1, 0 and -1 is fairly rare in Perl and is pretty much limited
to cmp and =.
I'm curious to see examples of existing code which otherwise would
improve, but it really doesn't seem like there's much improvement
either way and you severely complicate the meaning of Cif( cond ),
since it has to now fail on -1 if Cotherwise exists.
PS -1 is true, just to make sure that's clear.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Hold on while I slip into something a little more naked.
Re: Feeding potatoes to dead horses
On Thu, Jul 12, 2001 at 06:56:25PM -0700, Dave Storrs wrote: On Tue, 10 Jul 2001, Michael G Schwern wrote: You can always just do this: my Value $foo; And $foo will act like a normal scalar taking anything (your PMAW). If that's the goal, I'd vote that it be spelled: my Scalar $foo; Yeah, I'm just a little worried it will be confused with my SCALAR $scalar_ref; but it should be fine. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One ck and shiny crust over my hairy anus constipation sucks -- Ken Flagg
Re: precision belongs in bigfloats, nowhere else.
On Thu, Jul 12, 2001 at 06:09:07PM -0400, Dan Sugalski wrote: Depending on what you do with them, precision (or, rather, significant digits) is a useful concept for integers as well. Just because you have, for example, an integer with 43 digits doesn't mean that all 43 are actually useful or trustable--you may only have 2 or 3 that mean anything. I digress... They went through Great Pains in Engineering class to hammer into our head that 43 != 43.0 != 4.3 x 10 in the land of significant figures and taught us all these special considerations for preserving sig figs through mathematical operations. A Math::SigFigs might be interesting, if I ever found myself needing them I might write it. For those of you whose branes haven't been loaded down with this bit of engineering baggage, the idea is to express the accuracy of a measurement through a number. If you've got a normal ruler and measure the length of something, you're probably going to get accurate it down to the centimeter. 43 cm, say. What you really mean is 43 cm plus or minus 0.5, and that's what 43 cm means in significant figures. Say you then measure something else with a highly accurate tool and get 20.5432 cm. Again, what you mean is 20.5432 cm +/- 0.5 What is the total length of those two things? 63.5432 cm, right? Not in the land of sig figs. Because the first measurement is so much more innacurate than the first, its innaccuracies swamp the measurement. The answer is 63 (or 64, I forget which way the rounding goes) to reflect the inaccuracies involved. 63 cm +/- 0.5 cm. I have no idea if this is what Dan was thinking. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If you got the wax out of your ears you could hear the twister picking up the trailer park of your future!
Re: Feeding potatoes to dead horses
On Tue, Jul 10, 2001 at 01:02:18AM -0500, David L. Nicol wrote: The real problem isn't [sig digs]. The real problem is how much this complicates the implicit typing rules. I'm going to have to play around a bit and see which way works best. I hope you're proposing that fatal errors on poor conversion is off by default. You mean if you try this: my Num $foo = 4.2; my Int $bar = $foo; # *error* loss of information that would be fatal, yes. I think that's the right thing to do, its exactly the sort of thing types are made to defend against. You can always cast: my Int $bar = int($foo); PS This is *ALL* off by default. This would be a nice thing to have a pragmata for, what hash refs stringify to. Why? Example of use? I had a situation where I cared if refs were reffing the same object or not and interpolating them was actually handy. But there are other situations where it might be nice to have them expand to their keys, expand to their values, or expand to their perl5 arrayifications. This appears to be outside the scope of this discussion. Refs don't do any of that right now with or without typing. If you're building strong typing, some magic has to go. 99% of the time when you use a reference as a string its a mistake. Ergo, references do not automatically cast. You can always make an explicit cast or bless your refs and overload their references' stringification. Remember, the idea here is to catch mistakes. When in doubt, do everything. Unfortunately, there's a very finite amount of tuits available to implement all this, not to forget document, test and teach. When in doubt, stop and rethink. my $foo;# PMAW PMAW? Perl's Magical Autoconverting Wondervariable. The draw of the PMAW is why we're all here (rather than outside in the heat, tinkering with our regenerative braking systems) in the first place. We could assume untyped variables are untyped, but I'd rather they're considered mistakes. Again, the purpose here is to catch mistakes. I don't know if this will wind up being more or less annoying, we'll have to play with it a little. Fortunately, its a decision that can easily be reversed. You can always just do this: my Value $foo; And $foo will act like a normal scalar taking anything (your PMAW). Rather than just speculate, I'm going to go play with this idea for a while. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I was *meant* to mount your donuts.
Re: You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either.
On Mon, Jul 09, 2001 at 04:43:28PM +1000, Jeremy Howard wrote: One of mjd's points about mashed potatoes is that Perl isn't ML, and ML's typing approach doesn't fit on top of Perl very well (i.e. at all). Well, my hope is somehow we can get types to be a bit more implicit than the usual mess most people are used to. Stroustrup noticed the same thing (about typing, not mashed potatoes) when looking at this issue for C++. His solution was the introduction of 'templates': YeeeAHHH!! Don't say that word!! I'll have nightmares now. Because templates provide much-needed flexibility in algorithm and class development, C++ programmers don't have to use many of the workarounds that mjd identified. Yes, they have lots of different work arounds. ;) Perl 5 didn't need templates, because there wasn't compile-time typing. But with Perl 6 I want to send my compact array of integers to the same fast sum() function as my compact array of floats, and not have to wait while perl treats them both as old generic scalars. That means that my sum() function needs a typed parameter list. There seems to be at least two potential solutions: - Provide a type placeholder in the parameter list (a la C++ function templates) - Provide a type hierarchy for all types (a la Haskell) I think a type hierarchy makes much more sense than unleashing the hell of templates on Perl. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: Implied types, first try. Or Its amazing what you can do with potatoes
On Mon, Jul 09, 2001 at 11:00:45PM -0500, David L. Nicol wrote: [EMAIL PROTECTED] wrote: Why not drop the sigil on things with declared types? A VERY SHORT DIGRESSION INTO SIGILS I'm going to say you need sigils for this: print Hello, my name is $name\n; You're going to say this: print Hello, my name is $(name)\n; And then I'm going to say that looks like crap and then 12 other people are going to join in and then nothing useful will get done. So in the interest of keeping this thread down to just one massively controversial topic, let's assume the sigils are going to stay for the purposes of this discussion. THIS ENDS THE VERY SHORT DIGRESSION INTO SIGILS. PLEASE DO NOT START ARGUING ABOUT THEM IN THIS THREAD. THANK YOU. I'm pondering this being okay: my Num$dec = 4.0; my Int$int = $dec; # Num - Int okay since 4.0 truncates to 4 # with no(?) information lost You have lost information. You have lost one digit of precision. That is not insignificant. Although that information is currently carried in STRING types and not in FLOAT types. Sig figs isn't really the issue here. You can convert back and forth between 4, 4.0, '4' and '4.0' all day and still get the same value (I'm ignoring for the moment the possibility of floating point error, I don't know how much of an issue it is). The real problem isn't that. The real problem is how much this complicates the implicit typing rules. I'm going to have to play around a bit and see which way works best. You'd have to do an explicit typecast (syntax left as an exercise). Given that most times when you try to use a reference as a string you're making a mistake, this shouldn't be a big deal. This would be a nice thing to have a pragmata for, what hash refs stringify to. Why? Example of use? Now, here's an example of something that might be really annoying to get right. Let's say localtime() returns a hash in Perl 6 (sensible). snip localtime would return a magic read-only hash reference. snip I just picked localtime() as a sufficiently complicated example. I don't really want to discuss its interface here. See sigils above. The real question: variables implying their types from function signatures... is it sane? my $foo;# *error* forgot to declare a type. We could have Perl go through heroics to try and find $foo's first assignment and imply a type from that, but I think that will rapidly get Messy and Surprising. my $foo;# PMAW PMAW? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Realize this, sweetheart, I'm squeezing my poodle.
Re: Implied types, first try. Or Its amazing what you can do with potatoes
On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote:
User-defined types?
Haven't even thought about them yet.
I'm pondering this being okay:
my Num$dec = 4.0;
my Int$int = $dec; # Num - Int okay since 4.0 truncates to 4
# with no(?) information lost
but I think it will complicate my Grand Plan which I'm not ready to
reveal.
Compile-time or run-time?
It would have to be a run-time type check if we allowed Num to cast to
Int. Similar to allowing Strings to cast to Ints and Nums. Is that
run-time nature that worries me, might get in the way of implied
types.
my Num $x = 3.0;
$x++;
my Int $y = $x;
Could be compile-time, if you do constant folding first.
Alot of how much checking we can do at compile-time depends on how
long we have to compile, and thus optimize. If you precompile your
Perl 6 program, then we have all the time in the world. If you're
compiling on the fly (ie. how we do it now) then you can't spend so
much time doing constant folding.
Dunno yet.
So Int is a subset of Num, and '4' and '4.0' are considered to be
exactly equivalent.
Yes, that's my thinking. I'm going to have to play with it and see
how annoying it is if Nums don't auto-cast to Ints.
but we like to mix types up in hashes. One way we can allow this is
to have a generic type, Value (or perhaps Scalar) that every type will
cast into. Hash keys would be implicitly of type Value.
my Value %hash = (foo = 1, bar = 2, baz = 'yarrow');
but that's pretty much the same as switching off strong typing. So
obviously hashes have to have per-key types. I will leave the syntax
of that as an exercise for the reader. It would have to make it easy
to declare lists of keys as being a single type. If we come up with
something nice here, it can probably be backported onto arrays.
It's only switching off strong types for that variable, so it's a
valuable thing to do.
Its switching off types for pretty much all hashes, since hashes very
often have mixed type values (think objects and structs). We've
definately got to have per-key hash types.
my qt(String = DontEvenThinkAboutIt) %tree = (id = 1);
$tree{parent} = \%tree;
(or if you think you can tackle that)
$tree{parent_with_distance} = [ 0, \%tree ];
a map from strings to numbers and lists of two elements, where the first
element is a number and the second is a reference to a map from strings
to numbers and lists of two elements...
I don't follow.
How is a regex different from any other function that makes sense with
multiple types?
Most functions don't change a variable in place. s/// does. substr()
is also a problem. .= another.
my $foo = 42; # Int type implied
my String $bar = read_line($some_file);
$foo .= $bar;
That expands out to
$foo = $foo . $bar;
$foo . $bar is fine, since Ints can auto-cast to Strings. The result
is a new string which is reassigned to $foo. If that string looks
like an integer, its okay. Otherwise its a run-time type violation.
Not having auto-casts would solve this problem, but then it would make
life suck in so many other ways.
my Int $foo = 42;
my Num $bar = 4.2;
my Int $foo2 = increment($foo);
my Num $bar2 = increment($bar);
my Sub $sub2 = increment(sub { 42 });
sub increment {
my $x = shift;
if (ref $x eq 'CODE') {
return sub { 1 + $x-(); }
} else...
}
I'm going to presume for the moment that functions must have declared
types, otherwise they simply take and return Values. I haven't really
thought about making function signatures implicit yet.
sub escape_cgi_param { return quotemeta(shift()) }
my Int $id = escape_cgi_param(...);
my String $name = escape_cgi_param(...);
The latter is fine. The former might be a run-time type violation if
escape_cgi_param returns something that doesn't look like an integer.
But it needs to resolve the type of an arbitrarily nasty expression
anyway, doesn't it?
my $foo = (time % 2) ? one : 3; # $foo is a String
I don't know how far we can do with this. Again, it depends alot on
how much time we have to compile.
Or consider
Yep, these are all nasty possiblities. mjd suggested I go through
some real-world code and see how much of it I can make implicit, what
problems are encountered, if there are any restrictions I might have
to make, etc... I'm going to do that a bit and come back. Functions
will be tough.
(you wrote your ramblings, I wrote mine. I spent much time thinking in
circles about this stuff during the RFC phase and didn't really come up
with much. So now I'm seeing what I come up with without thinking. :-) )
Yeah, not thinking can sometimes reap interesting ideas. :)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
GuRuThuG make
Re: You can't make a hot fudge sundae with mashed potatoes instead of ice cream, either.
On Mon, Jul 09, 2001 at 10:37:47PM -0500, David L. Nicol wrote: Jeremy Howard wrote: \ Perl 5 didn't need templates, because there wasn't compile-time typing. But with Perl 6 I want to send my compact array of integers to the same fast sum() function as my compact array of floats, and not have to wait while perl treats them both as old generic scalars. Snip I haven't been tricked into reading MJD's article yet, but might your third option be multiple functions with parameter-type-based dispatch? We can do that with perl 5, but it isn't automatic. The problem with polymorphic functions is you have to rewrite the function N times (where N == the number of different types you want to handle). Its certainly a possiblity, it just seems rather inelegant. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I have this god-awful need to aquire useless crap!!!
Re: Anyone actually experienced with object inheritance?
On Thu, Jul 05, 2001 at 11:04:29AM -0700, Hong Zhang wrote:
I don't think object inheritence has any significant advantage.
Since it is not widely used and understood, we should not use it
in Perl, period.
*cough* A little harsh.
Its functionality can be achieved by many different ways. The
anonymous class is one of them. Personally I prefer using mixin.
The mixin is similar to Java interface. The differences are that
a) mixin can have instance fields, but they must be private.
b) mixin can have method implementations.
c) mixin can not have superclass.
Why no superclass?
Here is an example:
public mixin Node
{
private Node next, prev;
public Node next() { return next; }
public void next(Node n) { next = n; }
public Node prev() { return prev; }
public void prev(Node n) { prev = n; }
}
Say if you want Thread can be easily inserted into LinkedList,
you can write
public Thread extends Object implements Node {
...
}
or
public Thread extends Object, Node {
...
}
and don't bother to implement classic linked list node.
Given that Perl doesn't really have to worry about strict typing or
interfaces (at the very least it will be very optional in Perl 6) what
problem is this solving?
And how would this solve the Mail problem put forth by Ziggy?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I'm not actually Kevin Lenzo, but I play him on TV.
Re: Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
On Fri, Jul 06, 2001 at 12:41:42PM -0500, David L. Nicol wrote: But would the game be worth the candle? IMHO not really. Of all the potential quirks Perl's OO has, this is one of the least quirky and least violated. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #21: POSIX complience problem
Re: Anyone actually experienced with object inheritance?
On Tue, Jul 03, 2001 at 12:10:19AM +0200, Bart Schuller wrote: The Apple Newton was programmed in NewtonScript, a prototype-based language. http://www.cc.gatech.edu/~schoedl/projects/NewtonScript/ seems like a nice overview. Ahh, its derived from Self. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I've just gone through a lung-crushing breakup with my blender and I don't think I should screw my forehead alone tonight.
Good example of object inheritance's usefulness
Ziggy came up with a good example of when object inheritance makes
life easier. Basically, there are times when you'd want to override
individual methods of individual objects. Example below.
- Forwarded message from Michael G Schwern [EMAIL PROTECTED] -
From: Michael G Schwern [EMAIL PROTECTED]
To: Adam Turoff [EMAIL PROTECTED]
Subject: Re: Anyone actually experienced with object inheritance?
On Mon, Jul 02, 2001 at 07:56:27PM -0400, Adam Turoff wrote:
What I want is a lazy object interface. I want a mailbox class
that has a factory method like next() that returns mail message
objects. When instantiated, each message has a few members and
object data containing the unparsed text of the message. When
header() or body() is called, then and only then do I want the
message split, with the header and body going into object members,
but I also want header() and body() replaced with simple accessors
*only for this object*. And I want to do it easily.
Okay, I see where this is going. You want something like...
package Mail;
use base qw(Class::Object);
sub header {
my($self) = shift;
$self-{header} = $self-_parse_header;
$self-sub 'header', sub {
my $self = shift;
if(@_) {
$self-{header} = shift;
}
return $self-{header};
};
return $self-{header};
}
sub body {
...similar to header...
}
my $mail = Mail-new;
print $mail-header;# calls the full Mail::header
print $mail-header;# calls the simple accessor
Right, I can see how that would be hard to pull off using normal
inheritance. Object inheritance gives you fine grained control over
overriding individual methods for individual objects. Clever!
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN
sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN
SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern
scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn
SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
- End forwarded message -
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
This is my sig file. Is it not nify? Worship the sig file.
http://www.sluggy.com
Re: Anyone actually experienced with object inheritance?
On Mon, Jul 02, 2001 at 12:59:51PM -0700, David Whipp wrote: Its not quite the same thing, but Java does have the concept of anonymous classes (it names them 'inner' classes): Is Perl6 going to have a similar concept? Are they really necessary? You can get the same effect so many other ways in Perl already, inner classes seem to be a way around alot of Java's BSDM features, like interfaces. Of course, if you REALLY want them I'm sure I can write a perl5 module to pull them off. ;) Seriously, give me an example of how you'd like to see it work (or point me at some docs) and I'll see what I can do. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One my anus yearns now warm paste fills me happily saturday morning -- imploded
Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
On Mon, Jul 02, 2001 at 04:18:31PM -0400, Michael G Schwern wrote:
On Mon, Jul 02, 2001 at 12:59:51PM -0700, David Whipp wrote:
Its not quite the same thing, but Java does have the concept of
anonymous classes (it names them 'inner' classes): Is Perl6 going
to have a similar concept?
Okay, maybe I don't understand anonyous classes, but isn't this pretty
much the same thing:
package Foo;
{
package My::Anon::Class;
@ISA = qw(Whatever);
sub new { ... }
sub bar { ... }
}
sub new {
my($class) = shift;
my $anon = My::Anon::Class-new;
...
}
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
How can I stoop so low? Years of practise, that's how. It's been hard
going but now I can stoop lower than a pygmy limbo dancer.
-- BOFH
Anonymous classes (was Re: Anyone actually experienced with object inheritance?)
On Mon, Jul 02, 2001 at 05:04:23PM -0400, John Porter wrote:
Michael G Schwern wrote:
Are they really necessary? You can get the same effect so many other
ways in Perl already,
That is a very unhelpful attitude.
We've already got everything and the kitchen sink proposed for Perl 6.
Remember, somebody's got to write all this.
Give me data aggregation by inheritance
Oooh, now that would be useful.
namespace scoping
Err... something like lexical namespaces? my package Foo?
package Foo;
{
my package Bar;
sub baz { 42 }
}
print Bar-baz; # *bt* Bar only exists in its scope.
Interesting, but do we need them in 6.0?
interfaces
Pretty much covered by our discussions of method signatures and typing
earlier, no? Yes, we need them.
and then I'll grant that inner classes are easy to tack on.
You can always do this right now:
package Whatever;
sub foo {
my $self = shift;
my $obj = Class::Object-new;
$obj-sub 'bar', sub {
blah blah blah
};
$obj-sub 'yarrow', sub {
more blah
};
...now $obj acts like an instance of...
...an anonynous inner class...
}
When $obj goes away, all trace of its class goes away (thanks to a
helpful DESTROY method). Same effect as an anonymous inner class in
Java. One instance, methods defined on the spot, can't access it from
outside foo(). The syntax could use a little work...
And, of course, you can get the same effect if you don't sweat the
protections by just defining one package inside another.
Uh oh. I smell another BDSM OO vs Happy-Go-Lucky OO argument brewing...
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Re: Anyone actually experienced with object inheritance?
On Mon, Jul 02, 2001 at 05:09:58PM -0400, John Porter wrote:
Perhaps this could be done by allowing to attach a name to q
lexical scope; perhaps this could be conflated with normal labels.
my package Foo {
sub bar { ... }
}
perhaps?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Jesus hates me.
http://www.unamerican.com/
Re: Per-object inheritance in core a red herring?
Please look at Class::Object before responding. URL below. On Fri, Jun 29, 2001 at 06:36:31PM -0400, John Porter wrote: [EMAIL PROTECTED] wrote: Any sufficiently encapsulated hack is no longer a hack. Who said that? I think it's wrong. Me. Any sufficiently encapsulated hack is no longer a *naked* hack. So what. As long as the hack has no effect outside its little bubble of encapsulation, its no longer a hack as far as the outside world is concerned. Its a simple matter of interface perspective. You shouldn't be relying on an object's reference. ref $obj eq 'Some::Class' wrecks subclassing, ref($a) eq ref($b). That's generally bad. Consider the following real world scenario: # Shop::Video represents a VHS, DVD or Laserdisc. $video = Shop::Video-new($video_id); So is ref $video eq 'Shop::Video'? Nope. Shop::Video-new() is a factory method. It returns either a Shop::Video::VHS, Shop::Video::DVD or Shop::Video::LD object depending on if the $video_id refers to a VHS, DVD or Laserdisc. Those are all Shop::Video subclasses, so they all have the same interface. The caller never has to know any of this. Factory methods are a common design pattern. There are other times when you might have to rebless objects into subclasses unbeknownst to the caller. Adaptor and Proxy design patterns can be easily implemented this way. $a-isa($some_class) $b-isa($some_class) is the correct way to see if two objects have the same interface. What's the trade-off here? It works, its efficient, the hacks are well encapsulated. Having it in the core, in C[++], would be that much more efficient, and that much less of a hack. Maybe the tradeoff is that it wouldn't work. :-) Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT CLASS::OBJECT?! They're NO SLOWER than normal objects, it uses all the normal OO channels, it was very simple and small to implement and it WORKS! Now, right this second, with perl 5. I'll post the URL yet again... http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One conway: unit of mind expansion. One Conway == ~20 lines of Perl code found in $CPAN/authors/id/D/DC/DCONWAY, which gives the sensation of your brain being wrapped around a brick, with kiwi juice squeezed on top. -- Ziggy
Class::Object (was Re: Multiple classifications of an object)
On Wed, Jun 27, 2001 at 01:00:40PM -0700, David Whipp wrote:
For the distinction between methods vs members, I don't think
we have to stray too far from perl-is-perl. Afterall, we already
know that foo is a function and $foo is a scalar. So from an
implementation perspective there's no problem giving methods
and members a separate namespace. Its just a syntax issue ;-).
We already have a sub keyword; and one of its parameters is
the name of the function. Allow that paramter to be a hard
reference to an object, and you've got a way of defining
object-level functions (members are objects):
sub $foo.{bar} { ... } #? === sub $foo.bar { ... } ?
To read the function associated, you can use a property sub:
$foo.{bar}.sub # returns the subroutine.
calling a property can pass a value, and parentheses are optional:
$foo.{bar}.sub { ... } # context says {} is subroutine composer
So the correspondance, foo $bar === $bar.foo, is maintained.
Now I just need to work out the meaning of sub $foo {}.
I can do you one better. I can make this even more elegant and I can
make it work in Perl 5 and work just as fast as normal objects.
Observe. Nothing up my sleeve...
package Class::Object;
our $counter = 0;
sub new {
my($proto) = shift;
my($class) = ref $proto || $proto;
my $obj_class;
if( ref $proto ) {
$obj_class = ref $proto;
}
else {
$obj_class = $class.'::'.$counter++;
@{$obj_class.'::ISA'} = $class;
}
bless {}, $obj_class;
}
sub sub {
my($self, $name, $meth) = @_;
*{ref($self).'::'.$name} = $meth;
}
package main;
# Generate an object, give it a method called 'foo'
my $obj = Class::Object-new;
$obj-sub('foo', sub { return FOO, I SAY!\n });
# Generate another object, give it a different method called 'foo'.
my $another_obj = Class::Object-new;
$another_obj-sub('foo', sub { return UNFOO!\n });
# Get copies of those methods back out, just like any other.
my $obj_foo = $obj-can('foo');
my $another_foo = $another_obj-can('foo');
# Same names, same classes, different methods!
print $obj-foo;
print $obj_foo;
print $another_obj-foo;
print $another_foo;
print Yep\n if $obj-isa('Class::Object');
print Yep\n if $another_obj-isa('Class::Object');
# $obj-new clones itself, so $same_obj-foo comes out as $obj-foo
my $same_obj = $obj-new;
print $same_obj-foo;
That's basically what you want, right?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
Re: Class::Object (was Re: Multiple classifications of an object)
Oh yeah. Look at Class::Classless. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Per-object inheritance in core a red herring?
You are to chop down the largest tree in the forest with... A HERRING!
I've been following this whole per-object inheritance thing, .ISA,
etc... and one thing keeps coming to mind.
Why does this have to be in the core language?
First, its a relatively obscure feature. Per-object inheritance isn't
something most people even know about much less can think of a good
way to use. Before the Self crowd carves me up for dog food, it
doesn't mean its not an interesting and useful feature, it means its
unlikely to get used much. Compared to, say, threading.
Second, and perhaps more importantly, we can do this perfectly well
with a module. No hacks, no tricks, no filters. Class::Classless is
one implementation (complete, but a little convoluted), Class::Object
is another (cleaner, but not complete yet).
Class::Object uses the mini-class technique (ie. auto-generated
classes that aren't much more than an @ISA and a place to stick
methods) which is fine. In fact, its wonderfully elegant! Since they
work entirely within perl's OO system *without* an autoloader, they're
just as efficient as any other object. Object inheritance can be
gotten simply by manipulating @{ref $obj.'::ISA'} (encapsulated, of
course). One class, one object. It works, its efficient, it uses
existing syntax.
The rule of thumb has always been if you can do it in a module, don't
put it in the core. Well, we can do it in a module. Work on the
module, don't complicate the core.
PS It also means we don't have to wait two years for Perl 6 to be able
to use it!
PPS A Class::Object proof-of-concept is en route to CPAN.
http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz if its not
there yet.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
-- Ziggy
Re: Multiple classifications of an object
On Mon, Jun 25, 2001 at 11:44:06AM -0700, David Whipp wrote:
When you blass an object in Perl, you give it exactly
one type. The @ISA variable allows that type to refer
to many other classes as the inheritance tree. @ISA
is a list, but ref($obj) isn't. This means that you
sometimes have to create a lot of useless classes to
work around this limitation.
...
Can anyone see any problems with making Cbless and
Cref work with lists? Cisa is not effected.
I don't know if this is the answer. Lemme dig out Design
Patterns... okay, the Bridge pattern addresses this. If you look at
Male and Female to be implementations of the Person class, rather than
subclasses, things slip in easier. I'm not going to go into the
details, look at Design Patterns Gamma, Helm, Johnson and Vlissides
pp 151-161
Another way to address this is delegation instead of inheritance.
Male ISA Person and Female ISA Person, but Employee is not. Instead,
Employee HASA Person. Each Employee object contains a Person object.
So, for example, you might do this...
package Employee;
sub name {
my $self = shift;
$self-{_Person}-name(@_);
}
which delegates any calls to Employee-name off to Person-name.
That way, Employee doesn't have to know if the Person is Male or
Female.
There are lots of tricks you can do with autoloaders and such to make
this process much easier. Delegation is really good for handling
things that inheritance makes complicated.
We might want some magic to ensure 'ref($foo) eq bar' still works
as expected.
Oooh, I've had to do things like that in the past, usually to keep
backwards compatibility with a wonky interface. A function which
returns an overloaded string that can equal many things.
Alternatively, it returns a superimposed scalar. ;) Not something you
want to have to do by choice.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Our business in life is not to succeed but to continue to fail in high spirits.
-- Robert Louis Stevenson
Re: Multiple classifications of an object
On Mon, Jun 25, 2001 at 12:05:42PM -0700, Peter Scott wrote:
In Perl5 I am forced to create 4 new classes:
Employed_Male, Employed_Female, Unemployed_Male,
Unemployed_Female. The combinatorial explosion can,
well, explode!
What's wrong with multiple inheritance?
You get a maze of twisty subclasses, all slightly different. And
every time you add a new type they all have to change. Consider what
happens if you added a new Person subclass, 'Other'. Now you need
Employed_Male, Employed_Female, Employed_Other, Unemployed_Male,
Unemployed_Female, Unemployed_Other. You can see how this will
rapidly get nasty.
Of course, you *could* write Employee as a factory, generating the
necessary subclasses on the fly and blessing the new object into them
as needed...
package Employee;
foreach my $sex (qw(Male Female Other)) {
@{'Employee::'.$sex.'::ISA'} = qw(Employee $sex);
}
but delegation is probably the way to go.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
purl Hey, Schwern! THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING-
LIGHTENINGBEASTASAURSOPOD BEHIND YOU! RUN, BEFORE IT GAFLUMMOXES YOUR
INNARDLYBITS!
Re: Multiple classifications of an object
On Mon, Jun 25, 2001 at 11:36:34PM +0200, Trond Michelsen wrote:
The downside is of course that I need to make a small stub for every
single function I want to delegate.
Well, that's relatively simple to automate...
%Delegations = ( foo= '_This',
bar= '_This',
yar= '_That',
);
while(my($meth, $key) = %Delegations) {
*{$meth} = sub {
my($self) = shift;
$self-{$key}-$meth(@_);
};
}
So $obj-foo(@args) becomes $obj-{_This}-foo(@args). Ahh, the magic
of closures.
Wasn't Damian working on something like this? I looked at his
delegation stuff in perl5+i, but it didn't seem to have anything to do
with this sort of delegation.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Embrace polymorphic builtins, for they are cool.
On Mon, Jun 11, 2001 at 09:18:14PM -0500, David L. Nicol wrote: But I'm digressing. What I want to talk about is overloaded builtins. I recently suggested that Cclose be overloaded to make its argument, when its argument is not a filehandle, become read-only. An objection was made to this, on the grounds that homonymous operators are confusing, with eval block and eval string being given as an example of something that is confusing. This post is intended to be a response to that objection. Natural language contains many homonyms. This is rarely, outside of dramatic plots, a problem, as there are other indicators, up to and including requests for clarification, but generally context, to guide us human beings as we apply our common sense to the great questions of What Is Fair and What Is Right without taking wrong turns or digressing into discussions of propagandistic trends in modern journalism while dividing chocolate cake evenly among party guests. Okay? Ceval (string/block) is but one. I'd hold this up as a failure of polymorphic functions. eval STRING and eval BLOCK do completely different things and people associate their behaviors, merits and flaws together because they have the same name. Cdo might be considered another. Another fine counter-example. Who understands all the different things that do() does?? Its particularly bad because of the name. do is about as generic as foo. It could mean anything. overloading Clength(@) to do what beginners expect. This is an example of polymorphism done for good. Why? First, there's a relatively obvious expectation of what length() will do with a string and an array (a hash might be a little less obvious). Second, and much more subtle, is that while the object of the function changes, its basic functionality does not. Its very important. Think of it as a verb (function) and object of that verb (arguments). length() is the verb, a string or array is the object. When acting on a string, you get the number of characters in the string. When acting on an array, you get the number of elements in the array. Basically the same operation, adapted for the object. This is polymorphism for Good. Now look at eval. When acting on a string, it compiles and runs it as code. When acting on a block, it traps any errors and prevents dying. You may be able to come up with some weak analogies between the two, but they're two different functionalities. Different object, same action: ok Different object, different action: not ok close (IO) # closes an open stream, returns # true on success or false on failure, # sets $! on failure close (\$) # overwrites the ASSIGN method of the overly elaborate explaination snipped close. Closing a filehandle means you're no longer going to read and/or write to it (depending on how it was opened). Closing a variable means you're no longer going to write to it... but reading is ok. The analogy is there, but its not a particularly strong or obvious one, and there's the jarring difference that you can no longer read from a closed filehandle, but you can read from a closed variable. You've got to be careful with polymorphism and ensure that you've got strong analogous action in all cases. Not just because its clever or you like the name. This is not to say we shouldn't have polymorphic built-ins (we already have more than you might think) but they must be chosen with extreme care. Some more counter-examples... un/pack() on a filehandle could compress and decompress the file! It might be perfectly logical if un/pack didn't already do something completely different. Some good examples... delete/exists work on both arrays and hashes. delete() completely removes an array/hash element, exists() checks to see if an array/hash element has been populated (even if its undefined). The details might start to diverge a bit, but the basic meaning doesn't change. Homogeneous operators are potentially confusing (just because English has homonyms doesn't mean its not confusing) but not all polymorphic functions are homonyms. Find the ones which retain their basic meaning across all their objects, those are the good ones. PS delete() and exists() are also polymorphic, as is reverse(), chomp(), chop(), goto() and die(). There are probably more, but I can't think of them, probably because they mesh so well we don't even think about it. You could consider functions which have default arguments as polymorphic, then there's lots and lots of polymorphism in Perl. But I digress. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One kiloconway: unit of extreme mind expansion. Equal to 1024 conways, one kiloconway gives the sensation that all of the quantuum
Re: Properties and stricture
Ok, I've realized a few things. 1) There's two sorts of type-checking going on here. Compile-time and run-time. 2) Run-time type checking is fairly easy and imposes few limitations. In fact, you can even do it now through ad hockery. 3) Compile-time type checking is a bit harder. Any module/class which wishes to be compile-time checked must not have its *signature* altered at run-time. By signature I mean the methods, functions, global variables and inheritence tree of a strict class must be defined at compile time. All the external stuff. The internals can change at any time. This means you can still AUTOLOAD, so long as the function signature is defined beforehand. But you can't use AUTOLOAD to define brand new methods of the strict class. eval STRING still works, just so long as it doesn't modify a strict class. It can call methods of a strict class, and this is all checked at the eval's compile-time. Dynamic method calls ($obj-$method()) works, it will be run-time checked. Subroutine refs, same thing. 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. Automatic method generation will work, but only for those known at compile-time. Which is fine. So mod_perl, Apache::Registry, AutoLoader, Class::Accessor, Exporter, Template Toolkit can all still work, with a bit of reworking. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One My feet hurt... with destiny! http://sluggy.com/d/010204.html
Re: Properties and stricture
On Wed, Jun 06, 2001 at 10:28:41AM -0400, John Porter wrote: Michael G Schwern wrote: It will have to go for strict classes. @ISA will have to be locked. strict classes? strongly typed class? Can a man make up gibberish in peace? ;) Basically, any class which wants to be type-checked 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... Yes, very true. I missed that entirely. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: Properties and stricture
On Wed, Jun 06, 2001 at 07:06:49PM -0700, Dave Storrs wrote: But if we did, how could we hope to get a good new Star Trek series? : You're still hoping for a new, good Star Trek series??? You must be a Cubs fan. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If you'll mount me, I'll let you bomb Canada until they swoon.
Re: $foo.Foun (was Re: Properties and stricture)
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote: BD languages What's BD? Bondage and Discipline, scum! You're not a good enough programmer to be trusted not to make mistakes! Now drop and give me fifty! -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Now I fight for wisdom. http://sluggy.com/d/010204.html
Re: 1 until defined(getvalue()); return $^d;
On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote:
Since this thread made it into this week's Official Perl6 Summary,
here goes a defense of Cit as a shorthand for the thing that last
had Cdefined or Cexists queried of it.
Ya know, I hate myself to admit it but I'm liking this idea. The one
that got me was this:
foreach my $uid (@users) {
print it if is_luser($uid);
}
I like the way it reads. If 'it' is read-only it limits the potential
complications. Yes, you can do similar things with grep...
print grep is_luser($_), @users;
but TMTOWTDI.
I am a bit worried about having to do so much pointer copying to
support this feature.
PS 'it' could take many forms
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Monkey tennis
Re: Properties and stricture
On Tue, Jun 05, 2001 at 11:51:53AM -0400, John Porter wrote:
Perl has strong typing; it just has a different notion of
what a type is. The types in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Prototypes don't work on methods. And I wouldn't hold them up as
being anything but a mediocre hack. Its not really type checking.
Of course, there's Attribute::Types for things like that.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
sort God kill 9, @ARGV;
Re: Properties and stricture
On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote: But in the end, I'm most concerned that my code is correct. Having the compiler check everything it can possibly check for me is really a requirement for that. Compile time type checking of method signatures is really helpful as well. What you count as Java's greatest strength, I count as Java's greatest weakness. You have to remove *alot* of language features to get down to the point where its predictable at compile time. 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). 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. 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). 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. As an interesting side-note, there are functional languages out there which do strict type checking *without* you having to explicitly declare the types of everything. I'm fuzzy on the details... I believe its called Implicit Typing, ML and CAML do it. Anyhow, might be interesting to look into. A typing system that just works without you really having to do anything would be very Perlish. Of course, it probably only works with strict functional languages, which is very unPerlish. It got to the point in Java that I would sometimes check in my code without even testing it I was so sure it was correct. I can't imagine ever saying that about Perl. I can't imagine ever saying that about any language! Type checking is nice, but its just one class of error-checking. Doesn't do squat for basic logic errors, for example. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: Properties and stricture
On Tue, Jun 05, 2001 at 07:33:55AM -0700, Dave Storrs wrote:
(By 'strictly', I think you mean 'all methods (etc) are declared
explicitly in code, not generated by AUTOLOAD, etc'. If I'm not
understanding you correctly, please correct me.)
Yeah, pretty much. I put together a proof-of-concept thingy to scan
for constructs which make code unpredictable here:
http://www.pobox.com/~schwern/src/B-Scan-0.01.tar.gz
Couldn't we still have a 'be-super-strict' flag that would throw
warnings upon encountering a construct that would interfere with
compile-time checking? Make it be off by default, of course, but if
people want Perl to help them check this kind of thing, it should be
possible.
Yes, I'm just afraid this sort of thing would expand to engulf all of
Perl. I'm also worried its scope would become far too large.
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.
This is, of course, a drastic example, but these sort of tricks go on
all the time in Perl. Its probably not the cleanest OO style in the
universe, but its Perl's. Any Perl OO idiom which breaks *formal*
encapsulation (as opposed to the informal style we usually keep) won't
work with strict, compile-time typing. One or the other has to give.
I'm running into similar problems trying to put together some sort of
serviceable refactoring tools. Perl's extreme maliability also means
extreme unpredictability, which makes things like strict typing and
automated refactoring less than 100% reliable.
Before anyone gets the wrong idea, I don't think the solution is a
drastic scaling back in Perl's flexibility. I just don't know what
the solution is yet. Maybe it should be possible for a class to
completely seal off its namespace to the outside world on request.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Death follows me like a wee followey thing.
-- Quakeman
Re: Properties and stricture
On Tue, Jun 05, 2001 at 12:46:52PM -0400, John Porter wrote: Michael G Schwern wrote: Prototypes don't work on methods. And I wouldn't hold them up as being anything but a mediocre hack. Its not really type checking. It's not just prototypes. % perl -e '$r=\%h; print @$r' Not an ARRAY reference at -e line 1. This isn't type-checking (semantical arguments /dev/null), its more like basic syntax. You don't want to try holding up prototypes and dereference checks to Java's typing system and try to claim its in the same league, or even the same sport. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One It sure is fun masturbating. http://www.unamerican.com/
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:42:01PM -0400, John Porter wrote: You don't want to try holding up prototypes and dereference checks to Java's typing system and try to claim its in the same league, or even the same sport. As I said before, it boils down to the fact that perl's notion of a type is different from other languages. It *does* check these types, and it casts very opportunistically. Ok, let's call them types for a moment. A) You can't meaningfully define new types. This makes it pretty much useless as a typing system. B) The system's only awareness of OO is that objects must be references, otherwise anything goes. Even if prototypes worked on methods you still couldn't specify which objects you want. C) To call Perl's differenciation between scalar, array, etc... references a typing system is like calling C's differenciation between structs, arrays and scalars a typing system. You may be able to draw analogies, but they don't serve the same purpose. Yes, there is some actual type casting going on between strings and numbers and various internal scalar types, but its mostly behind the scenes. What Perl does with references is basic sanity. Using a scalar reference as an array ref doesn't really have meaning, for example. A real typing system is a layer of *additional and arbitrary* (from a purely syntactical PoV) enforcement on top of this. Typed data could mix and could have meaning (a variable of type Velocity could be used where a Price is wanted, they're both numbers) but you disallow it because it doesn't fit in with the reality you've defined in your program. Perl doesn't have a built-in typing system comparable to what most of other languages have, and its not healthy to delude ourselves into thinking we have one. The lack isn't much of a problem, Perl doesn't really need it and it causes all sorts of complications (as noted in the other threads). Wouldn't hurt to have one, though. I have a feeling we're arguing somewhat different things here. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:37:11PM -0500, Garrett Goebel wrote:
Before anyone gets the wrong idea, I don't think the solution is a
drastic scaling back in Perl's flexibility. I just don't know what
the solution is yet. Maybe it should be possible for a class to
completely seal off its namespace to the outside world on request.
How do you determine the outside world? Out of the package's namespace or
out of the file's?
It would have to be both. Nothing outside the namespace could peek at
or modify package data in that namespace, and no outside lexical
context would be allowed to use that namespace.
So if Foo.pm defines class Foo as being armored, Bar.pm couldn't do this:
package Bar;
{
package Foo;
print $Secret_Foo_Variable;
}
Of course, there's problems of order of definition. What happens if
Bar.pm is loaded before Foo? Dunno.
When you say seal off its namespace, do you mean that the symbol table
would be thereafter static... or that only code within the predeclared scope
could mess with the symbol table?
Only code inside that namespace could mess with stuff in that
namespace. It can all still change, but the changes cannot come from
outside its package.
What about lexicals?
Lexicals already have their own privacy rules.
How about:
package_name.finalize();
finalize package_name;
This is a different concept.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I knew right away that my pants and your inner child could be best friends.
Re: Properties and stricture
On Tue, Jun 05, 2001 at 01:05:45PM -0700, Daniel S. Wilkerson wrote: 2 - You can't make a user defined type, like classes in Java, that are compile time checked. Well, you can sort of: Attribute::Types. But that's not what John is talking about. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One gigaconway: a hypothetical unit of mind expansion, so disturbing it is likely to change the fundemental nature of the universe. Some contend that gigaconway events, while rare, are much cheaper to produce than antiprotons, nuclear weapons or even XML specifications, and start at US$60,000 each. If you believe gigaconway events are indeed possible, please send your tax deductable contributions to: The Conway Fund, c/o Yet Another Society http://www.yetanother.org/ -- Ziggy
Re: Properties and stricture
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote: Someone please tell me what automatic method generation is exactly. Its the generation of large numbers of similar methods which would otherwise be really tedious to write out by hand, such as accessor methods. Without this, object-oriented programming would be hand-cramping tedium (or an elaborate exercise in editor macros). Its also very useful for generating complete sub-classes on the fly. Class::Accessor and Class::MethodMaker are two modules which I can think of off the top of my head that do this in Perl. Class::DBI absolutely depends on it. Java trips rather badly on this technique. For some elaboration... http://www.pobox.com/~schwern/papers/Why_I_Am_Not_A_Java_Programmer/why.pod in particular the section entitled No dynamic method generation For a really elaborate elaboration... http://www.pobox.com/~schwern/papers/Closures_and_Accessors/Closures_and_Automated_Accessors.txt -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm not actually Kevin Lenzo, but I play him on TV.
Re: Properties and stricture
problems, and, in effect, increases the mental power of the race. Funny, there are a few cases where I'd like to have type-checking, but most of the time I see it as unnecessary work. Then again, my notion of typing comes from C++, a language devoted to unnecessary work. I suppose, this is exactly why it will be optional. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: Properties and stricture
On Tue, Jun 05, 2001 at 02:39:33PM -0700, Daniel S. Wilkerson wrote: Thank you, that's what I thought it might be. This can be done at compile time with a two-stage compilation. The first one writes the code that the second compiles. Then the checking can be done during the second stage. Yeah, but that's yicky and limiting and involves temp files and you have to know everything you want to generate before you run the program. Anyhow, I think we can save the technique even with strict-types. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One GOD made us funky!
DANGER! ADVOCACY! (was Re: Properties and stricture)
On Tue, Jun 05, 2001 at 05:49:30PM -0400, John Porter wrote: By preventing lots of little gotchas, you free the mind to pay attention to what it is doing rather than the most minute details of how to do it. This is a quite powerful effect. Interesting you should mention this. It is, without a doubt, the main reason we like to program in Perl, instead of in low-level languages like Fortran and Java. And it may explain why programs written in Perl -- dynamic, weakly-typed though it be -- are at least no more buggy than programs written in low-level languages. Yes, this is something I've been meaning to investigate somewhat in the Why I Am Not A Java Programmer thing, but didn't really feel confident enough about to get into. By reducing the amount of code you need to write, very high-level languages can drastically reduce bug counts. This is partially because programmers tend to have a constant bug-rate per Kloc (thousand lines of code), so less code means less bugs. Its also because smaller code means less to remember and easier to keep in your head. Of course, any low-level language can achieve similar wins with sufficient libraries/classes to raise its level of encapsulation to that of a high-level language, to a certain extent. Obviously, trying to drag assembler up to the level of Perl wouldn't quite work. Then again, you can view Perl as just a bit abstracted interface to C... Removing incidental work also helps. Explicit type-checking can be seen as just that. Its not strictly necessary, you can strip it all out and the code will run exactly the same (with a bit of hand-waving towards type-casting magic). Other things you can strip and/or automate are memory allocation, privacy rules, accessors, etc... None of these things directly effect your real goal, which is the encoding of a reality onto bits. Now, this same argument can be taken too far. Documentation, tests, comments, whitespace... these too are incidental. But strip them at your peril! You must draw a personal line and decide for yourself what is necessary and what is just paperwork. The problem with Java is they've drawn the line for you. You must use strong types, you must set up privacy rules, you must write all your code by hand, you can't allocate your own memory, etc... The problem with Perl is you can only draw the line at certain places. Privacy? Take it or leave it. Strong types? Ummm, sorry. But I think we've strayed into the topic of advocacy. Interesting advocacy, nevertheless. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I am not one of those stupid moron who don't know what I am doing. I know about FDA. FDA raids hundreds of small businesses every year that deal with alternative medicine or therapy. They take away your computer, seize your $200,000 inventory, and drive your company totally out of business in no time if they ever approach you. --Alex Chiu, Immortality Guy
Re: Properties and stricture
On Tue, Jun 05, 2001 at 03:29:02PM -0700, Daniel S. Wilkerson wrote: It would be interesting for someone to measure that, however I doubt that it is so. Oh, and look at what just showed up in my mailbox! - Forwarded message from Tony Bowden [EMAIL PROTECTED] - I think we should start measuring our rate of change on the Maintainability Index over time: It's quite a simple process. For each 'module' of code, we just take: 171 - 5.2 * ln(aveV) - 0.23 * aveV(g') - 16.2 * ln (aveLOC) - 50 * sin (s= qrt(2.4 * perCM)) where perCM= the average percent of lines of comments per module, aveLOC = the average count of lines of code per module aveV(g') = the average extended cyclomatic complexity per module=20 aveV = the average Halstead Volume V per module. For anyone not familiar with the latter concepts, the cyclomatic complexity (CC) is simply calculated as: CC = E - N + p Where for a connected graph of the module that shows the topology of control flow within the program, E = the number of edges of the graph N = the number of nodes of the graph p = the number of connected components and the Halstead Volume is simply HV = N * (LOG2 n) where N = N1 + N2 n = n1 + n2 where n1 = the number of distinct operators n2 = the number of distinct operands N1 = the total number of operators N2 = the total number of operands=20 (This is spelt out in much more detail at http://www.sei.cmu.edu/activities/str/descriptions/mitmpm.html) This should be fairly simple to implement (I'll leave that as an exercise for the reader), and could probably be used as a starting point for CPANTS. --- End forwared message (That was a joke, BTW) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let me check my notes. http://www.sluggy.com
Re: $foo.Foun (was Re: Properties and stricture)
On Tue, Jun 05, 2001 at 04:38:24PM -0500, 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? Can't you hear the low roar from the strong-typing argument coming from the thread next door? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Stupid am I? Stupid like a fox!
Re: 1 until defined(getvalue()); return it;
On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote: while pseudocoding something I realized that it would be really cool if there was another magical default shelf, like $_ or _ but subtly different, that stores, if lexically used, the object of the most recent defined or exists -- or maybe even the most recently referred to scalar, just the way it works in English. it would change much more often than $_ does. *quiver* Please god no. Its difficult enough to follow the twists and abuses of $_ when reading code. That aside, could you put together a code example of what this wins? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: 1 until defined(getvalue()); return it;
On Wed, May 30, 2001 at 02:39:57PM -0500, David L. Nicol wrote: ... defined $thing and return $thing ... when $thing is a complex expression, a temporary variable must be explicitly assigned. it holds the place in my pseudocode. Hmmm, if $thing is a complex expression I wouldn't want to shove it all onto one line. defined(some_really * complex + expression with function(calls)) and return $IT; doesn't win you much over: my $it = some_really * complex + expression with function(calls); return $it if defined $it; You save a few characters. Take a typing class. ;) Maybe it makes one-liners flow better? PS I'm trying REALLY hard to not say AGGGH! KILL IT NOW BEFORE IT GETS LOOSE! -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One And it's made from all-natural baby skin, so you know it's good for the environment. http://www.goats.com/archive/000606.html
Re: 1 until defined(getvalue()); return it;
On Wed, May 30, 2001 at 02:54:27PM -0500, David L. Nicol wrote: small incremental improvement to [read|writ]ability writability: one less variable name to have to remember not to collide with I think you have this one backwards. This is one giant, ambiguous global variable whose value and meaning changes constantly from statement to statement. Think $_ but worse. You have to constantly worry about adding in a new statement for fear it will alter the meaning of $IT and break code below you. readability: keyword it means look at very recent code, instead of starting at the top of the block and reading down to find what $foo is (trivially solvable by reading backwards...) This is better solved by using smaller scopes/subroutines and meaningful variable names. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 11:26:36AM +1000, Damian Conway wrote: Not. The run-time property is set on the *value* in $Foo, not on the variable itself. Change the value, change the properties. Ok, that makes me happy. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: 'is' and action at a distance
Let me see if I understand this... $Foo is true; # Meanwhile, in another part of the city... $Foo = 0; print My spider sense is tingling if $Foo; Does that print or not? I can see the need for wanting to disassociate truth from value (I've wanted it myself) but if $Foo remains true, even after I've assigned a false value to it, then yes, that does count as action-at-a-distance and is probably a Bad Thing. However, if assigning to $Foo clears the eariler assertion of truth, then there's no problem. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One You see, in this world there's two kinds of people. Those with loaded guns, and those who dig. Dig. -- Blonde, The Good, The Bad And The Ugly
Re: Exegesis2 and the is keyword
On Tue, May 15, 2001 at 03:02:44PM -0700, Nathan Wiger wrote: The only worry/problem/etc that I wonder about is the potential overuse of the is keyword. It is a very nice syntactic tool, but when I see something like this: $*ARGS is chomped; I wonder if that wouldn't be better phrased as: autochomp $*ARGS;# $ARGS.autochomp Is that autochomp as a keyword or autochomp as an indirect method call on $*ARGS? The thing I worry about is this: I don't think actions should be declared using is, necessarily. $STDERR is flushed; $var = $ARGS is read; $STDOUT is printed to Hello, World!\n; This could be argued 'round and 'round as to what's an action and what's a property. 'chomped' and 'flushed' make sense as properties as they are descriptive. You're setting a property which the variable will take into account in its actions. Whereas things like 'read' and 'printed' are immediate actions. I suppose the best distinction is right there in your example. flushed and chomped don't do anything immediately, whereas read and printed do. TMOWTDI I suppose. Without the extra new ambiguity. Thoughts? Put down the indirect object syntax and step away from the keyboard with your hands up! ;) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: what I meant about hungarian notation
On Sun, May 13, 2001 at 11:37:01PM -0500, Me wrote:
Yes. But I'm not sure that:
# ordered
@array = (1, 2, 3, 5, 8);
# unordered
%hash = (Fred = 22, Jane = 30);
is more or less typical than:
# unordered:
@array = ('England', 'France', 'Germany');
# ordered:
%hash = (Name = 'Ralph',
You're right, the want of an ordered hash is common, but definately
not in the majority (and its quite a bit slower and eats more memory).
There have been numerous proposals for giving various easy ways to
declare the sort order for a hash. http://dev.perl.org/rfc/124.pod is
one. The idea of variable attributes is another.
When all the smoke clears, it will be relatively simple to declare an
ordered hash probably on the order of adding a single word to its
declaration. Whipping up a storm about it is unnecessary.
11 normal people (perl beginners) have responded
to this so far.
While there is merit in taking beginners's needs into account, it is
not wise when designing a language to alter features just for
beginners. As elitist as this may sound, they are beginners and will
advocate short-term solutions. They don't quite know what works best
in the long run.
Also, I don't equate beginners with normal (perhaps loud). After
all, beginners don't stay beginners for long. For every beginner now
there will be one less in a year (either they've gotten better or
they're doing something else). The only new font of beginners is
brand-new programmers. Again, they should be taken into account and
the learning curve banked for speed as much as possible, but you don't
design a language around them.
For most of your programming life, you are not a beginner.
Anyhow, this is how you get things like BASIC.
(PS 11 people isn't a statistic, its a night at the pub)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
Re: Perl, the new generation
On Fri, May 11, 2001 at 01:55:42AM +0100, Graham Barr wrote: On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote: By far most of my use of typeglobs is making aliases, and then mostly for code: *color = \colour; I would say that probably the most common use now for typeglobs is from the IO:: modules. Which are created with gensym so they are anonymous. Personally, I use typeglobs mostly to autogenerate repetitive methods without an autoloader: *method = $closure; but this should definately have a direct analogy in Perl 6 so I'm not worried. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Your average appeasement engineer is about as clued-up on computers as the average computer hacker is about B.O. -- BOFH
Re: A proposal for more powerful text processing to be built in to Perl: Flex and Pushdown Expressions.
On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote:
Flex - Put all of flex right into Perl.
Having a lexer in Perl is useful, but does it have to be built into
the core? There already are several lexer modules for Perl 5
(Parse::Lex, Lex, Parse::RecDescent...) and while they may be
benefited by certain small, sharp additions to Perl, they do rather
well outside the core (and it means the Perl 6 developers don't have
to add Yet More to their plate).
Pushdown expressions - Slightly more powerful regular expressions.
This modifier would require that all parentheses-like literals: () []
{} pair-up in order for the trailing one to match.
That might be handy, its been getting easier to do this sort of thing
in a regex but its still a bit less-than-obvious. Non-obvious enough
to require its own module: Text::Balanced.
Can't comment on the particular syntax you've chosen, but the idea
sounds useful.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
GuRuThuG make a channel called #Perl, and infest it with joking and
fun it doesnt make alot of sense.
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
On Fri, May 11, 2001 at 10:56:38AM -0700, Nathan Wiger wrote:
Well, I think we should take a step back and answer a few key questions:
1. Do we want to be able to use Perl 5 modules in a
Perl 6 program (without conversion)?
This would be desirable as it would allow people to continue to use
unconverted code (particularly the wealth of CPAN code) without having
to wait. It would probably speed adoption of Perl 6. But while the
translator may be able to deal with this, I don't want to add to the
flock of seagulls already hanging around their necks.
I'd say this is it would be nice if we can find an easy way to do it.
2. Do we want to be able to switch between Perl 5 and
Perl 6 in a single file (by using module to dictate
P6 and package P5)?
I'd say no. Although it would allow for incremental upgrades of
legacy modules, the idea of mixing two versions of Perl in a single
file makes the short hairs on the back of my neck stand up. It will
be extremely confusing.
It may also encourage small enclaves of Perl 5 rot hanging around in
Perl 6 code for many years with people afraid to touch it. It reminds
me of the continual troubles which had plauged Windows as a result of
leaving old DOS and Win 3.1 code lying around in its guts. Also MacOS
had similar problems by leaving old 68k code deep within its bowels
long after it had converted to PowerPC.
And consider the horrors of using the same variable in the two halves.
Say the Perl 6 part declares a global variable which the Perl 5 code
tries to use (or vice-versa). Or worse yet, sharing a lexical
variable. The Perl 6 part may assign all sorts of weird attributes to
the variable and make assumptions on it that the Perl 5 code is
unaware of/unable to account for. Technically speaking there's
nothing wrong with this (the translator could handle it) but the poor
programmer that has to maintain such a beast!
If the answer to #1 turns out to be yes, then a similar effect can
be gotten by having a Perl 5 module require a Perl 6 module which uses
the same package. Then you can slowly upgrade your module by moving
more and more code off to the Perl 6 file.
3. Do we want to assume Perl 5 or Perl 6 code? If we
assume P5, then we have to look for module somewhere.
I think Apoc 1 made it clear we're assuming Perl 5 and the method to
indicate Perl 6 (at least for modules) is the leading 'module'
keyword.
The specifics of handling scripts remains unknown, but many ideas have
been tossed about including command line flags as well as guessing
based on the name of the perl executable. (ie. symlink /usr/bin/perl
to /usr/bin/perl6. #!/usr/bin/perl6 indicates its Perl 6 code).
If we assume P6, we can look for a number of differences,
such as $foo[1], $foo{bar}, etc to identify P5 code.
I don't like the idea of trying to guess if its perl 5 or perl 6 at
all. A Perl 5 syntax error can suddenly make perl think its Perl 6
and report all sorts of weird errors. That will make debugging a
nightmare.
4. Do we want to be able claim 100% compatibility, or
99% except typeglobs, in which case if *foo is
seen we just drop with Typeglobs not supported?
I think we should table this one until more details of Perl 6 and the
flexibility of its parsing are known.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
-- Ziggy
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
On Fri, May 11, 2001 at 02:22:30PM -0400, David Grove wrote: The largest problem may be in non-compiled modules, perl-only, user-designed. Actually, the largest problem will be *compiled* modules. XS, as it is very chummy with the Perl internals, will flat out not work. Anything that uses XS will have to be re-written outright. Not much that can be helped there. Fortunately, there's plans in place for something much better and better documented. So maintainers of XS modules should be stampeding to convert. Also, they'll know very far in advance that the Day Of Reckoning is coming. Perl-only modules shouldn't have much of a problem. However, some code depends on undocumented features/bugs. We can do our best to replicate the more popular abuses. CPANTS will be in place long before any Perl 6 code is layed down, that will provide a very good metric on how good our compatibility is and where we need improvement. Also, I'll see if I can get the JART off the ground. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If you have to shoot, shoot! Don't talk. -- Tuco, The Good, The Bad And The Ugly
Re: what I meant about hungarian notation
On Tue, May 08, 2001 at 08:21:10PM -0500, David L. Nicol wrote:
What if, instead of cramming everything into scalar to the point
where it loses its value as a data type that magically converts
between numeric and string, as needed, we undo the Great Perl5
Dilution and undecorate references.
There are two very important reasons why $%@ is more than just YA
Hungarian Notation. I believe Abigail pointed this out to me some
time ago.
The first, string interpolation. $ lets Perl be fairly unique in
having a simple way to interpolate variables in strings. Its a fairly
clear distinction between a bare word and a variable.
With the idea of interpolating method calls in strings on the table,
it now becomes rather important to have that $ on objects.
print The $animal.name says: $animal.sound\n;
Of course, we could disambiguate by requiring the () as class methods
will...
print The animal.name() says: animal.sound()\n;
But that leads to the second Very Important Reason. Distinguishing
between object method and class methods. In the above example, it is
not clear if you're calling the method 'name' on the class 'animal' or
on the object 'animal'.
The inevitable clash will happen where a variable name will match that
of a class name and no simple rule can solve it. Object methods
cannot have precedence over class methods else there becomes no way no
call that class method.
I'm sure some set of special, optional disambiguating syntax (similar
to ${var}) could be dragged in, but it seems like you're just trading
one bit of inconsistency for another.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
If you have to shoot, shoot! Don't talk.
-- Tuco, The Good, The Bad And The Ugly
Re: Tying Overloading
On Wed, May 09, 2001 at 02:05:48PM -0700, Austin Hastings wrote: Will it be possible to define pointer classes, a la C++, in a relatively smooth manner? That is, an object R has methods of its own as well as methods belonging to the referred to object? Sounds you're looking for automatic delegation. There's an RFC dealing with this... http://dev.perl.org/rfc/193.pod and a Perl5 module planned, Class::Delegation. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One An official I want James Earl Jones' cock up my ass t-shirt. http://www.goats/com/archive/010303.html
Re: Apoc2 - STDIN concerns
On Tue, May 08, 2001 at 09:44:57AM -0700, Larry Wall wrote:
there seems to be a shortage of three-humped camels.
No wonder we're short, they're rather careless with them...
The Three-humped Camel:
An advertisement once appeared in a Welsh local paper which
read: 'Last - one three-humped camel. Owner desperat.
Reward.' A telephone number was given for people to ring. The
landlord of the local pub was not very pleased. It was his number
that had been given and over 70 people rang him, claiming to
have seen his non-existent camel.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
grep { ref and ref !~ /^[A-Z]+$/ } kill 9, @ARGV;
Re: So, we need a code name...
On Sun, May 06, 2001 at 11:51:27AM -0700, Peter Scott wrote:
durian.
You want to name it after a fruit smelling of dead cows and sewer gas?
durian
n 1: tree of southeastern Asia having edible oval fruit with a
hard spiny rind [syn: {durion}, {durian tree}, {Durio
zibethinus}]
2: huge fruit native to southeastern Asia `smelling like Hell
and tasting like Heaven'; seeds are roasted and eaten like
nuts
I think that's rather descriptive of Perl in general. Its huge, hard
on the outside, soft on the inside, smells really nasty but if you're
brave enough (or dumb enough) to take a bite it tastes wonderful.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
BOFH excuse #229:
wrong polarity of neutron flow
Re: Apo2: \Q ambiguity
On Sun, May 06, 2001 at 10:23:18PM +0200, Johan Vromans wrote: Larry Wall [EMAIL PROTECTED] writes: I won't tell you what I had to go through just to get those two characters into this message, and they're still only in Latin-1. Compose and an average version of X. Hmmm, maybe you can point out the compose key on my keyboard, I can't find it. ;) I know what Larry went through. I had to do quite a bit of work just to be able to type a £ symbol. I wound up remapping my 'option' key (that's 'alt' to you non-Mac people) to £. I still haven't managed to get my xterms to display it right and had to switch from my normal Clean font in emacs because it doesn't support high ascii to Neep. Stupid American Computers aren't quite ready for the Unicode invasion. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Free beer w/riot!
Re: So, we need a code name...
On Thu, May 03, 2001 at 12:32:40PM -0700, Larry Wall wrote: Since it's something underlying Perl, I'd suggest a decrement of Perl, which would of course be Perk. The Java engine would have to be Perj, I guess, which seems fitting somehow. Shouldn't the Java engine be Perk (or perhaps Perc) is that just too fitting? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, Spoon
Re: sandboxing
On Thu, May 03, 2001 at 03:53:53PM -0500, David L. Nicol wrote: the larger question remains, is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? CPANTS will have to try and clunk a sandbox together and I have no illusions about how difficult this will be. On a sane Unix, yes we have chroot. But what about Windows? MacOS? VMS? EEEK! Not withstanding getting into trying to limit things like sockets, disk usage, etc... Sure, Unix has ulimits, ipchains, quotas, etc... but what about the DumbOS's and the AncientOS's? IMHO that should be the indicator of whether Perl needs to provide a particular sandbox feature. If we leave it up to the OS, how many OS's leave no way (or very difficult ways) to do it. And how radically different are the ones which provide it? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One But unluckily most Germans here are too smart. They all speak good English and won't be able to speak German to me. --Alex Chiu, Immortality Guy
Re: sandboxing
On Fri, May 04, 2001 at 09:20:13AM -0400, Dan Sugalski wrote:
Building a good sandbox with resource limits on a VMS system is trivial. I
expect it may even be easier with IBM's big iron OSes.
I'm sure it is. I'm just worried about having lots of:
if( $^O =~ /VMS/ ) {
do some really scarey (to a Unix user) VMS hacks
}
elsif( $^O =~ /Big Iron/ ) {
do some different really scarey hacks
}
etc...
Obviously this will have to be done at some point, but I'd rather it
was encapsulated somewhere. Either inside Perl or in some core
sandbox/Safe module.
It's less trivial with Unix, but not bad. Beats me on WindowsNT,
though I'd bet it's up to the task.
The single-user OSes are more problematic. I don't know that MacOS (before
OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x,
or AmigaOS. (Though for those we can still track memory usage)
I'd prefer that when we think about the cross-platformness of Perl 6
we keep these troublesome OS's in mind as far as considering what Perl
should leave to itself and what it should leave for the OS to decide.
Luckily the security sandbox features are all implementable from
within perl. It's the resource limitation ones that are trickier,
especially CPU time.
Memory limits we should be able to do, assuming Perl 6 continues to
have its own malloc.
CPU usage is a problem... we could provide two similar, but easier to
implement, features. Throttling (by sticking a tiny little sleep
between each opcode) and limited running (ie. kill yourself if you run
longer than X seconds). The latter we might be able to pull of
externally using SIGALRM, but not all systems have that.
Also things like limiting the number of open filehandles and sockets and
limiting network usage could be done inside perl.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
And Solaris must be destroyed.
-- Peter Miller
