Re: RFC 51 (v2) Angle brackets should accept filenames a
Chaim Frenkel wrote:
What does
$foo = "filename";# 1
$bar = "another";
$gaz = "filename; # 2
^ add " here
Does #2 get the second line or the first?
$gaz contains the second line. Otherwise this:
while ('filename'){print;};
won't work. This gets a little hairy, I admit.
Can the contain a function?
Of course. Stick any old list there.
Your example seems to indicate that
it can. But if it is hard for me to parse visually, I'm not sure
how easy it would be for the parser.
This is an implemenation detail. On the other hand, I was hoping that
it would be easy for a human parser. Perhaps it only takes some getting
used to. Like the first time I saw something like:
for ($foo){
/pattern/ next;
print join ' ', /pattern_with_groups/;
};
To my eye angle brackets signify input.
Jon
--
Knowledge is that which remains when what is
learned is forgotten. - Mr. King
Re: RFC 14 (v2) Modify open() to support FileObjects and
Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Allowing URI/URL syntax can perhaps dodge the "portability" issue URLs use / so if user thinks URL they think /. -- Nick Ing-Simmons
Re: RFC 14 (v2) Modify open() to support FileObjects and
In message [EMAIL PROTECTED] Graham Barr [EMAIL PROTECTED] wrote: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: open 'ftp://ftp.perl.org/'; # ftp What user/password does it use Whatever you put in the URL with anonymous as default. open 'http://www.yahoo.com/'; # http will it support cookies, authentication ? No reason why not. My point is that many of these protocols are more complex than I would certain want open to handle. Leave the complex stuuf to those modules and use the API they provide. The suggested syntax does not necessarily conflict with the above - the core might spot the xxx: scheme and try and load an xxx.pm from some well known path and hand off the open to that module. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Let He who taketh the Plunge Remember to return it by Tuesday.
Re: RFC 14 (v2) Modify open() to support FileObjects and
In message [EMAIL PROTECTED] Tom Hughes [EMAIL PROTECTED] wrote: The suggested syntax does not necessarily conflict with the above - the core might spot the xxx: scheme and try and load an xxx.pm from some well known path and hand off the open to that module. To follow up to myself I should add that there is also a second technique that achieves the same result. That is if the core provides a way for modules to register as handlers for certain types of filename - the when you load a module like LWP it would register things like http and ftp that it knows how to handle and open's for those types would be handed off to the registered handler. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Don't speak about Time, until you have spoken to him.
Re: RFC 51 (v2) Angle brackets should accept filenames a
"JE" == Jon Ericson [EMAIL PROTECTED] writes:
@foo = lazy grep
while( @foo ) { ... }
JE What does lazy grep do? How does this apply?
lazy would set the rest of arguments to be lazily evaluated. An iterator
that would call the function until the results are exhusted.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
On Wed, 09 Aug 2000, Chaim Frenkel wrote: BCW Isn't that what the nebulous line disciplines are supposed to handle? Has anyone taken on RFCing line disciplines? I haven't seen anything on them, but everyone seems to be in agreement that we're going to have them. If no one else wants to bite the bullet, I'll at least throw something out that people can object to. (It seems to me that line disciplines, or at least the idea of Perl's implementation of line disciplines, precedes Perl 6. Is this my imagination, or can someone point me to an existing ref?) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Summary of I/O related RFCs
"JE" == Jon Ericson [EMAIL PROTECTED] writes:
JE =item 33 (v1): Eliminate bareword filehandles. (language)
JE No discussion.
I think it carried unanimously.
JE =item 36 (v1): Structured Internal Representation of Filenames
JE (internal)
JE No discussion of the proposal that "Wherever Perl internally uses
JE filenames (in a very inclusive sense: filenames, directory names,
JE whatever) the components of the file name should be stored in a
JE platform-neutral structured format." It also included: "A vague
JE possibility: the proposed internal format could be designed to be
JE flexible enough to present also URLs/URIs."
Are URIs sufficiently descriptive?
JE Chaim also expressed concern that overloading and would create
JE confusion for perl and programmers. I said that they would simply
JE replace the file-globbing mode found in perl 5.
Please adjust that. My concern was for the parsing of some arbitrary
complex expression.
Hmm, I'll offer this as an alternative { hairy expression }
Then the parser can switch to block, and then discover it has to switch
the previously assumed less than into a operator.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v2) Modify open() to support FileObjects and
On Wed, Aug 09, 2000 at 07:26:29PM +, Nick Ing-Simmons wrote: Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Hmm. So that would be open 'file://etc/passwd'; open 'dir://usr/local/bin'; with the default open method being "file"? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 73 (v1) All Perl core functions should return ob
I think, if you look in the archives and the Camel, you'll find that turns out not to be the case. I really don't like putting words in other people's mouths, so I'll refrain. However, I have read comments from Larry and others in Camel and perl5-porters that say something akin to this: 1. Objects should be easily embedded and embeddable 2. But don't you dare lose the functionality of a simple interface That's what I aimed this proposal at, trying to find a way to satisfy both these key requirements. I would *never* ditch #2 in favor of #1, no way. I agree with what Ken said completely: Hey! That sounds like an implementation topic... ;) (The internals should be able to handle this if the language wants it, right?) Let's get the ideas going. The internals might have some honest concerns that cause us to radically rethink this or dump it later. However, let's figure out what we want the language to do first, and figure out how to do it second. Internals aside, I think if we could get the language to do this it would be a tremendous step forward. But that's just my opinion. -Nate
Re: RFC 23 (v2) Higher order functions
=head1 TITLE Higher order functions Sounds good. We should add this to the language. Oh boy, the tricks we can play with this... Hildo
Re: RFC 73 (v1) All Perl core functions should return ob
=head1 TITLE All Perl core functions should return objects Yuck. Why not use the proposed want() and return hash-refs or slices, when appropriate. Hildo
Re: RFC 59 (v1) Proposal to utilize C* as the prefix t
Peter Scott [EMAIL PROTECTED] writes:
At 09:28 AM 8/8/00 +0100, Piers Cawley wrote:
Peter Scott [EMAIL PROTECTED] writes:
At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
I meant that BEGIN, END, and INIT aren't declared as subs at present but
named blocks. I was surprised to discover that they're put in the
symbol
table anyway though.
Check the docs again. [snip]
Four special subroutines act as package constructors and
destructors. These are the `BEGIN', `CHECK', `INIT', and `END'
routines. The `sub' is optional for these routines.
Drat. I propose making it non-optional for
P6. ETOOMANYSPECIALCASES. Any
objections?
But what happens if you want multiple BEGIN blocks?
Same as now:
$ perl -le 'sub BEGIN{print "one"} sub BEGIN{print "two"}'
one
two
It's a bit of a white lie to suggest that they're just plain ol'
subroutines, but at least we're getting closer to the truth.
Woohoo but that's butt ugly. I definitely vote for removing the 'sub
BEGIN {}' syntax rather than making 'BEGIN {}' become 'sub BEGIN {}'
--
Piers
Re: RFC 71 (v1) Legacy Perl $pkg'var should die
Damian Conway sent the following bits through the ether: If you take this, I won't be able to port the forthcoming Klingon.pm module to Perl 6!!! D'oh! ;-) Leon -- Leon Brocard.http://www.astray.com/ yapc::Europe - September 22-24 London - http://yapc.org/Europe/ ... Error 404: .signature generator ran out of tuits
Re: access to pod/doc text by code
Uri Guttman [EMAIL PROTECTED] writes:
some people have mentioned help strings as special parts of a sub
declaration like gnu lisp has. this could be more support for that type
of thing. but i don't want it to be too strange.
Hmm...
sub foo ($$;@) :lvalue
"Documentation string here"
{
# meat
}
You know, I'm not sure if that's ugly or beautiful. Of course, if it
did come into use there'd have to be some way for pod to get at the
docstrings, otherwise we'd end up with something like:
=item foo ARG1, ARG2, [@ARRAY]
Documentation string here
=cut
sub foo ($$;@) :lvalue
"Documentation string here too"
{
# meat
}
Which violates the 'never write stuff more than once' principle.
Err... I still haven't made up my mind about whether I like it though.
--
Piers
Re: RFC 23 (v2) Higher order functions
Peter Scott [EMAIL PROTECTED] writes: =head1 TITLE Higher order functions Well, this should keep the Obfuscated Perl Contest going for at least another decade :-) Whilst still being deeply useful in non obfuscatory contexts too. -- Piers
Re: Error handling
Timeouts, shouldn't be reliant on UNIX. (Although I dont think they
should
be in the language eigther. A system is easily developed using threads.
something which I hope to develop when perl6 is ready...)
I don't understand this paragraph.
As it stands, if you want to have a timeout on a peice of
code/function/whatever.. you need to use eval, $SIG{ALRM}and alarm()
Unfortuantely alarm() doesnt work on windows (and probobally any other
non-posix os)...
I just think that if Perl6 means one thing, and it effects only one great
change. TRUE platform independance should be it
Java is the success it is because of it. And lets face it, we're all here
because we like Perl more, so to paraphrase Larry "Use the stuff that rocks,
and not the stuff that sucks"...
Re: println() ... printbr()
I actually saw this in the newsgroups and thought it was a neat idea. What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
]- I thought 'bout this too, but I think it is not general enought..Why ?
we shall then add this too :
printbr "text";
i.e.
print "textBR";
OR printtd, printtr
print "TDtext/TD";
and many other like this !!!
current way for many prints operators is :
$old = $\;
$\ = "\n";
print ...
print ...
print ...
$ =$old;
OR
{
local $\ = "\n";
print ...
print ...
print ...
}
There shall be easier way in Perl6 for doing this ... I too get really tired
of these "\n" and BR's at the end
ALSO ...
print @array;
must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_BR"};
not like at the moment :
foraeach (@array) { print $_};
=
iVAN
[EMAIL PROTECTED]
=
Fw: println() ... printbr()
- Original Message -
From: "Peter Bevan" [EMAIL PROTECTED]
To: "raptor" [EMAIL PROTECTED]
Sent: Wednesday, August 09, 2000 11:05 AM
Subject: Re: println() ... printbr()
I actually saw this in the newsgroups and thought it was a neat idea.
What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
]- I thought 'bout this too, but I think it is not general enought..Why
?
we shall then add this too :
printbr "text";
i.e.
print "textBR";
OR printtd, printtr
print "TDtext/TD";
and many other like this !!!
current way for many prints operators is :
$old = $\;
$\ = "\n";
print ...
print ...
print ...
$ =$old;
OR
{
local $\ = "\n";
print ...
print ...
print ...
}
There shall be easier way in Perl6 for doing this ... I too get really
tired
of these "\n" and BR's at the end
ALSO ...
Although I agree that a println is a top idea (not only for ease of use
but
also for cross-platform line end characters)
the other versions you mention (printbr etc) have (in my opinion) no place
within the Perl language. Perl is not a cgi language perse, simply one in
which its is easy to implement and as such it should not contain web
specific functions. That is the function of modules (such as the excellent
CGI module, which will do those things you mentioned anyway)...
print @array;
must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_BR"};
not like at the moment :
foraeach (@array) { print $_};
This I totally disagree with. The use of an array in scalar context does
(and I believe should always) return it's length. It is one of Perl's
single
most usful features (in my expirience)...
Re: println() ... printbr()
* Peter Bevan ([EMAIL PROTECTED]) [09 Aug 2000 20:08]:
To: "raptor" [EMAIL PROTECTED]
[...]
print @array;
must work like this :
foraeach (@array) { print "$_\n"};
foraeach (@array) { print "$_BR"};
not like at the moment :
foraeach (@array) { print $_};
This I totally disagree with. The use of an array in scalar context
does (and I believe should always) return it's length. It is one of
Perl's single most usful features (in my expirience)...
Almost. print @array is a list context.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
Q: How do I block warnings?
A: The simplest way is to do: close STDERR; -- perliaq.
Re: RFC 65 (v1) Add change bar functionality to pod
On Wed, 09 Aug 2000, Hildo Biersma wrote:
=head1 DESCRIPTION
Making what's changed in documentation stand out's quite useful,
something I'm coming to appreciate more and more as the RFCs are
flying back and forth. The standard way to do this is to mark the
changed sections with one or more vertical bars on the left margin.
Since changes can themselves be changed, multiple levels of change bar
can occur. This mirrors the common practice in printed documentation.
I have a strong feeling this is a bad idea, because:
- Not everyone is interested in the changes
Some of us have to add them anyway. :-)
The real question is whether the distributed Perl docs will include
change bars.
- Human authors are fallible, and it's easy to forget changebars
Yep. (Although human authors are fallible, and it's easy to ^_foo,
or whatever the current currying syntax is now.)
- We don't want the pods to grow indefinitely
Yep. (I think we keep the last five versions, so we simply filter out
/^\|{6,}/.
Instead, it should be pretty trivial to write a tool that compares the
pods for the current and (any) previous version, generate the
changebars, then writes that out as a separate document - for those who
want it. It may be desirable to include that with the default module
distribution, or we may want to make this a web-based CPAN resource, but
boy this should not clutter up every module out there.
We tried this, too. It worked, but was a little too awkward for our
use. (And failed the requirements in the end anyway.)
FFT.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
John Tobey [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
date() would be more general, and replace both. You can pass it a time
zone, ANY time zone, and it will tell you what time it is in that time
zone.
You're proposing embedding the full power of the Olson TZ library into
Perl core. This is a nontrivial amount of data that changes four or five
times a year. I really don't think this is a good idea. Furthermore, the
only time zone database that can actually do this doesn't use the naming
scheme that you're probably used to.
The JTobey::Date module uses the TZ environment variable (which, I'm
told, is non-portable), the esoteric POSIX routines tzset and tzname,
and some functions from the CPAN modules Date::Parse and Date::Format.
It's far worse than non-portable; it's completely insufficient. The POSIX
TZ syntax cannot represent many real time zones. You need the Olson-style
naming scheme which refers to entries in a fairly large external database
You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
files in /usr/share/zoneinfo. Actually, I do use those indirectly,
though probably non-portably, by localizing C$ENV{TZ}. GNU Libc
takes care of finding the zoneinfo file, but lamentably reparses it
every time TZ changes and CPOSIX::tzset is called.
My module does not parse old-style TZ formats, though some other
module (Date::Format or Time::Zone?) does.
-John
chomp unchomp
Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Hence my println() suggestion. Maybe instead it should be: unchomp; print; Where unchomp ADDS \n to the end of text if it isn't already there. If there is chomp there should be unchomp- the reasons for including it are the same as for including chomp. If chomp is optimized so too can unchomp. Having chomp without unchomp would be like having = but not having = [see note]. Sure you can get by without it- just change the order of the args, but why would you want to? If you have one, the other needs to be there for, if nothng else, parity. BTW I never suggested println() was in the language before. I just glommed onto another thread inadvertantly. Sorry! Ed note- in Programming Perl v2 and v3 this IS the case by the way- the = (ge) logical operator is not in the book! Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: RFC 48 (v2) Objects should have builtin stringifying
Michael Fowler wrote:
I think a stringified reference is worth seeing, moreso than a simple undef,
for debugging purposes if nothing else.
I personally would like to have the stringification of refs be a
symmetric operation, i.e. such a string should dwim in a ref context:
$r = bless {}, 'Foo';
$s = "$r";
ref($s); # True.
$s-bar; # call method of Foo.
I guess that means the deref operator would have be implicitly overloaded
for strings...
--
John Porter
Re: RFC 58 (v1) Cchomp() changes.
Bart Lateur wrote:
chomp() is basically just a "postprocess data coming from a file"
command.
That is way too simplistic. I for one think the current behavior
of chomp() is ideal for its simplicity.
while() {
/foo/ and next; # why bother chomping?
if ( /bar/ ) {
print; # why bother chomping?
}
elsif ( /quux/ ) {
s/$/ (quux found)/;
print; # why bother chomping?
}
else {
chomp;
$x{ $_ . $y };
}
}
--
John Porter
Re: RFC 58 (v1) Cchomp() changes.
On Wed, 9 Aug 2000 09:23:02 -0400, John Porter wrote:
That is way too simplistic. I for one think the current behavior
of chomp() is ideal for its simplicity.
while() {
/foo/ and next; # why bother chomping?
if ( /bar/ ) {
print; # why bother chomping?
}
...
}
It's not "simple". It's confusing. Very often I do stuff like you
describe, and then it turns out that there are cases where I needed the
chomp, and I forgot to add a newline. Argh. Edit the code, and run the
script again. ALWAYS or NEVER chomp is simpler.
If a built-in chomp() takes less than 1% of the time of reading the
line, and I'm 100% sure it can even be far less (cutting of a preknown
length of the a string is pretty damn fast), then why NOT do it?
I'm quite convinced that always implicit chomp can prove to be faster
than doing it for some cases, using an explicit perl keyword for a
fraction of the lines.
Say that we're talking about an overhead of under 0.3% of execution
time, with a turnover point at where less than 20% of the lines need the
chomp. Would you bother?
Note: if we become more liberal in what can mark a line end, say, regex
support instead of a plain fixed string, chomp() as currently used would
slow down quite a bit. An implicit chomp() need not to slow down at all
(i.e. a difference of under a microsecond), since we just found a string
that terminates the line, and thus we already know its length.
--
Bart.
Re: RFC 71 (v1) Legacy Perl $pkg'var should die
On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote:
D'oh! ;-)
Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with
this appropriate name any more.
http://search.cpan.org/search?mode=modulequery=d%3A%3Aoh
OTOH, try this:
$hash{a'b} = 1;
print keys %hash;
--
a::b
That shows that the current situation is not ideal, anyway.
Besides, p52p6.pl can handle the conversion.
--
Bart.
Re: Things to remove
On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote: Perl++ perm -- good old hairy perl, finally under control. Running and ducking, --Steve
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Ted Ashton wrote:
John Porter:
What would be the output of the following program:
$\ = "\n";
$i = 0;
for ( .. -1 ) {
$i++;
last if $i 2;
print
}
If the answer is (as I suspect), "This never prints anything; it goes
into an infinite loop just trying to generate the first number", then
the proposal is absurd and should be scrapped.
By my understanding (which is definitely not very thorough), the output would
be a run-time error.
What error message? "Program never halts!" ???
--
John Porter
Re: RFC 48 (v2) Objects should have builtin stringifying
John Porter wrote:
Michael Fowler wrote:
I think a stringified reference is worth seeing, moreso than a simple undef,
for debugging purposes if nothing else.
I personally would like to have the stringification of refs be a
symmetric operation, i.e. such a string should dwim in a ref context:
$r = bless {}, 'Foo';
$s = "$r";
ref($s); # True.
$s-bar; # call method of Foo.
I guess that means the deref operator would have be implicitly overloaded
for strings...
Bit dangerous there - the string-to-ref operator is left out for a
purpose.
- Would you really want the ref-counting system / the GC system to
scan strings?
- Would like like the effects of pointer arithmetic that
the ref-tostring, edit-string, string-to-ref sequence allows?
Hildo
Re: Things to remove
The discussion of a new name for perl6 is amusing but irrelevant. It's not like this list doesn't get enough traffic already. Thanks for ceasing and desisting. Nat
Re: RFC 73 (v1) All Perl core functions should return ob
At 07:55 AM 8/9/00 -0700, Nathan Wiger wrote: It means a lot more code to write (and debug) for the things that return these objects, and that means parts of perl will be slower, take longer to write, and take up more space. Point taken. I don't think internals should be ignored altogether, just that they shouldn't be the driving force in the language design. Otherwise we'd wind up with something like C. :-) I do agree that the internals shouldn't drive the language (otherwise a crack team of Ninja would've already taken care of that Conway guy... :), but neither can they be completely ignored. I'm just weighing in with a rough estimate of the cost. It's someone else's job to balance that cost with the benefits, but that can't be done without at least some idea of the cost. (I expect Larry's got a good handle on that already, or will when he takes a hard look at the final proposal, but...) One alternative is to add a pragma to implement this, maybe called 'object'. So a person could 'use object' to get the objects flowing everywhere. But again, this is an implementation thing I'd rather save until at least v2, after people have given input on the idea itself. Honestly, I'd rather you put together a general scheme for handling the object/scalar morphing thingie and RFC it, and then we migrate the various functions that people think should do the object thing as time and effort allow. They all might not be in perl 6.0.0 (And what are we going to call the first dev release--perl 6.-1.0?) but could get added in as modules and make it into perl 6.2.0 or something) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 79 (v1) Code which is both executable and POD.
From: "Perl6 RFC Librarian" This allows actual running code to be inserted directly into the documentation for that code. This (if I understand your aim here) points out The Difference between comments and POD, and underlines why POD is not a good way to comment code. Comments can always be assumed to be visible with the code they are about. POD is sometimes visible with the code it is about, but only when viewed in the source. However POD is intended to be viewed without its surrounding code, using a pod-viewing application. You can't have it both ways. Either POD is a comment or its not (and my position is that its not, its documentation.). This RFC would seem to address the issue quite neatly. --Michael
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Tangentialy, can I suggest that a nicer synthax might be -Inf..-1 / 1..Inf, etc. Assuming that we end up supporting full IEEE floats, this becomes the "obvious" synthax, and I find C(-Inf..Inf) to be far more clear then C(..). We've got plenty of puncuation already, thank you very much. Also, can someone please suggest a reasonable implementation of (-Inf...-1)? If not, can I suggest that we require that if one of the arguments to (list) .. s +/-infinity, it be the second one, and additionaly say that a..b is the list , a+1, a+2, ... b if ba, and a, a-1, a-2, ... b if ab. This would allow the full expressiveness of both (-inf..0) and (0..inf) without ever having an infinite starting point to a list. (If a..b where a==b, then we get the list containing only a.) In any case, (-inf...-1) would "obviously" either: begin with the smallest negitive integer representable, or begin with the IEEE -inf. If it begins with the IEEE -inf, then it has to continue with an infinite number of -infs, since -inf+1=-inf (a rule of IEEE arithmitic). Ergo, it is useless to begin at -inf unless perl6 becomes _very_ good at finding out what you "really" meant. OTOH, having it begin with the smallest non-(negitive)infinite value means that it becomes non-infinite, IE scalar((-inf..0)) != inf. This is obviously a Bad Thing. Also, if bignums are intergrated (as has been proposed), then there is no smallest representable integer. (This assumes that the float synthax will be extended to include "NaN" and "Inf" as valid floating-point numbers. (This does take away from non-reserved namespace.) Has this been proposed yet?) -=- James Mastros, In slightly over his head.
Re: RFC 71 (v1) Legacy Perl $pkg'var should die
Bart Lateur writes:
: On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote:
:
: D'oh! ;-)
:
: Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with
: this appropriate name any more.
:
: http://search.cpan.org/search?mode=modulequery=d%3A%3Aoh
:
:
: OTOH, try this:
:
: $hash{a'b} = 1;
: print keys %hash;
: --
: a::b
:
: That shows that the current situation is not ideal, anyway.
:
: Besides, p52p6.pl can handle the conversion.
Alternately:
use ident qr/[A-Za-z_][A-Za-z_0-9']*/;
or some such.
Larry
RE: RFC 67 (v1) Deep Copying, aka, cloning around.
From: Peter Scott [mailto:[EMAIL PROTECTED]] I would like deep copying to include copying CODE. It would be useful for implementing object methods... Why would it be necessary to deep copy a CODE reference? It might not be necessary. I'm still learning how to write kosher Perl... elegance is a long way off for me. It'd be nice to for a class to be able to initialize a new object containing a copy of an anonymous subroutine instead of a reference to a common one. There might be some real justification when used with closures. Then class methods could pass through to object methods that could be switched at runtime. Besides, it wouldn't be deep copying if it shallow copied the subroutines ;) If deep copying and cloning are though of in terms of persistent objects... aka Data::Dumper and Storable, then deparsing subroutines into something that can be stored becomes more important too. Class::Tom does this pretty well. Garrett
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 04:06 PM 8/9/00 +, Ed Mills wrote: In keeping with Larry's design philosophy that the language should "not just sit there -do something!" I agree that there should be a number of vector/matrix manipulations available, performed in a psuedo-scalar context (not in a loop). That would be list context. (Or perhaps array or hash context, and yes I know we don't have those right now) Just to name a few: [Snip] etc. etc. This kind of functionality would attract a whole new category of users from mathematics and other areas, as well as giving us optimized solutions to operations that many of us do regularly in loop contexts. I expect it would make other things interesting as well, not just math things. (Running a substitution on an array would be keen, for example) On the other hand one can argue all of these belong in CPAN under a matrix:: library or something like that, but to me if would make Perl a powertool to build these kinds of functions into the language syntax. In many cases these can be treated as overloading scalar ops for a non-scalar context. While I'm firmly of the opinion the code to actually Do Something should be elsewhere (at least to start), support definitely needs to be in the core to notice what that something is--you won't get very far with: @a * @b if perl does a scalar on both arrays before doing the multiplication... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
I do agree that the internals shouldn't drive the language (otherwise a crack team of Ninja would've already taken care of that Conway guy... :), but neither can they be completely ignored. Agreed. Which reminds me, we should call off those Ninja... :-) Honestly, I'd rather you put together a general scheme for handling the object/scalar morphing thingie and RFC it, and then we migrate the various functions that people think should do the object thing as time and effort allow. Agreed again. No reason to bloat the language with 10,000 pragmas. I think RFCs 49 (object STRING func) and 73 (this one), taken together, do a pretty good job of a first stab at this. However, as I get more input from people, integrating this all together into another RFC is probably a good idea, as you suggest. But I do like keeping 49 separate because it could be integrated into the language without having to include 73. -Nate
Re: Things to remove
[EMAIL PROTECTED] writes: : Most of the requests for deletion seem to begin with, "This isn't : used..." : : To which, "*I* use it." is a very valid argument. : : Agreed. The real problem with ?...? is that it complicates the hell out : of the parser. So long as the special magic is retained for m?...?, I : would suggest that raw ?...? could beneficially disappear. Or turned into m//f, or some such. Must think about relationship to an extension-based reset operator as well. To maintain current semantics we'd need introspection into the regular expressions used in a particular package. Larry
Re: RFC 73 (v1) All Perl core functions should return ob
I don't think it will be a half million objects. Let's take stat (and all the other long list returns). The underlying implementation object could be a packed structure psuedohash. (Think DSECT.) Then the only op would be the packed structure pseudohash lookup. Which would be done at compile time. (Fallbacks to the hash lookup if really generic.) For the other types, it would be quite invisible. The parser would translate the $foo-SCALAR into whatever you would want scalar($foo) to have returned. Similarly for other possible constructs. Just think of it as moving the internal access routines closer to the language. chaim "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS On 9 Aug 2000, Perl6 RFC Librarian wrote: =head1 TITLE All Perl core functions should return objects DS While an interesting idea, it'll mean we have a half-bazillion different DS types of objects floating around just from the core. The number of DS different vtables needed to deal with this (along with the functions in DS those tables) is rather formidable, and it will tend to impact DS performance. (The more different pieces of code you have the less cache DS coherency, which means things go slower) DS These really aren't objects anyway, they'd be magic scalars. (And yes, I DS know--the difference would be what, exactly? :) Regardless, I think this'd DS be rather slow, and I don't think it ought to be core. DS However... DS If you feel the need, it should be possible to let you do this, or at DS least a part of it for one or three ops, with a module. I think it might DS be better to wait until the plain way's in and then embellish it later. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: access to pod/doc text by code
"JV" == Johan Vromans [EMAIL PROTECTED] writes: JV Uri Guttman [EMAIL PROTECTED] writes: i think reading the file may have issues like finding it. or doc strings for each sub vs. parsing that out of the whole pod. i just bothers me to have to read that file for stuff that was in the source. so some better syntax to make that accessible to the code seems like a win. JV A neglectible one. JV Remember, 99.99% of the times this is used to fetch a final (fatal?) JV usage or help message. It is not something that is done 400 times JV during the lifetime of a common program. i have a new use for this, which is getting help text from long lived objects (which could be remote). that will not be a fatal/final message. i would like the speed to be decent and going to a file (and parsing the pod and filtering) is not a good solution IMO. as i said, there are workarounds and we now have an rfc on this subject. that is all i wanted, to bring this matter up. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 76 (v1) Builtin: reduce
Please consider the possiblity of tristate logic (RFC TBD.) ala, SQL. Assuming a "use tristate", undef + number = undef This might require that the reduce function be able to ignore undefs. Either always under the tristate pragma. Or on a case by case basis. Also you haven't specified if the arguments to reduce are evaluated lazily. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL The first call to the reduction subroutine will be passed the first N PRL elements of the list, and subsequent calls will be passed the result of PRL the previous call and the next N-1 elements in the list, until no more PRL elements remain in the list. If fewer than N-1 elements remain on the PRL final call, all the remaining elemetns are passed. PRL If the original list has no elements, Creduce immediately returns Cundef. PRL If the original list has a single element, that element is immediately returned PRL (without every calling the reduction subroutine). PRL Otherwise, the result of the final reduction call is the result returned PRL by Creduce. PRL If the reduction subroutine is ever terminated by a call to Clast, PRL the enclosing Creduce immediately returns the last reduction value PRL (i.e. Cundef on the first reduction call, $_[0] otherwise) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 10:44 AM 8/9/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : Note that it may not be possible to satisfy conflicting requests. If : module CA and module CB demand two different versions of the same : module CC, the compiler should halt and state the module conflicts. Pardon me for sniping at a great RFC, but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. Does that mean, then, that when module A does a "$C::bar = 1" it affects a different package namespace than module B doing a "$C::bar = 2"? And does it also extend to things like this: package A; use C 1.2; package B; use C 1.4; where two packages in the same file use different versions of module C and get them? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
Damian Conway [EMAIL PROTECTED] writes: Operator overloading is scheduled to be revamped. While I remember - it would be good if overload mechansim could be extended to cover and || as well as and | with the class deciding if short-circuit happens. Oh, definitely. I need lazily evaluated args for that, but (of course) there's an RFC in the pipeline to cover that too :-) Damian
Re: Overloading ||
At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote: Damian Conway [EMAIL PROTECTED] writes: Operator overloading is scheduled to be revamped. While I remember - it would be good if overload mechansim could be extended to cover and || Yes. as well as and | with the class deciding if short-circuit happens. No. I don't want to see or || and not know whether it short-circuits without looking in the class interface. My brain is conditioned through years of C and Perl to expect that they always short-circuit. This is too venerable a semantic to change. Please. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 79 (v1) Code which is both executable and POD.
On Wed, 9 Aug 2000, Michael Mathews wrote: To be fair, neither of these are examples of using a comment function for "comments" though, but rather using a comment function to disable sections of code and I suppose that makes as much sense as using POD to disable code. This is another instance where a macro preprocessor might be useful. (My previous example was an alternative to some of the higher-level function proposals.) In cpp (though I'd not recommend that particular "language" for Perl): #if 0 ..disabled code... #if 0 ..older disabled code... now in nested disables #endif ..more disabled code #endif Just hoping that looking at it from another skewed viewpoint may inspire someone, Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Ramblings on base class for SV etc.
Dan Sugalski [EMAIL PROTECTED] writes: Well, compactness for one. With a scalar on one side it's less odd (it was a bad example). When funkier, though: @foo = @bar * @baz; the expansion becomes less obvious It is "obviously" a cross-product ;-) With perl's $s and @s we can actually make sensible choice between mathamaticians · (dot) and X (cross) produducts from context. Whether that is a good idea is another matter. and quite a bit larger, especially if the arrays are multidimensional. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk -- Nick Ing-Simmons
Re: RFC 79 (v1) Code which is both executable and POD.
Michael Mathews wrote: I do consider this a potential alternative to the MLC RFC ... I don't. This RFC deals strictly with POD. If a good in-line comment solution is also implemented, so much the better; but orthogonal to this. but to my mind it addresses the opposite problem: how to get executable code into a commenmt, rather than how to get executable code out of the program That's a very astute observation; and it's why the solutions may reasonably be independent. -- John Porter
Re: RFC 79 (v1) Code which is both executable and POD.
Andy Dougherty wrote: This is another instance where a macro preprocessor might be useful. ... Just hoping that looking at it from another skewed viewpoint may inspire someone, Fine; but I hope people only see RFC 79 as an extension to POD, because that's all it really is. It does not attempt to address the in-line comments issue -- and would fail if it did try, because that is a issue with the whole of POD, even in the absence of RFC 79. -- John Porter
Re: Overloading ||
No. I don't want to see or || and not know whether it short-circuits without looking in the class interface. My brain is conditioned through years of C and Perl to expect that they always short-circuit. This is too venerable a semantic to change. Please. What if I want to overload and || so that they help built an expression tree, rather than immediately evaluating? Damian
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 11:11 AM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : different package namespace than module B doing a "$C::bar = 2"? Presumably. H. That brings up some issues of ambiguity, then. If you use C in package A, and also in package B, which do you see when you're in main and access $C::bar? : And does it also extend to things like this: : : package A; : use C 1.2; : package B; : use C 1.4; : : where two packages in the same file use different versions of module C and : get them? I expect that could also be made to work, provided the semantics of importation remain package-scoped and don't become lexically scoped. Sure. They'd have to be, otherwise packages split across different files would get a rather bizarre view of the world. This sort of means we'll need some sort of two-level stash, one per-package and one global. (Unless you're outlawing symbolic references... :) To me, it really just means that the *real* name of the package includes the implementation (author?) and version, but that when you say use C; you're just choosing to wildcard both the implementation and version. This view says that we probably ought to figure out how to encode the implementation and version syntactically as part of the package name, rather than as a 3rd argument to use. Yup. I can see the build procedures needing to know this too, since we'll probably need to give modules with shared libraries unique names. Some platforms (OS/2 and VMS, at least) will need that, as they get cranky if you try and load shareables with the same base filename. Think about the long names of fonts for an example of how far this can be taken. Would this be "Taken to its logical and sensible conclusion" or "Taken as far as it can possibly go, though it you turn around and look *really* hard with binoculars you can see where you crossed the line, way back there by the horizon"? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
At 04:58 AM 8/10/00 +1000, Damian Conway wrote: No. I don't want to see or || and not know whether it short-circuits without looking in the class interface. My brain is conditioned through years of C and Perl to expect that they always short-circuit. This is too venerable a semantic to change. Please. What if I want to overload and || so that they help built an expression tree, rather than immediately evaluating? Is it worth the damage it will cause to fragile brains like mine? I have often wondered whether a language could allow user-defined operators. The fact that none have done it should be a clue :-) I guess it's getting too incestuous with the lexer. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 73 (v1) All Perl core functions should return ob
At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote:
I want the core to stay useful but not complex. If localtime returned
a hashref in scalar context, that'd be enough for me:
$now = localtime;
print $now-{MONTH};
print $now-{YEAR}; # already has 1900 added onto it :-)
print $now-{INTEGER};# epoch seconds value
To get what is now scalar localtime, you'd say
print localtime-{STRING};
I'd just as soon that was scalar(localtime)--if we're going to do this,
then we should do it so the short-hand format's convenient and useful.
Which sort of argues for localtime in a numeric scalar context to return
epoch seconds, in a string scalar context to return a time string, and in a
plain scalar context a hashref. (or mini-object, or tied thingamabob, or
whatever) Of course, we're trying to kill $! which does that, which is a
counter-argument...
In list context it would return a simple list of values as it does now.
RFC 48 is way too complex for my liking. In particular it expects
Perl to be able to distinguish between assignment to array and to a
hash.
I smell a counter-RFC, or at least a mailing list on which to thrash
this out.
Nat
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Overloading ||
At 12:04 PM 8/9/00 -0700, Peter Scott wrote:
At 04:58 AM 8/10/00 +1000, Damian Conway wrote:
No. I don't want to see or || and not know whether it
short-circuits
without looking in the class interface. My brain is conditioned
through
years of C and Perl to expect that they always short-circuit. This
is too
venerable a semantic to change. Please.
What if I want to overload and || so that they help built an expression
tree, rather than immediately evaluating?
Is it worth the damage it will cause to fragile brains like mine?
"And now it's time for the head on top of your shoulders to explode"
I have often wondered whether a language could allow user-defined
operators. The fact that none have done it should be a clue :-)
What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of
computer programmers?")
I guess it's getting too incestuous with the lexer.
Nah, though it does restrict the optimizer some depending on how it overloads.
Of course, by the time Damian's done, perl won't actually *do*
anything--you'll need to fire off another window and do a "kill
-HEYYOUGETMOVING 23442" to actually make something happen...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Overloading ||
What if I want to overload and || so that they help built an expression tree, rather than immediately evaluating? Is it worth the damage it will cause to fragile brains like mine? "Pain is the weakness leaving your body!" ;-) I have often wondered whether a language could allow user-defined operators. The fact that none have done it should be a clue :-) I guess it's getting too incestuous with the lexer. User-defined operators are a can of rattle-snakes that I *seriously* recommend we don't open. Damian
Re: Overloading ||
Of course, by the time Damian's done, perl won't actually *do* anything--you'll need to fire off another window and do a "kill -HEYYOUGETMOVING 23442" to actually make something happen... Actually, the plan is exactly the opposite. By the time I'm finished everything will be done...in constant time! Damian
Re: RFC 54 (v1) Operators: Polymorphic comparisons
At 05:12 PM 8/7/00 -0400, Chaim Frenkel wrote: "DC" == Damian Conway [EMAIL PROTECTED] writes: I currently fail to switch to 'eq' many times when I should, but the failure mode is obvious. Her the failure mode will be really strange. DC I would claim that the failure mode is not obvious: "dog"=="cat" is true Sure it is. I pass a large amount of data and _everything_ matches! Voila, I messed up the test. Test looks okay. (If I was a newbie, '==' is broken. Given my experience, I used the wrong test.) Both ways have issues. "dog"=="cat", but "10.0"ne"10". Both are arguably wrong--dogs aren't cats, but 10.0 really is 10... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
At 05:23 AM 8/10/00 +1000, Damian Conway wrote: Of course, by the time Damian's done, perl won't actually *do* anything--you'll need to fire off another window and do a "kill -HEYYOUGETMOVING 23442" to actually make something happen... Actually, the plan is exactly the opposite. By the time I'm finished everything will be done...in constant time! Sure, but being Quantum, we won't know how long that time is, or if we do we won't know what the answer is... (With all the lazy operations proposals, I can see the release slogan now: "Perl 6, the language for couch potatoes") Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: DRAFT RFC: Enhanced Pack/Unpack
At 10:53 PM 8/7/00 +0200, Bart Lateur wrote: Right. Why you people don't call it "Intel" vs. "Motorola", like the rest of the civilised world, I don't know. ;-) See the TIFF spec, for example. Er, in case you were in any doubt: Motorola (from the 68k processors) is BigEndian, Intel (x86) is LittleEndian. TIFF marks the files with either "MM" or "II". Yep, except for the PowerPC and 88k chips, which can do either, or the i860, which was BigEndian IIRC... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: DRAFT RFC: Enhanced Pack/Unpack
At 07:26 PM 8/7/00 +0100, Tom Hughes wrote: From /usr/include/endian.h on my linux box: #define __LITTLE_ENDIAN 1234 #define __BIG_ENDIAN4321 #define __PDP_ENDIAN3412 Basically PDP or middle endian is low byte first within each word but high word first in the overall longword. This, FWIW, is because the PDP-11 (as opposed to all the other PDP families) was a 16-bit machine, so this is actually two words each in little-endian storage... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: chomp unchomp
On Wed, 09 Aug 2000, Ed Mills wrote: Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Chomp removes one or more line separators from the end. Hence my println() suggestion. Maybe instead it should be: unchomp; print; Where unchomp ADDS \n to the end of text if it isn't already there. How many? Ideally, since you're looking for an inverse, you'd want to replace however many were chomped off, right? If there is chomp there should be unchomp- the reasons for including it are the same as for including chomp. If chomp is optimized so too can unchomp. Having chomp without unchomp would be like having = but not having = [see note]. Sure you can get by without it- just change the order of the args, but why would you want to? If you have one, the other needs to be there for, if nothng else, parity. chomp() uses $/, I believe. $\ is the inverse of $/, and is used automatically. And it's fewer characters. $\="\n"; print; -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 79 (v1) Code which is both executable and POD.
Uri Guttman wrote:
but how will perl access that text? what perl var get the text in that
=for block?
Well, the proposal was more about getting perl code into doco than
getting doco into perl.
the proposal for a special here doc notation is possible but
that can be hard for pod to parse unless we restrict the format.
Yes, that's an idea.
Maybe what's needed is two distinct perl pod processor types, one
which passes on the text literally to the compiler, and one which
wraps it up like a string literal.
The former type:
=for pod
The subroutine is defined as
=for perl-code pod
sub foo($\@%)
{
#...
}
The latter type:
print
=for perl-string pod
Help is on the way.
;
--
John Porter
Aus tiefem Traum bin ich erwacht.
Re: chomp unchomp
Bryan C. Warnock wrote: Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. -- John Porter
Re: chomp unchomp
At 03:36 PM 8/9/00 -0400, Bryan C. Warnock wrote: On Wed, 09 Aug 2000, Ed Mills wrote: Here is the argument- Perl has (had?) chomp(). It removes \n at the end of a line. That's something we often need to do. We ALSO often need to ADD \n to the end of a line. This usually looks something like: print "$kitty\n"; Chomp removes one or more line separators from the end. Chomp only removes one instance of the record separator from the end. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Overloading ||
Peter Scott [EMAIL PROTECTED] writes:
At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote:
Damian Conway [EMAIL PROTECTED] writes:
Operator overloading is scheduled to be revamped.
While I remember - it would be good if overload mechansim
could be extended to cover and ||
Yes.
as well as and |
with the class deciding if short-circuit happens.
No. I don't want to see or || and not know whether it short-circuits
without looking in the class interface. My brain is conditioned through
years of C and Perl to expect that they always short-circuit. This is too
venerable a semantic to change. Please.
The reason I want the class to decide is not to change the semantic meaning
but the implementation - i.e. _when_ it short circuits.
I have an application which overloads all the ops and builds a little parse
tree of objects. When you "look" at the tree it returns the value.
my $a = new Thing;
my $b = new Thing;
my $cond = $a $b; # an object
sub foo
{
if ($cond)
{
}
}
$a-bind($a_value);
$b-bind($b_value);
foo();
If things worked as I wanted then when foo is called and "looks" at $cond
then overloaded "boolean" operator of $cond would walk the tree and see
if $a should be considered "true" with its current binding if not
it would short-circuit tree traversal, if it was it would go look at $b's
trueness.
Currently it is completely hosed by and || as perl will not give me
access to the short-circuited operand so I cannot put it in my tree so
when it evaluates I get the wrong answers.
(To make app. work I use and | and make _those_ short circuit - but
my users and I keep forgetting ...)
I don't think giving overload control over short-circuit is any more
surprising than allowing overloaded '+' to subtract.
--
Nick Ing-Simmons
Re: RFC 54 (v1) Operators: Polymorphic comparisons
Dan Sugalski wrote: At 05:12 PM 8/7/00 -0400, Chaim Frenkel wrote: "DC" == Damian Conway [EMAIL PROTECTED] writes: I currently fail to switch to 'eq' many times when I should, but the failure mode is obvious. Her the failure mode will be really strange. DC I would claim that the failure mode is not obvious: "dog"=="cat" is true Sure it is. I pass a large amount of data and _everything_ matches! Voila, I messed up the test. Test looks okay. (If I was a newbie, '==' is broken. Given my experience, I used the wrong test.) Both ways have issues. "dog"=="cat", but "10.0"ne"10". Both are arguably wrong--dogs aren't cats, but 10.0 really is 10... I first thought that "==" and "eq" were cut from the same cloth as "||" and "or" that is the difference was precedence. But I guess I learned. Or did I? -- Clayton Scott
Re: RFC 79 (v1) Code which is both executable and POD.
"JP" == John Porter [EMAIL PROTECTED] writes: JP Maybe what's needed is two distinct perl pod processor types, one JP which passes on the text literally to the compiler, and one which JP wraps it up like a string literal. JP print JP =for perl-string pod JP Help is on the way. JP ; and how will perl know that is a string? the special here doc format has more appeal to me. print =POD ; this is help for pod and code =POD for perl it is just a literal string which can be used any way it wants and there are no major parsing changes. for pod, it has to look for =POD tokens and the closing token (which is in pod form on the left margin) another possibility is nesting pod in a here doc. $help = POD ; =pod perl help text seen by both pod and perl =cut POD $help =~ s/^=(:pod|cut)$//mg ; that works for me assuming perl will include the pod directives in the here text. since it has to look for =pod anyway, we could define it to delete those lines and then we don't need the s///. this would only be in effect in here docs (which are multiline by definition unlike long quoted strings). the two goals of code in pod and pod in data are not the same and probably won't use the same mechanisms. all i want is pod in perl strings and that is nothing like having perl code be seen by pod as well. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 73 (v1) All Perl core functions should return ob
Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat
Re: chomp unchomp
On Wed, 09 Aug 2000, John Porter wrote: Bryan C. Warnock wrote: Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. Sorry. You're correct. I was rolling the string, list, and paragraph mode removals all into one argument. :-( Chomp *sometimes* remove one or more newlines from the end of a string. #!/usr/local/bin/perl -w $/=""; $a = "Hello\n\n\n\n\n\n"; $foo = chomp($a); print "$foo chomped, $a\n"; Whammo perl gork 6 chomped, Hello I may be slow, but I make mistakes. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Overloading ||
Peter Scott writes: I have often wondered whether a language could allow user-defined operators. The fact that none have done it should be a clue :-) I guess it's getting too incestuous with the lexer. Ilya sent in a patch for user-defined operators. It was rejected, not least because your new operators had to look like ``+++'' skanky quotes and all. This was probably to avoid too much lexercest. Nat
Re: chomp unchomp
On Wed, 9 Aug 2000 15:42:24 -0400, John Porter wrote: Bryan C. Warnock wrote: Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. Try setting $/ to the empty string. (not undef!) -- Bart.
Re: RFC 73 (v1) All Perl core functions should return ob
I'm nervous about these different contexts. I thought scalar vs list
was confusion enough. Now we're talking about overloading even
further? We need to think VERY long and VERY hard about this before
thinking it's a good thing.
Well, I have, and I do.
(Though I'm no longer sure whether that's an argument for or against! ;-)
The problem is not multiple contexts; it's inconsistent return values.
That is, there's no way of guessing what a particular "listish" function
-- such as map, each, reverse, etc. -- will return in a scalar context,
without actually *knowing* what it's defined to return).
In some senses additional contexts actually help, by improving DWIMity.
If I can say:
my $month = date-{month};
then I'm much more confident what I'm going to get back. As opposed to:
my $what = date;
which might return epoch seconds as an integer, or a date string, or a
hash- or array ref, or the number of elements in the date array :-(
With extra contexts I can be surer:
my $yesterday = date() - 86400; # reasonable to expect epoch integer
my $today = "today is " . date(); # reasonable to expect date string
my $tomorrow = date()-{DoY} + 1; # reasonable to expect hash ref
Damian
Re: RFC 76 (v1) Builtin: reduce
On 09 Aug 2000 13:49:24 -0400, Chaim Frenkel wrote: Assuming a "use tristate", undef + number = undef This might require that the reduce function be able to ignore undefs. Either always under the tristate pragma. Or on a case by case basis. grep defined, LIST -- Bart.
Re: RFC 79 (v1) Code which is both executable and POD.
Uri Guttman wrote: "JP" == John Porter [EMAIL PROTECTED] writes: JP Maybe what's needed is two distinct perl pod processor types, one JP which passes on the text literally to the compiler, and one which JP wraps it up like a string literal. JP print JP =for perl-string pod JP Help is on the way. JP ; and how will perl know that is a string? While I'm not necessarily saying it's a great solution, the answer to your question is simple; the special "perl-string" pod processor -- which is active in the perl compiler's input stream -- sees such a construct and converts into a q() string literal. It requires some machinery in the perl parser, for sure. print =POD ; this is help for pod and code =POD I like this. It also requires some machinery in the pod processor. the two goals of code in pod and pod in data are not the same and probably won't use the same mechanisms. all i want is pod in perl strings and that is nothing like having perl code be seen by pod as well. Yup. -- John Porter Aus tiefem Traum bin ich erwacht.
Re: RFC 73 (v1) All Perl core functions should return ob
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 01:33 PM 8/9/00 -0400, Chaim Frenkel wrote: I don't think it will be a half million objects. Let's take stat (and all the other long list returns). The underlying implementation object could be a packed structure psuedohash. (Think DSECT.) Then the only op would be the packed structure pseudohash lookup. Which would be done at compile time. (Fallbacks to the hash lookup if really generic.) DS stat makes some sense. (local|gm)time makes some sense. The socket DS functions make some sense. The message and shared memory functions DS make some sense. Basically most of the 'advanced' functions make DS some sense. That's the problem--they all make some sense, which DS is a lot of code to get right for the .0 release. I'm not quite in favor of the proposal, but I'm not sure it is so extensive. (As I see it, all of the internals are being rewritten. So the work has to be done.) This isn't an N - N problem. This is more limited. The perl - op level, would be the access method. The advance funcs, would only have to get the mapping correct. Actually, by rationalizing the return "object" you might be making the internal coder's life easier. What am I missing? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
Johan Vromans wrote: Be reminded that Perl++ will increment Perl, but return the _current_ value. Heh, at least we're not python = python + 1 -- John Porter
Re: Overloading ||
Dan Sugalski [EMAIL PROTECTED] writes:
I have often wondered whether a language could allow user-defined
operators. The fact that none have done it should be a clue :-)
What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of
computer programmers?")
You cannot as far as I aware define new operators in C++ - just redefine the
ones you have. I cannot decide that '|' is now an operator.
I guess it's getting too incestuous with the lexer.
That is the root of the problem.
--
Nick Ing-Simmons
Re: RFC 79 (v1) Code which is both executable and POD.
Doesn't that put the formating for a target within the document. Shouldn't that be external to the actual markup? How about backing up a bit, and adding a style sheet to POD? Then only markup will be in pod, then making things disappear would be the job of the stylesheet. chaim "LW" == Larry Wall [EMAIL PROTECTED] writes: LW It already is, as far as I'm concerned. LW The view that the POD contained within a file specifies a single LW document is oversimplified. The moment we added =for and =begin/=end, LW POD became a way to specify multiple, independent documents in the same LW file. Each keyword following =for or =begin/=end specifies a different LW abstract document. If one of those abstract documents happens to be LW commentary on the code, great. Not all of those abstract documents have LW to be intended for external POD viewers, assertions to the contrary LW notwithstanding. LW Seems like all we're discussing now is how much those independent LW documents should be independent (where the code itself is considered LW one of the documents). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Things to remove
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:
Someone proposed (I think I deleted that email) to make
while (FH) { ... }
work like
while (FH) { chomp; ... }
Guilty.
I've benchmarked the above codes, with '...' replaced by nothing, chomp
vs. the -l command line switch, and it turns out that the implicit chomp
of -l is almost 10% faster than the explicit chomp() of the traditional
approach: 9.83 seconds (implicit) vs. 10.77 seconds (explicit), on the
same file.
The culprit is that $/ set to something other than "" (or undef) slows
down the printing considerably: abnout 20%. This probably could be
improved by a lot.
--
Bart.
Re: RFC 79 (v1) Code which is both executable and POD.
Larry Wall said: John Porter writes: : So, are you saying that if this RFC is implemented, POD would be : an good way to comment code? It already is, as far as I'm concerned. Please, if I'm missing something specific please explain it to me. But here's what I can tell from the documentation included with my download of Perl: From perlpod by Larry Wall The "=pod" directive does nothing beyond telling the compiler to lay off parsing code through the next "=cut". ... For, begin, and end let you include sections that are not interpreted as pod text, but passed directly to particular formatters. ... The paired commands "=begin" and "=end" work very similarly to "=for", but instead of only accepting a single paragraph, all text from "=begin" to a paragraph with a matching "=end" are treated as a particular format. Okay, what this means to /me/ is that I can escape from the normal interpretation of POD by using these commands (ie =for/begin/end). However this assumes, as I read it, that we are already in POD: such as, formally: =pod =begin multiline comment ...disabled code or whatever =end multiline comment =cut or (from perlsyn) you could get away with the following, though Tom warns "You probably shouldn't rely upon the warn being podded out forever. Not all pod translators are well-behaved in this regard, and perhaps the compiler will become pickier." =secret stuff warn "Neither POD nor CODE!?" =cut back This is not what I am after! Here's what I would propose: a quick, easy to recognize, logical to learn, way of explicitly defining where a comment starts and ends (which requires the delimiter be unlikely to appear in the comment itself). It would be even better if it supported nesting (which =cut doesn't because it ends all POD). --Michael
Re: RFC 73 (v1) All Perl core functions should return ob
Nathan Torkington wrote: Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat We could stop insisting on these finitely enumerated and nonextendable "contexts" and start allowing overloading assignment, like so: The assignment operator is selected from the Rvalue's methods, therefore the Rvalue gets to examine the type of the Lvalue and decide what to give it. In this scheme, "time" could by default return an integer, except if the Rvalue has a defined time-override method, in which case it is used instead. -- David Nicol 816.235.1187 [EMAIL PROTECTED] On hold for tech support since 1995
Re: RFC 78 (v1) Improved Module Versioning And Searching
On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote:
: Note that it may not be possible to satisfy conflicting requests. If
: module CA and module CB demand two different versions of the same
: module CC, the compiler should halt and state the module conflicts.
Pardon me for sniping at a great RFC . . .
No problem, I don't feel sniped at.
. . . but I already promised the CPAN
workers that I'd make that last statement false. There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality. Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.
Near the end of the RFC this topic does come up; see it directly at
http://www.nnaf.net/~scs/Perl6/RFC78.html#Alternative_Idea_Module_Versio.
That section was much longer in my unreleased drafts, but did include
some discussion on disambiguation when multiple versions of the same
module are loaded. In the RFC I wrote off this idea with ``In This Way
Lies Madness, but perl has done stranger things.''
If we want to open that can of worms I'm willing to pitch in. I'll even
continue on with the task of maintaining the RFC, or starting another
if appropriate. But I'd barely started thinking about this issue with
respect to perl until a couple of days ago, so folks who are much more up
to speed on language/inheritence/etc are going to have to carry the load.
Turning back to some specific comments made by Larry and by Dan Sugalski:
LW The larger view of it is how to support package aliasing. A package
LW name is essentially the name of a public interface. Suppose you
LW have one interface, but two or more different implementations of
LW that interface by different people. Each might have their own
LW version sequence.
Package aliasing should certianly be allowed; the RFC already contains
a suggestion for it:
use foo 3.0 as foo_old;
use foo =3.0. as foo;
use foo 3.0. as new_foo;
Using the alias gets you what you need.
Your comment above implies that CPAN may (will be allowed to) contain
modules of the same name and same version by different authors. Is this
correct? If so (shudder), what happens currently when both are installed?
I presume one simply overwrites some or all of the other.
If that's the intent, then yes, author name must become part of the
package identifier. Rather than change the meaning of "ref $object"
unexpectedly, I'd add one or more alternate forms of ref. Off the
top of the head, something like
( $version, $class ) = vref $object; # ref with version
$version = vref $object; # scalar context gets version
( $author, $class ) = aref $object; # ref with author
$author = aref $object; # scalar context gets author
( $version, $author, $class ) = fref $object; # get all
# Scalar context gets a string suitable for select the
# exact object in use
$fq_name = fref $object;
if ( $fqname eq fref $other_object )...
LW Another question is whether the two different versions of the "same"
LW module are going to stomp on each other? (Not in package space, since
LW the packages are distinguished internally, but how about in the
LW filesystem?)
If we include author name along with the version number in the file system
namespace (gawd, I can't believe I just wrote that), then clobbering
won't happen. IMHO this feature is no more difficult to add to the
install process than adding version numbers; it implies tho that we
need a $AUTHOR var in all modules and to allow for it in module `version'
specifications. Again, off the top of the head, we could allow a string
(any string that would not be confused with a version number) to indicate
the author:
use foo CONWAY =1.3 as foo_good;
use foo GATES 1.3 as foo_bad;
use foo * as foo_desperate;
As long as there's no author names `as', we're cool. I suspect the
proposed syntax in the RFC could be extended to handle this unambiguously
both for run/compile-time module naming and for installation, but need
to think it thru.
DS Does that mean, then, that when module A does a "$C::bar = 1" it
DS affects a different package namespace than module B doing a
DS "$C::bar = 2"?
LW Presumably.
Yes, that's how I'd see it too. Which creates a real problem for
modules which do things like
package foo;
{
my $hidden_var;
sub new {
if ( $hidden_var ) {
do x;
} else {
do y;
}
}
}
Now there are two copies of $hidden_var while the module clearly expects
only one. Either this kind of construction will have to be avoided,
or some mechanism developed which allows multiple version of a module
to somehow share important data which is otherwise hidden by such tricks.
IMHO, module authors should be able to forbid multi-loads across
sufficiently different versions of the module (ie, all
Re: RFC 73 (v1) All Perl core functions should return ob
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
Re: RFC 54 (v1) Operators: Polymorphic comparisons
Clayton Scott wrote: I first thought that "==" and "eq" were cut from the same cloth as "||" and "or" that is the difference was precedence. Then I learned. Mr. Scott's experience is evidence for a strong argument AGAINST operator overloading. If we allow object types, and allow object types to overload, we lose the clarity we have in a language that doesn't have these things. Maintaining code with perl5 package-modules is difficult enough, but at least all the object method calls are explicitly object method calls and there aren't any object method calls masquerading as well-understood builtins! -- David Nicol 816.235.1187 [EMAIL PROTECTED] On hold for tech support since 1995
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Ted Ashton wrote:
Thus it was written in the epistle of John Porter,
Ken Fox wrote:
Both of those expressions are the infinite list (-infinity..-1). I
have
no idea how to write that properly 'cause I'm not a math guy. These
things aren't streams (infinite queues) -- they're infinite stacks.
I'm
not sure they have a name in computer science.
O.k., here's the basic question. (If someone has already answered this,
I didn't find it satisfactorily comprehensible. Assume I'm an idiot.)
What would be the output of the following program:
$\ = "\n";
$i = 0;
for ( .. -1 ) {
$i++;
last if $i 2;
print
}
If the answer is (as I suspect), "This never prints anything; it goes
into an infinite loop just trying to generate the first number", then
the proposal is absurd and should be scrapped.
By my understanding (which is definitely not very thorough), the output
would
be a run-time error.
That's my understanding too. I'm trying to pull together a more complete
proposal that describes under what conditions a list can or can not be used
without specifying its domain (amongst other things). Bear with me for a day
or two...
Re: RFC 76 (v1) Builtin: reduce
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC I'm not sure how this would affect the proposal. If an item in the
DC list being reduced is undef, it appears in the reduction
DC subroutines arg list as undef. The reduction subroutine can then
DC handle it (or not) as it chooses.
DC For example, to short-circuit if the reduction ever becomes undef:
DC $sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;
Actually, it would be easier to do in reduce, the undefs should
simply be ignored.
Otherwise having the user code it, becomes
{ defined $_[0] defined $_[1] ? $_[0] + $_[1]
: defined $[0] ? $_[0] : $_[1] }
Pretty ugly.
And for the N case, it gets even uglier. So reduce should be able
to supply the next N-1 defined() values.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 54 (v1) Operators: Polymorphic comparisons
I first thought that "==" and "eq" were cut from the same cloth as
"||" and "or" that is the difference was precedence. Then I learned.
Mr. Scott's experience is evidence for a strong argument AGAINST operator
overloading.
Huh???
I draw exactly the opposite conclusion: If "==" were overloaded to
automatically Do The Right Thing for numbers vs strings as operands,
there would have been no confusion in the first place!
If we allow object types, and allow object types to overload,
we lose the clarity we have in a language that doesn't have
these things.
Maintaining code with perl5 package-modules is difficult enough, but
at least all the object method calls are explicitly object method
calls and there aren't any object method calls masquerading as
well-understood builtins!
So these:
$vec4 = $vec1-add($vec2-unit-cross_product(
$vec3-unit)-dot_product($vec1-unit);
$diff = Math::BigFloat-new((Math::BigFloat-new((
Math::BigFloat-new((Math::BigFloat-new($China{gdp}
-fmul($China{gdp_incr})))-fdiv(Math::BigFloat-
new($China{pop}-fmul($China{pop_incr})-fsub(
Math::BigFloat-new(Math::BigFloat-new($USA{gdp}-
fmul($USA{gdp_incr})))-fdiv(Math::BigFloat-new(
$USA{pop}-fmul($USA{pop_incr})))-fabs());
are better than these:
$vec4 = $vec1 + ~$vec2 x ~$vec3 . ~$vec1;
$diff = abs(
($China{gdp}*$China{gdp_incr})/($China{pop}*$China{pop_incr})
- ($USA{gdp}*$USA{gdp_incr})/($USA{pop}*$USA{pop_incr})
);
Surely not?
Operator overloading can certainly be abused (hey, I'm building a career
on that! ;-), but it can also significantly *improve* the maintainability
of code, when used correctly.
In other words: it's just like *every* other feature of Perl.
Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Ted Ashton wrote:
I understand very well the concern. I, for one, don't agree that having
(1..) in the language implies that having (..-1) is possible (though it
does
make sense to me that having (1..) and (..-1) would imply having (..)).
After
all, if I were to write
for (1..) {
print;
}
I would get an infinite loop, but one which was doing something, whereas
for (..-1) {
print;
}
The reason that having (1..) implies having (..-1) is that if you allow
(1..), then this is a valid construct:
@dot_dot_neg_one = reverse (map {-$_} (1..));
which is identical to (..-1)! So scrapping (..-1) doesn't actually win you
anything, in terms of avoiding 'impossible loops'.
The only way around all this, IMO, is to require that the domain of indexes
of an infinite loop be specified before the list is output in any way.
'Output' includes reduction of the list (see RFC 76). The domain could be
specified explicitly, or could in some cases be derived by Perl implicitly
from the context of the expression.
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 11:13 PM 8/9/00 +0200, Bart Lateur wrote: On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] Nope, and we should stop. One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. s/object\./object right now./; If the current plan goes through, arrays and hashes will be typeable, and therefore overloadable. (Think of it as a lightweight object--no method calls, just overloading) but a problem is: @copy = @ary; which only copies the items by value, as a list, and thus ignores the blessing. @copy is a plain array. Well... What happens depends on the type of @copy, and what we decide to do with whole-container assignments. It's reasonable to make @copy the same type as @ary. And if @copy's not a generic scalar array (and is, instead, an integer array, say) some sort of conversion might take place. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 73 (v1) All Perl core functions should return ob
At 09:16 PM 8/9/00 +, David L. Nicol wrote: Nathan Torkington wrote: Dan Sugalski writes: Which sort of argues for localtime in a numeric scalar context to return epoch seconds, in a string scalar context to return a time string, and in a plain scalar context a hashref. (or mini-object, or tied thingamabob, or whatever) Of course, we're trying to kill $! which does that, which is a counter-argument... I'm nervous about these different contexts. I thought scalar vs list was confusion enough. Now we're talking about overloading even further? We need to think VERY long and VERY hard about this before thinking it's a good thing. Nat We could stop insisting on these finitely enumerated and nonextendable "contexts" and start allowing overloading assignment, like so: The assignment operator is selected from the Rvalue's methods, therefore the Rvalue gets to examine the type of the Lvalue and decide what to give it. Both the l and rvalues will need to participate somehow, if for no other reason as to make sure that: @foo = @bar; doesn't bother with the list flattening/unflattening trick. I'm not sure that giving the rvalue unconditional control's a good idea. In this scheme, "time" could by default return an integer, except if the Rvalue has a defined time-override method, in which case it is used instead. Gack. The problem there is then you need to worry about time-return, stat-return, shm-return, foo-return, bar-return... Icky. I think perhaps Plan B would be better. (And no, I have no plan B at the moment) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 78 (v1) Improved Module Versioning And Searching
At 01:50 PM 8/9/00 -0700, Larry Wall wrote: Dan Sugalski writes: : At 11:11 AM 8/9/00 -0700, Larry Wall wrote: : Dan Sugalski writes: : : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : : different package namespace than module B doing a "$C::bar = 2"? : : Presumably. : : H. That brings up some issues of ambiguity, then. If you use C in : package A, and also in package B, which do you see when you're in main and : access $C::bar? I dunno. I don't imagine the situation will arise that often. It'll happen at least once. I suppose we could go insane and make packages loaded in through modules completely invisible to all but the use-ing package, so in this case main wouldn't even know there was a C loaded, and if it tries to mess with things in the C package it gets its own empty stash to deal with. (Which all other packages that didn't use one version of the module or another get) I suppose that's a fancy way of saying namespaces created by used modules are private to the package using them. (Though that still leaves the issue of what happens when package B uses something from package C which wasn't created on the use, but then I'd probably just say "you get your version of C. Nyah!") Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 76 (v1) Builtin: reduce
Actually, it would be easier to do in reduce, the undefs should
simply be ignored.
Otherwise having the user code it, becomes
{ defined $_[0] defined $_[1] ? $_[0] + $_[1]
: defined $[0] ? $_[0] : $_[1] }
Pretty ugly.
And for the N case, it gets even uglier. So reduce should be able
to supply the next N-1 defined() values.
$def_sum = reduce { $_[0]+$_[1] } grep {defined} @numbers;
Damian
Re: RFC 78 (v1) Improved Module Versioning And Searching
Thus it was written in the epistle of Steve Simmons, . . . but I already promised the CPAN workers that I'd make that last statement false. There's no reason in principle why two modules shouldn't be allowed to have their own view of reality. Just because you write Foo::bar in your module doesn't mean that Perl can't know which version of Foo:: you mean. OK, let's let someone else get into the conversation. I'll take that as my cue ;-). DS . . . If you use C in package A, and also in package B, which do you DS see when you're in main and access $C::bar? LW I dunno. I don't imagine the situation will arise that often. It may not happen often, but once is enough. IMHO the answer is `in load order' unless the programmer does something explicit to resolve the issue. *shudder* This whole business is getting pretty scary. Best that I can tell, what y'all are saying is that if A and B happen to both load the same version of C, then A can say $C::flag = 1 and B can see that, but if they load differing versions, then they can't (as there are two copies of $C::flag). Oi! If you are going to split it up in that fashion, I would think that you would have to go all the way. No matter what version is available, every load of a package from another package is private to that package. A has it's mirage of C and B has it's mirage of C, even if they loaded the same version, and main has no access to either. I happen to have a profiler out there which uses the DB package. What happens if someone loads SmallProf and DProf and the perl debugger all at once? Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == Mathematics is not only real, but it is the only reality. That is that entire universe is made of matter, obviously. And matter is made of particles. It's made of electrons and neutrons and protons. So the entire universe is made out of particles. Now what are the particles made out of? They're not made out of anything. The only thing you can say about the reality of an electron is to cite its mathematical properties. So there's a sense in which matter has completely dissolved and what is left is just a mathematical structure. -- Gardner, Martin == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 76 (v1) Builtin: reduce
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
DC For example, to short-circuit if the reduction ever becomes undef:
DC $sum = { defined $_[0] or last; $_[0]+$_[1] } 0, @numbers;
Chaim Actually, it would be easier to do in reduce, the undefs should
Chaim simply be ignored.
If I understand you correctly, I want to disagree with you.
What if the "reduce" was to count the number of undefs?
$count = reduce { $a + not defined $b } 0, @some_list;
Do not discard undef from the source list.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC: Higher resolution time values
At 08:18 PM 8/9/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 06:16 PM 8/9/00 +, Nick Ing-Simmons wrote: Dan Sugalski [EMAIL PROTECTED] writes: As an engineer I would really like to know when you are going to run out of precision in double - that is forty something bits of mantissa. That is more precision than you have in the real world. It's not precision, it's resolution. What do you do if your timers return values in 1/10ths of a second? What is the problem with that? You can't accurately represent a tenth of a second with floating point numbers. You could if you made 1/10th second the "unit" of the float internally. If we're going to handle them, we might as well be exact. Why - the 1/10 of second is not exact anyway (unless you happen to have an atomic clock in an appropriate physical enviroment attached to your machine). A double's mantissa is better than your typical oscillator. While it may not be correct, at least it's exact. If we go with an inexact representation, we run the risk of accumulating errors and eventually ending up with a number that's both inexact and incorrect. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
Bart Lateur wrote: If you're talking about matrix manipulations, I should immediately hold you back. Perl arrays are pretty bad as is for representing matrices. Don't let anybody tell you otherwise: Perl data structures are one-dimensionaly by nature. A lazily evaluated slicing operator would make arrays look like matrices and tensors (an RFC for this should be appearing RSN). Of course this would have to be implemented efficiently by Perl, which Dan has already talked about doing. For vector manipulation, I can understand that, *in principle*, but not really. I remember that a few functional language extensions have been proposed, including "apply a function (code block) to each combination of item i from the first list with item i of the second list, for each i". You can easily roll your own. It will do what you want, not what the implementors thought useful. For example: vector multiplication. What will @foo*@bar do? Will it return the scalar product (abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector orthogonal to both others), or a matrix multiplication? If you roll your own, you can choose. It should provide a component-wise multiplication by default. This would provide consistency amongst all operators applied to a list in list context (and many functions could provide this behaviour too--like chomp(), as Bryan Warnock mentioned earlier). Of course, if the user wants to overload this behaviour, we should let them. In the multiplication example, however, I would have thought that 'x' is a more suitable inner product operator...
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
I'm looking forward to the upcoming writeup :-). I'm thinking of recanting the whole RFC! :-) Damian
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
Thus it was written in the epistle of Damian Conway, I'm looking forward to the upcoming writeup :-). I'm thinking of recanting the whole RFC! :-) *checking etymology* hmmm . . . "recant" . . . "recant" . . . doesn't that mean to sing the whole thing over again? :-), Ted P.S. Seems to me that while putting hooks in the core to allow this sort of thing might be worthwhile, infinite lists are not likely to be commonly used and so probably should go into a module. -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == You know that I write slowly. This is chiefly because I am never satisfied until I have said as much as possible in a few words, and writing briefly takes far more time than writing at length. -- Gauss, Karl Friedrich (1777-1855) == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)
I'm thinking of recanting the whole RFC! :-) *checking etymology* hmmm . . . "recant" . . . "recant" . . . doesn't that mean to sing the whole thing over again? Literally: "to sing a different tune". :-) Seems to me that while putting hooks in the core to allow this sort of thing might be worthwhile, infinite lists are not likely to be commonly used and so probably should go into a module. Agreed. I hereby bequeath the rewrite to someone else. Damian
overloading assignment operators
Dan Sugalski wrote: Both the l and rvalues will need to participate. Sorry. Quick review of how C++ does it indicates that selecting an assignment operator from the lvalue's methods makes sense. Since we have dynamic typing, there's nothing keeping an assignment method from running through a set of things it would like to be assigned, and interrogating the rvalue to see if it can provide them. But is there really an advantage, or is it just a neat trick? -- David Nicol 816.235.1187 [EMAIL PROTECTED] On hold for tech support since 1995
Re: overloading assignment operators
At 10:33 PM 8/9/00 +, David L. Nicol wrote: Dan Sugalski wrote: Both the l and rvalues will need to participate. Sorry. Quick review of how C++ does it indicates that selecting an assignment operator from the lvalue's methods makes sense. Sure, and using the rvalue makes sense too, in some circumstances. Since we have dynamic typing, there's nothing keeping an assignment method from running through a set of things it would like to be assigned, and interrogating the rvalue to see if it can provide them. Yup, that's true. More work than I'd like to do by default in general, but a small subset's not out of order. But is there really an advantage, or is it just a neat trick? What, to a smart assignment? Sure. It means we can have efficient hash and array assignments, since they won't need to flatten. It means that if Damian gets his higher-order things going we can have assignment defer assignment. It means that we can maybe do 'smart' data copies (or not). It allows a lot of possibility. Whether any are worth making real is another issue entirely. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
