In trying to write some algorithms using the proposed higher-order function
notation, I keep finding myself wanting to explicitly bracket parts of the
curried expression:
$sum_xy = sub {reduce ^last+^x*^y, zip($_[0], $_[1])};
Sure, in this case reduce() would probably be written such that its
> >> An object that has many different -ify methods:
> >> stringify
> >> numify
> >> hashify
> >> listify
> >> objectify (!)
> >
> > Possible, but blech.
>
> Why is that more blech?
Because it's "heavy".
However, if Dan assures me
Damian Conway wrote:
>
>> What is:
>>
>> $x = date();
>>
>> going to return?
>
> Probably the current scalar context result (i.e. a date string)
>
>> An object that has many different -ify methods:
>> stringify
>> numify
>> hashify
>> listify
>
"Bryan C. Warnock" wrote:
> This was the ass that I never found the gall to scratch, because I've
> identified no solutions, and have found only problems.
>
> --
> Bryan C. Warnock
> ([EMAIL PROTECTED])
Let me see if I can paraphrase you accurately:
Defining a framework for modifying compil
> > > 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.
>
> Imagine storing your code along with your data in a database for use
> later (persist
On Wed, Aug 09, 2000 at 11:46:12AM -0500, Garrett Goebel wrote:
> 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?
>
On Wed, Aug 09, 2000 at 10:10:29AM -0700, Nathan Wiger wrote:
> Agreed. General-purpose timezone support is scheduled for a swift and
> painless death in the next version of RFC 48. Only the local timezone
> and GMT will be included in the RFC, same as now.
By "local timezone" do you mean that so
On Wed, 09 Aug 2000, Dan Sugalski wrote:
> I've not seen a pragma yet that affects lexing, though I may have missed
> some. (I don't consider the lexical/package thing a lexer issue, since it's
> not) They change the behaviour of the generated code, yes, but not the
> lexing/parsing/whatever of
> DC> Urgh. If you want lazy eval, say so explicitly:
>
> DC> sub somesub (?@) {
> DC> my @foo = @_;
> DC> }
>
> Where do you want the lazy specified -- on the caller or the callee?
> Or should it be available to both? (and of course the opposite
>
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Urgh. If you want lazy eval, say so explicitly:
DC> sub somesub (?@) {
DC> my @foo = @_;
DC> }
Where do you want the lazy specified on the caller or the callee?
Or should it be available to both? (and of course the
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> It seems to me the generally inability to influence the lexer is the
BCW> one general weakness in Perl.
Well, what's wrong with a builtin macro capablity that is allowed
to read the rest of the input stream. Some parsing would be do
At 09:22 PM 8/9/00 -0400, Bryan C. Warnock wrote:
>But.
>
>It seems to me the generally inability to influence the lexer is the
>one general weakness in Perl.
A weakness shared by pretty much every language I can think of. (Actually I
can't think of one that doesn't have it, but I may be ove
At 07:54 PM 8/9/00 -0600, Nathan Torkington wrote:
>Damian Conway writes:
> > 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()->{
> What is:
>
> $x = date();
>
> going to return?
Probably the current scalar context result (i.e. a date string)
> An object that has many different -ify methods:
> stringify
> numify
> hashify
> listify
> objectify (!)
Possible, but blech.
> While we are here, can reduce itself generate an average? I.e. something
> cuter than:
>
>$avg = reduce { $_[0] + $_[1] } @numbers / @numbers;
Of course.
This is about as cute as it gets:
$ave = ${reduce( bless( \(((ref(^x)?$^x*ref(^x):^x)+^y)/((ref(^x)||1)+1)),
Damian Conway writes:
> 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
(please hold, th
On Wed, 09 Aug 2000, Peter Scott wrote:
> I guess it's getting too incestuous with the lexer.
On Wed, 09 Aug 2000, Nick Ing-Simmons wrote:
> That is the root of the problem.
On Wed, 09 Aug 2000, Damian Conway wrote:
> User-defined operators are a can of rattle-snakes that I *seriously*
> recomme
Joke time on this thread is over, back to work you all!
Nat
(cracking the whip :-)
On Wed, 09 Aug 2000, Brust, Corwin wrote:
> So, kids, whatcha doing with that return value? (the number of characters
> removed by the operation)?
Store it (in paragraph mode) so I know how many \n's to append back on
when spitting the output back. (Provided that matters. Otherwise, I
just ign
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> And for the N case, it gets even uglier. So reduce should be able
>> to supply the next N-1 defined() values.
DC> $def_sum = reduce { $_[0]+$_[1] } grep {defined} @numbers;
Fine.
Even better if the optimizer could recognize the id
Let's not throw this out completely. Let's explore the possiblities.
Making a module local to the using package, might have interesting
properties.
The only items of interest are the globals. And by making them visible
(or a version visible) to the use-ing module, two modules can get
different b
Bryan C.Warnock wrote:
> On Wed, 09 Aug 2000, Jeremy Howard wrote:
> > 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...
>
> And that seems to be wh
On Wed, 09 Aug 2000, Jeremy Howard wrote:
> 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...
And that seems to be where most of the critics of non-sca
[re Pod::Usage and pod2usage]
> i think reading the file may have issues like finding it.
Not a problem. You can tell pod2usage where to look or give
it a search path
> 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
Dan Sugalski wrote:
> 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 Sugalski the even samurai
Why n
On 9 Aug 2000 15:03:40 -, Perl6 RFC Librarian wrote:
>Improved Module Versioning And Searching
[About loading different versions of a module at the same time]
The whole thing sounds whacky to me.
I don't really mind that @INC is searched for the most recent version of
a module, but otherwi
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
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
> > 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 thi
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. Se
> I'm looking forward to the upcoming writeup :-).
I'm thinking of recanting the whole RFC! :-)
Damian
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
Thus it was written in the epistle of Jeremy Howard,
> 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 y
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
> "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
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
> 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
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"?
>: >
>
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 ha
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 p
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..) {
>
> > 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
> "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.
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) -- t
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 o
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
Damian> Actually, the plan is exactly the opposite. By the time I'm finished
Damian> everything will be done...in constant time!
What he keeps failing to mention is that the "constant time" of which
he speaks is greater than the MTBF...
I'm pretty much opposed to this idea. It's pushing OO too far onto perl.
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 C and module C demand two different versions of the same
> : module C, the compiler should halt and state the module conflicts.
>
> Pardon me for snipin
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)
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 -internal
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
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 documentati
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:
>Someone proposed (I think I deleted that email) to make
>
> while () { ... }
>
>work like
>
> while () { chomp; ... }
Guilty.
I've benchmarked the above codes, with '...' replaced by nothing, chomp
vs. the -l command
> >Builtin: reduce
>
> There are some things unspecified. Specifically 'special' reduce variables.
> You've got:
>
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers;
> > $sum = reduce ^_+^_,0, @numbers;
> > $min = reduce ^x <= ^y ? ^x :
At 02:46 PM 8/9/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Builtin: reduce
There are some things unspecified. Specifically 'special' reduce variables.
You've got:
> $sum = reduce {$_[0]+$_[1]} 0, @numbers;
> $sum = reduce ^_+^_,0, @numbers;
> $
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.
> "LW" == Larry W
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 fa
With a regex you can get much finer control; with a "r" modifier
for the regexen indicating that it should start at the end of
the string instead of the beginning the speed issue is gone;
i think unchop and unchomp is silly; that's what .= is for
--
David Nicol 816.
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> 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
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
> "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 psuedohas
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.
>> >>Th
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
>
>
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.
> 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
At 07:45 PM 8/9/00 +, Nick Ing-Simmons wrote:
>Peter Scott <[EMAIL PROTECTED]> writes:
> >At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote:
> >>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 s
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.
Mike Pastore <[EMAIL PROTECTED]> writes:
> Which is the reason I suggest Perl++ as a name for the language, instead
> of Perl6. :)
Be reminded that Perl++ will increment Perl, but return the _current_
value.
-- Johan
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, 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 a
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 $!
> "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
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
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.
On Wed, Aug 09, 2000 at 08:37:35AM -0700, Nathan Wiger wrote:
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
>
> Debugging is great, but I don't think this is the way to do it. The
> reason is some objects might have a
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 lo
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
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 p
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 o
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.
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)
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 oppo
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
> 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
> >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 langua
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> =for pod perl
JP> # this line goes to both the default pod processor AND the perl parser.
but how will perl access that text? what perl var get the text in that
=for block? the proposal for a special here doc notation is possible
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 exp
Larry Wall wrote:
> : 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.
I do too. RFC 79 presumes that POD continues in its state of grace.
> Seems like all we're discussing now is how much those indep
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 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
> >
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 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
> 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 t
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
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
> 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.
I'm no
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 actual
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 insta
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 i
> 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, defi
1 - 100 of 184 matches
Mail list logo
