Great. Let's see if/how this list works.
Edwin Wiles wrote:
> I've already thrown a few notes together for a perl5 module, but nothing
> I'm ready to share just yet. I need to dig through CPAN to make sure
> I'm not reinventing something.
When you are ready to share, I'll be glad to peruse.
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be done
Edwin Wiles wrote:
> On the other hand, the stated desire for this is for commenting out
> blocks of code. That might be more achievable with (I forget the right
> name for this) 'compile time directives' such as "#if", "#endif". We'd
> have to use a different opening syntax, since # is already
Graham Barr wrote:
> > The upcoming Python (v2.0) introduces a builtin called zip() that does
> > the same thing:
> >
> > for a,b,c in zip(aa,bb,cc):
> > ...
> >
> > There are also question on how long the resulting list should be if
> > @a, @b, @c is not of the same length. I think zip(
Ted Ashton wrote:
> > 2) Also this proposition fails in one of my goals, which was to allow
> > arbitrary nesting of multiline comments. I believe this would be true for
> > any function based solution.
>
> Negative. If you use paired delimiters you're ok.
>
> qc( Here's a quick comment which ac
If the file handle becomes an object, they'd be available via member functions
of the object for those that are curious, would they not? And if it is less
than an object, a function could be provided to obtain a pid from a handle.
Tom Christiansen wrote:
> >It seems that this issue is definitel
Bart Lateur wrote:
> On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote:
>
> > [ 'bar' => 'integer32', 'baz' => 'integer32', 'count' => 'integer32' ]
> >
> > [ 'var1' => '
the
script, except for forays into the language of the users of the script.
John Porter wrote:
> Glenn Linderman wrote:
> > >
> > > qc( Here's a quick comment which actually contains
> > > qc( another comment )
> > > within it
> > > );
&
John Porter wrote:
> Glenn Linderman wrote:
> > Stick with characters in the normal character set of the author of the
> > script, except for forays into the language of the users of the script.
>
> Good advice for the programmer, perhaps; but it should not be perl&#x
John Porter wrote:
> Glenn Linderman wrote:
> >
> > Agreed, but neither should perl implement features which make it hard for the
> > programmer to stick to that advice.
>
> That sounds reasonable, on first take, but actually I think that
> goes against the grain
Larry Wall wrote:
> A less obvious strategy is to try to see where various marginal
> features could be subsumed under some more powerful feature.
In general, this is a good^Wgreat concept to avoid multitudinous small features.
> To some extent,
I'm glad you qualified this...
> you see this w
The problem with lexical variables being made default, in earnest, is
simple, and error-prone:
code;
if ( condition )
{ more code;
$x = 'did then'';
} else
{ more code;
$x = 'did else';
}
print $x;
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x
Instead of "local", how about...
reuse
redef
our_temp
Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Rename the C operator
>
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
NetZero Free Internet
Andy Wardley wrote:
> What about '$me'? It ties in nicely with 'my' (although perhaps for the
> wrong reasons), it's half as much typing as 'self' or 'this' and we get
> to annoy both sets of religious zealots at once. :-)=
Yes, absolutely. Now what good meanings could we attribute to $mysel
Damian Conway wrote:
>> Could a way be found to control the flow so that the next case (not always
>> the one next in the order of the statment) could be executed? For example
>> you have cases 1-10. You want all odd cases to also execute case 9 and the
>> even cases to also execu
Great idea! (Don't accuse me of apathetic lurking!)
I suspect it already has a different meaning, based on operator precedence rules,
left to right evaluation, etc., but I strongly doubt there is much use of it in
that manner, and would encourage this redefinition to be used instead.
Perl6 RFC
This switch statement RFC seems to be built on the premise that the reason to have a
switch
statement is to remove a common parameter from the following limited form conditional
expressions. For that reason, two new keywords are required: switch: to define the
common
parameter, and case: to int
John Porter wrote:
> Glenn Linderman wrote:
> >
> > What good are comments if you can't find them when you need them?
>
> There's not thinging to stop you from writing
>
> qc/*** MAGIC HERE */;
Oh so true, but there&#x
Damian Conway wrote:
>> This switch statement RFC seems to be built on the premise that the
>> reason to have a switch statement is to remove a common parameter
>> from the following limited form conditional expressions.
>
> Yes. As I point out in the paper, that's the *nature* of a s
Ken Fox wrote:
> Then write the switch as:
>
> switch ( __ ) {
> case $v == 1: { ... }
> case $v == 2: { ... }
> case $v == @foo { ... }
> }
>
> It might take you a little while to get your head around the __
> symbol. I'm not sure it's useful to think of it as a variable;
> poiso
[EMAIL PROTECTED] wrote:
> On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote:
> >=head1 IMPLEMENTATION
> >
> >Remove the file-globbing behavior of the angle brackets.
>
> How about "Deprecate use of file globbing with angle brackets. Emit a
> warning when this behaviour is used
Johan Vromans wrote:
> An alternative solution is to automatically sent all messages that have
> been posted to the sublist so far, upon subscription.
If there are less than 100 of them, this is probably an excellant idea.
I still haven't received anything directly from -mlc, although I've
rece
Edwin Wiles wrote:
> Without them, the programmer must calculate the required length of the reads
> themselves.
Good point. I now want them, rather than being ambivalent.
> >[ 'bar' => 'i', 'baz' => 'i', 'count' => 'i' ]
>
> It is my understanding that "=>" is an indication of a link in a
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Edwin Wiles <[EMAIL PROTECTED]> wrote:
>
> > Endianness:
> >
> > /d - default, whatever your system uses normally
> > /n - network
> > /b - big
> > /l - little
> > /v - vax
> >
> > (??vax is sufficiently different to require it's own?
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
> Also, I would vote for a method to return the Julian date (yes I am an
> astronomer...) :-)
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_NetZero
An excellant idea, in my opinion.
It would be a very appropriate use of structure handling to address system APIs
with structures as parameters or returns. Indeed, stat, localtime, and other
firends could be handled via predefined structure definitions. This is not to say
that we should elimina
Bart Lateur wrote:
> >The C operator of Perl5 and earlier does not do what it claims
> >to and should be renamed.
>
> How about:
>
> override
>
> meaning: ignore the value you've seen so far, for now, you'll use my
> value.
This is the sort of thing I was looking for when I proposed "red
Andy Dougherty wrote:
> On Mon, 7 Aug 2000, Glenn Linderman wrote:
>
> > Me too, and I'm _not_ an astronomer.
> >
> > Tim Jenness wrote:
> >
> > > Also, I would vote for a method to return the Julian date (yes I am an
> > > astronomer...)
Damian Conway wrote:
> I often need a generic comparison test (typically for equality of less-than),
> and to get it one has to jump through hoops:
>
> sub generic_eq {
> my $failed;
> local SIG{__WARN__} = { $failed = 1 };
> return $_[0] eq
Jeremy Howard wrote:
> Damian Conway wrote:
> > Personally, if we have positional placeholders I don't see the need
> > for named ones too. But I'm willing to be convinced.
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm will
John Porter wrote:
> Glenn Linderman wrote:
> >
> > When using an inline comment, I want to spend my character budget mostly
> > on the comment, and just enough on the delimiters to see it
> > effectively. #< magic here ># would do quite nicely
> >
> &g
Perl6 RFC Librarian wrote:
> It is proposed that a new syntax for declaring constants be introduced:
>
> my constant $PI = 3.1415926;
> my constant @FIB = (1,1,2,3,5,8,13,21);
> my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed');
I like this. Implementation wise, it coul
Perl6 RFC Librarian wrote:
> The => operator would cease to be a
> first-argument-stringifying comma operator
I find nothing in the documentation that suggests that => is anything other than a
plain comma operator, yet you call it a "first-argument-stringifying comma
operator". In fact, the doc
Damian Conway wrote:
> Currying placeholders are scalars
Is that a general truth? It wasn't obvious from RFC 23... If you rev it, perhaps
you could make that clearer.
Looking back, the defining example did give a list of (;) in the prototype. I
suppose it would be pretty complex to infer
Damian Conway wrote:
>> I find nothing in the documentation that suggests that => is
>> anything other than a plain comma operator, yet you call it a
>> "first-argument-stringifying comma operator". In fact, the
>> documentation explicitly claims "=>" is a synonym of "," (see
>
Peter Scott wrote:
> Have you used strict lately? :-)
No, but the documentation for strict is some of what I reread before making a
fool of myself arguing with Damian, and it says nothing about barewords, as far
as I could read.
Having used it on occasion, I am aware it _does_ have some effect
Nice. But you need to discuss the initial condition: I'd guess you need
an
implicit
=begin perl
before line 1 of each script file, so that scripts that don't pod still
work.
How about some extensions, which integrate another old perl5 feature?
Instead of __END__, how about
=begin data
Now t
number. Perl 5.something. Probably pretty early.
Perhaps the printed docs should preserve their version, starting with perl6 (or
earlier)... just to remind one of their age...
Bart Lateur wrote:
> On Thu, 10 Aug 2000 17:59:52 -0700, Glenn Linderman wrote:
>
> >I find nothing in the d
Peter Scott wrote:
> I have often wished that digraphs were not bundled with variables in this
> respect, i.e., I wanted to put a string containing \n inside single quotes
> just 'cuz it didn't contain variables to be interpolated. Whether there's
> a way of improving this behavior or not I don'
Chaim Frenkel wrote:
> Would Unicode reduce the problem? Take some operators from the math symbols
> and make them the matrix op versions?
>
> (Now, if we add all that APL symbols ...)
Chaim, I think you are on to something here. But before jumping to Unicode or APL
to get more line noise, let'
Seems like the results of
@b = 1 .. 10;
for ( 1 .. 3 )
{ push @a, pop @b;
}
and
@b = 1 .. 10;
push (@a, pop ( @b, 3 ));
But this RFC makes it seem like they produce different results in @a. One could
argue that the current definition of unshift has a similar problem, and that you
are "preserv
There is already precedent (-M, et alia) for a "perl epoch" which is time
since the start of execution of the script. Negative numbers are used to
represent times prior to the start of execution, and positive numbers are used
to represent times after the start of execution.
The "perl epoch" does
[EMAIL PROTECTED] wrote:
> On Mon, Aug 14, 2000 at 11:27:35PM -, Perl6 RFC Librarian wrote:
> >
> >Inline Comments for Perl.
>
> What relationship does this have to RFC 5 (multiline comments), and
> hasn't the discussion of inline comments occurred in detail already?
Highly related. But sin
This deserves a "me too".
Perl6 RFC Librarian wrote:
> The camel and the docs include this example:
>if (/Time: (..):(..):(..)/) {
> $hours = $1;
> $minutes = $2;
> $seconds = $3;
> }
>
> This then becomes:
>
> /Time: (?$hours=..):(?$minutes=..):(?$seconds=..)/
Nathan, thanks for zeroing in on this paragraph from RFC 23. It raises a
question in my mind about the meaning of the RFC, and whether the paragraph is
even necessary, which could answer your question about implementation.
If a curried subroutine is truly generated because of seeing an expressio
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
> : > > consider the $ and $b to be warts.)
>
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ou
Clever, and really obscure; wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a & ^b, and that everyone
writing a non-curried sort sub name their parameters a and b? I guess that
wouldn't necessarily be bad, but it would be restrictive.
Damian Conw
Damian Conway wrote:
>> Clever, and really obscure;
>
> "Invisible", rather than "obscure", I would say.
> DWIMity of the first order. :-)
>
>> wouldn't this then require that _everyone_ that
>> writes a curried expression for the sort sub use ^a & ^b, and that everyone
>> writing
Well, RFC 23 doesn't mention ^0, and has several examples starting at ^1. And
it draws the analogy between ^1, ^2, etc and $1, $2, etc. I didn't make it up.
So I don't think you're being consistent here. Neither do I consider it an
improvement to add ^0.
While the positional placeholders may w
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
firmly planted on cheek.]
Bart Lateur wrote:
> On Wed, 23 Aug 2000 17:24:23 -
Dan Sugalski wrote:
> At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
>
> >--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
> >
> >>Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
> >>errors, people that want to write fa
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Just to point out that fatal is, indeed, as several people keep
> > saying, truly in the eye of the catcher.
> >
> > That said, none of the currently proposed mechanisms permit
> > "resume from fault
Yes, these all sound useful! Damian, could you make sure they get included
in your switch statement?
And don't forget
=:=
which should compare lazy, infinite sublists, as in
if ( 4..:2 =:= 2 * ( 2.. )) { ... }
Jarkko Hietaniemi wrote:
> I want four special new comparison operator
a -language topic that hasn't
been discussed much.
"David L. Nicol" wrote:
> i think he meant the windoes95 BSOD kind of GPF; that's how I read it at leas
>
> Glenn Linderman wrote:
> >
> > Dan Sugalski wrote:
> >
> > > At 02:48 AM 8/24/0
Chaim Frenkel wrote:
> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4)
>
> Actually, looking at it like that makes it an ugly situation. The 'new'
> expectation would be to have it become
> # $foo=1 $baz=2 @bar=(4)
Actually? How about it becoming
Jeremy Howard wrote:
> New programmers should easily understand that:
> - $foo is the variable 'foo'
> - _foo is the placeholder 'foo'
> - $_ is the default variable
> - __ is the default placeholder.
> Then, when they see the same named placeholder appear twice in the same
> higher-order
John Porter wrote:
> So, instead of "throw": "throwup".
That leads me down the path of "puke" and "scrub" instead of "throw" and
"catch". Actually, I rather liked the "oops" Scott suggested, but used in
place of "throw" instead of a rename of "exception". So how about "oops" and
"recover" inst
Nathan Wiger wrote:
> Bart Lateur wrote:
> > Why interpolate "$obj->method" and not "Class->method"?
>
> This is a decent point worth considering.
>
> I think another way to look at it which is more accurrate is that -> is
> special in many cases already:
>
>/$foo->{blah}/ # -> special
Eric Roode wrote:
> >Imagine that you could easily override the conversion of undef() into a
> >string, so that when stringified it returns something like "#UNDEF#"
> >instead of just an empty string. That would make debugging far more
> >easy: take a look at the output, and search for this senti
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace
Nathan Wiger wrote:
> I don't know about this. What if someone writes:
>
>print "You owe me $2, $name.\n";
>
> With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
>You owe me $2, Nate.
>
> But without it it won't?
>
>You owe me , Nate.
You turn
Michael G Schwern wrote:
> On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
> > The rest is handled adequately and consistently today, and Tom's
> > dequote is adequate to eliminate leading white space... especially
> > among people who cannot agree
John Porter wrote:
> Chaim Frenkel wrote:
> >
> > Removing -1 as a valid result, could be a breakage (if someone is
> > doing something weird with a negative result)
>
> What, like using it as an index into a substr?
> Bad Code is its own reward, my friend.
>
> > $foo = "flabergasted";
> >
Nathan Wiger wrote:
> Solves problem #1, indented terminator, except that it adds two newlines
> (more later).
I never found anything later about these extra newlines... so if this idea
has merit, it needs to be finished.
> However, it leaves 2 and 3. Let's try adding in a regexp:
>
>if( $i
Glenn Linderman wrote:
> I think $mesg wins up with the value of "1" the way you've coded it.
Sorry, I missed the placement of the (). $mesg is fine.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on...
Michael G Schwern wrote:
> On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
> > I'm all for solving problems, and this message attempts to specify 3
> > problems, but it needs more specification. You describe three
> > problems, but it is not c
I _like_ the conceptual idea, here. But I think we need a different kind of
quoting, not extend single quote semantics. Single quote semantics are really,
really, good for exact quoting. I'm sure you (since you mention VMS) find single
quote semantics good for escaping all those $ VMS requires.
Damian Conway wrote:
>> now, what if the double quoted range had a \E in it? either directly or
>> via interpolation? maybe the end escape should be another char than \E?
>
> Make \E significant only where it's explicit.
None of the \ escapes are significant via interpolation, even today
Simon Cozens wrote:
> sub interpolate {eval "\"@_\""}
>
> Never say "there is no way". There's *always* a way, and 99% of the time it
> doesn't need to go in core.
Yes. Well, actually if you carefully read the thread about RFC 111 in which I got
the inspired flash that interpolation of variable
Certainly I could live with this set of suggestions. The complete set. Thanks
Richard and Michael for developing them.
Michael G Schwern wrote:
> I'd say:
>
> 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the
>terminator, but it doesn't effect anything)
>
> 2) <<<
Richard Proctor wrote:
> > Maybe I'm being too simplistic, I don't use tabs anymore.
> >
>
> Yes you are, the problem comes with mixing editors - some use tabs for
> indented material some dont, some reduce files using tabs etc etc. [I move
> between too many editors]. Perl should DWIM. I thin
Chaim Frenkel wrote:
> >>>>> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> GL> Chaim Frenkel wrote:
> >> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4)
> >>
> >> Actually, looking at it like that make
Chaim Frenkel wrote:
> But you would still have to catch the exception. Not a nice thing to
> terminate the program just because an expected mismatch occured.
Sometimes it is, sometimes it isn't.
> Not finding something is not exceptional.
Sometimes it is, sometimes it isn't. Why were you loo
Chaim Frenkel wrote:
> I thought he was asking for evaluating until nothing is left to interpolate.
I wasn't, just some number of iterations of interpolation, but "infinite"
iterations of interpolation is an interesting idea, and could be added as a special
case... Such would make it hard to "es
Tom Christiansen wrote:
> I am certainly in strong favor of a simple and visually distinctive
> solution, and find that the leading bit helps a lot. But I would probably
> have written that as:
>
> die < !The old lie
> ! Dulce et decorum est
> ! Pro patria mori.
> P
Chaim Frenkel wrote:
> >>>>> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> >> Neither is EOF on a file, or working with an empty list. Adding all these
> >> exceptions for non-exceptional and quite common scenerios is bothersome.
&
Chaim Frenkel wrote:
> What about a hypothetical, use tristate. This would give undef some
> extra special powers.
There is a difference between "undefined" and "unknown".
SQL NULL, and the resultant tristate operators used in SQL, specifically is based
on NULL representing the "unknown" value.
Perl6 RFC Librarian wrote:
> The & is mandatory.
Which makes me happy with this proposal
> Parens are also mandatory if
> arguments are to be passed.
And I guess the balancing of the parens would solve many of the problems of
argument parsing for the function, which is a concern to me. Within
John Porter wrote:
> Glenn Linderman wrote:
> >
> > The idea of a _normal_ situation being considered exceptional is raised when the
> > code written inappropriately handles some of the normal return values.
>
> You would throw exceptions at the problem of bad cod
Chaim Frenkel wrote:
> >>>>> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> GL> There is a difference between "undefined" and "unknown".
>
> GL> Perl undefined is a different concept--that of an uninitialized
&
Tom Christiansen wrote:
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
>
> --tom
Sam Tregar wrote:
> Does it really make it more difficult? I would argue that having NULLs
> mapped to undefs is actually better than having real NULLs in Perl. An
> undef is a rather concrete and easily dealt with value - simply test with
> defined(). Plus, if you're careless enough to try to
Russ Allbery wrote:
> I agree with Tom; I think it's pretty self-evident that they're the same
> thing. undef means exactly the same thing as null; that's not the
> problem. The problem is that Perl doesn't implement the tri-state logic
> semantics that most users of null are used to, which is
Damian Conway wrote:
> Should I point out that RFC 225 (Superpositions) actually covers most of this?
>
> C is equivalent in semantics to C or C.
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll spend my time
John Porter wrote:
> Nathan Wiger wrote:
> >
> >undef null
> >
> >$a = undef; $a = null;
> >$b = 1; $b = 1;
> >$c = $a + b; $c = $a + $b;
> >$c is 1
Damian Conway wrote:
>> > Should I point out that RFC 225 (Superpositions) actually covers
>> > most of this?
>> >
>> > C is equivalent in semantics to C or C.
> I hope you won't mind my pointing out that the documentation of the
> Quantum::Superpositions module -- to which the R
"Konovalov, Vadim" wrote:
> I'm quite sure that adding "null" into the language will complicate
> programming and hardly will give any benefits. One should differentiate
> between "null" and "undef", sometimes (or better always!) check variables
> with defined(...) *and* isnull(...).
Unlike unde
"H.Merijn Brand" wrote:
> On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > =head1 TITLE
> >
> > Add null() keyword and fundamental data type
> >
> > =head1 MIGRATION
> >
> > None. New functionality.
>
> Not true. Apart from the discussion if undef is the same as n
John Porter wrote:
> Nathan Wiger wrote:
> >
> > Since undef() has established semantics, I don't think these should
> > change. I believe taking from RDBMS and adding null() which has the
> > correct NULL semantics is the way it should go.
>
> You realize, I hope, that there is no end of differe
Russ Allbery wrote:
> Glenn Linderman <[EMAIL PROTECTED]> writes:
> > Russ Allbery wrote:
>
> >> I agree with Tom; I think it's pretty self-evident that they're the
> >> same thing. undef means exactly the same thing as null; that's not
Sam Tregar wrote:
> On Tue, 19 Sep 2000, Glenn Linderman wrote:
>
> > They are different. Neither is a mistake.
>
> How do you explain the fact that every SQL book I've ever seen has
> included copious text on problems concerning NULL?
I'm not sure what SQL b
Bad idea. See my multitudinous posts on why. Briefly:
1) can't use null and undef together
2) not extendable to 29 versions of null, when SQL defines them
Nathan Wiger wrote:
> Graham Barr wrote:
> >
> > If you want an operator to act differently on some piece of data then a pragma
> > is the
Damien Neil wrote:
> On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> > Add null() keyword and fundamental data type
>
> I think that this is better done as a special overloaded object used
> by database modules which wish to implement SQL-style tri-state logic.
It could be
Eric Roode wrote:
> Glenn Linderman wrote:
> >Eric Roode wrote:
> >
> >> 1. You don't say in your RFC, but I'm guessing, that a null value
> >> evaluates to false in a boolean context. Correct?
> >
> >I would expect it to be considered false
Tom Christiansen wrote:
> > no strict;
> > $a = undef;
> > $b = null;
>
> Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted. NULL is neither number nor st
Tom Christiansen wrote:
> Perl has *one* out-of-band value. It doesn't need more. That
> doesn't mean that perhaps some rare sorts of programming might not
> benefit from fancy weirdnesses. That's what modules are for.
> You don't need to complicate the general language to get what
> you want.
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
> >It only takes a few pages, and a few truth tables to explain NULL.
> >It should only take a few pages and a few examples, to explain the
> >difference between undef and null.
>
Russ Allbery wrote:
> Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> > undef has the following semantics:
>
> > 1) all otherwise uninitialized variables are set to undef
>
> And as the RFC says, quite a few times, for database code you often want
> all your
> By your "reasoning", we can just add infinitely more things that
> take twice a few pages to explain.
You took that to an illogical extreme conclusion. Clearly you can't add
everything to the language. However, it is clear by the set of currently
submitted RFCs that more people think suggesti
Tom Christiansen wrote:
> >That's an empty string. In any case, if you really want to call it a
> >null string, that's fine, just a little more likely to be
> >misinterpreted.
>
> In Perl, this is the null string:""
> In Perl, this is the null character: "\0"
> In Perl, this is the null list
1 - 100 of 166 matches
Mail list logo
