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;};
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
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
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
"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
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
"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
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
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.
=head1 TITLE
Higher order functions
Sounds good. We should add this to the language. Oh boy, the tricks we
can play with this...
Hildo
=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
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
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/
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"
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
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
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
- 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;
* 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
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
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
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:
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 =
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?
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; #
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
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
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
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
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
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
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
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,
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:
:
:
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
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
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
[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
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
"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
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
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
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
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
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
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
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
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
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
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
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
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 :-)
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
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
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
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:
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.
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
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,
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
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
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
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
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 |
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
"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
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 $!
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
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
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.
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
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.
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
"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
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
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
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
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
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
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
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
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
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
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
"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
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
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..) {
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
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
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"?
:
:
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
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
"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
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
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
I'm looking forward to the upcoming writeup :-).
I'm thinking of recanting the whole RFC! :-)
Damian
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
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
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
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
1 - 100 of 126 matches
Mail list logo
