Larry Wall wrote:
>I cringe every time someone says "Parens construct lists in Perl 6."
>Parens don't construct lists in Perl 6.
>
>: Additionally, parentheses have one inconsistency which brackets do not:
>: This is the following case, already shown on perl6-language:
>:
>: $a = ();
Damian Conway wrote:
> For an C without modifiers, (...) are certainly unambiguous as delimiters.
> So I think they should be allowed. Of course, it's Larry's call and he may
> well prefer the simplicity of a blanket prohibition.
So one thing that bothers me in the whole discussion of rule vs rx
Deborah Ariel Pickett wrote:
> I'm imagining a table something like this:
>
> Subroutine Pattern matching
>
>
> Default { code } / pattern /
> delimiter
>
> Declare
Larry Wall wrote:
>
> If we're going to make it a method, however, it's possible that "curry"
> is the wrong popular name, despite its being the correct technical name.
> There's really nothing about the word "curry" that suggest partial
> binding to the casual reader. Perhaps we really want som
Allison Randal wrote:
> You know, I almost made a very similar reply. But I read through
> Damian's message a second time and changed my mind. C makes
> sense as a C minus C. As a C minus C it's less
> appealing. At the very least it begs a different name than "BETWEEN" (a
> name that implies it
Allison Randal wrote:
> What if $_ were dynamically scoped, but only for subroutines? Dynamic
> scoping is not necessarily the same thing as a global $_. It would
> merely pretend (only for $_) that the subroutine had been defined in the
> scope where it was evaluated. But that could get you into
Allison Randal wrote:
> > In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
> > > $_ becomes lexical
> Sound logic. And it almost did go that way. But subs that access the
> current $_ directly are far too common, and far to useful.
One thing I'm missing
Trey Harris wrote:
>
> Oops, caught my own mistake...
> Because $_ is always the topic, which is always the first parameter to a
> block, which in subroutines is @_[0], right? So in a sub, $_ == @_[0].
> The only question I have is if you modify @_ with a shift, does $_
> continue to point at t
Graham Barr wrote:
>
> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > > method m1
> > > {
> > >m2; # calls method m2 in the same class
> > Yes, but does it
David Whipp wrote:
>
> Mark J. Reed wrote:
> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > > method m1
> > > {
> > >m2; # calls method m2 in the same class
> > Yes, but does it call it as an instance method on the curr
"Mark J. Reed" wrote:
>
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2; # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class meth
Allison Randal wrote:
>
> On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
> > Larry Wall <[EMAIL PROTECTED]> writes:
> >
> > > We're talking about how to make .foo mean self.foo regardless of the
> > > current topic.
> >
> > Are we? I was looking for a way to unambgiously access the
Graham Barr wrote:
>
> On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
> > I think you just said the same thing I did. To be more explicit, using
> > the terminology you seem to want to use, I'll point out that I was only
> > talking about the case
Melvin Smith wrote:
>
> > > If you wouldn't want the base implementation to be ignore there is usually
> > > some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
> > > sure.
> >
> >I'm not sure either. In fact, I'm not sure what you mean by this
> >sentence at all. If it matt
Melvin Smith wrote:
>
> >Methinks (that's me, not you) that if me thinks (that's you, not me)
> >that my argument is an argument *for* it being pretty odd *not* to
> >inherit them, that there is an assumption by me or me (that's one or the
> >other of us) that is clearly wrong about the way inher
Me wrote:
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a LAST block to a method. I
Michael G Schwern wrote:
>
> In this case I'll take long-term simplicity over short-term
> easy-to-explain rules. Otherwise we'll be writing this all over the
> place til Kingdom come.
>
> do {
> if my $foo = bar() {
> ...
> }
> }
I'm surprised no one else h
"Bryan C. Warnock" wrote:
>
>
> Is it POST, LAST or LAST, POST, at runtime?
Since POST is checking invariants, and LAST can have side effects, LAST
must be executed before POST.
Apo 4 said POSTs were executed in the reverse of the order seen, I
presume that would hold for LAST as well.
> How
Me wrote:
> > [concerns over conflation of post-processing and post-assertions]
>
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").
>
> --me
Yes, very, very cool.
I especially liked how RFC 88 was "accepted wi
That particular example is flawed, because the try expression is turned
into a try statement because the } stands alone on its line.
But if you eliminate a couple newlines between } and for, then your
question makes sense (but the code is not well structured, but hey, maybe
you take out all the n
Aaron Sherman wrote:
> On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
>
> > So then the lexically scoped operator:+ wouldn't be able to achieve
> > the goal of my suggested implicit numerification warning... the goal
> > being the ability to ensu
Larry Wall wrote:
> Aaron Sherman writes:
> : On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote:
> : >
> : > Glenn wrote:
> : >
> : >> > Have I missed anything?
> : >>
> : >> Perhaps you've missed one thing.
> : >>
> : >>[snip]
> : >>
> : >> Perl 6 coul
Damian Conway wrote:
> Have I missed anything?
Perhaps you've missed one thing. It was kind of in a different branch of the
thread, about string numerification yielding NaN when given input that is "bad"
according to some definition of "badness". It was clear from discussion that
various contr
Aaron Sherman wrote:
> I see your point, but going from: "you have to error-check to be
> sure that the average you get is valid" to "you get NaN and like it"
> is a bit steep.
"you get NaN and like it" only happens when you put garbage in... and get garbage
out.
Yes, NaN is garbage. But when
Aaron Sherman wrote:
> Let's take this code as an example:
>
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
>
> Right now, if my expected numeric column has garbage in it on the
> 400,00
Aaron Sherman wrote:
> > It's bothered me that I can write 100_000 in my perl code, but if I have
> > a string "100_000" it'll evaluate to 100 when numerified. It would be
> > really weird if "10indigo" became 10i, "1e3foobar" became 1000, and
> > "10_000" became 10 in Perl 6 IMHO.
Note that in
Trond Michelsen wrote:
> There's always the possibility of supporting SI's binary prefixes ;)
>
> http://physics.nist.gov/cuu/Units/binary.html
An excellant idea. I was unaware of that standard, but was trying to head that
direction in my last posting.
Someone thought it wouldn't work with ima
Dan Sugalski wrote:
> At 04:42 PM 10/10/2001 +0100, Sam Vilain wrote:
> >On Wed, 10 Oct 2001 11:32:02 -0400
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > >Great idea, as well as sqrt(-1) returning 1i istead of raising the
> > > >exception.
> > > If we do them, yep. Currently no promises th
Why would it?
Someone posited a nested stack of parsers, this thread is discussing the
abandonment of one parser when going to the next. Really, the claim
that it should be up to the invoked parser to determine where to go next
allows the invoked parser to have syntax to return to the prior par
Why not
@foo = @( a + b ); # element by element add of @a and @b
or even
@( foo = a + b ); # element by element add of @a and @b assigned to
@foo.
I guess one could claim the idea is similar to the old BASIC MAT prefix,
although it was clearly reached by a different path. This could
Nathan Torkington wrote:
> Not a comment at all on it? Was I accidentally unsubscribed to
> perl6-language?
>
> *tap* *tap* is this thing on?
>
> Nat
Yes, well, my first impulse was to reply, making appropriate "Wow,
that's cool" type of remarks, and then I decided to let it sink in a few
days,
Nathan Wiger wrote:
> Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting.
> Forget p52p6 and the whole 80/20 thing, we could potentially hit the
> 100% mark.
Wow, that's cool!
> I'm unsure about the "module main" idea. I like that modules as a whole
> are strict/-w by default.
John Porter wrote:
> > So in RFC 119, we have in-scope catch statements, dangling except
> > clauses, and dangling always clauses.
>
> I'll go on the record as saying that I am totally opposed to
> dangling "clauses" of any kind.
Now that's just the sort of Gibralter-like position that begs to b
syntax and semantics
of exception handling, so RFC 119 is unaffected.
Bart Lateur wrote:
> On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote:
>
> >In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
> >set to the result of an eval or do. Ho
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Tony Olekshy wrote:
> > >
> > By rule 2 above, it would seem that if $p->foo raises an Error:IO
> > exception, that the except block hasn't yet been seen, and
> > therefore the block shoul
Tony Olekshy wrote:
> 2. Support always and except blocks. These constructs may be used
> without requiring a try before the block. They are dynamic
> operations which only come into play when they are encountered
> in the block, in run-time order.
...
> If we take this approach
Tony Olekshy wrote:
> Traditionally Perl has had both the "do" and the "eval" block
> forms, the latter which traps, the former which doesn't.
In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
set to the result of an eval or do. How does this impact exception
handling tes
Tony Olekshy wrote:
> I think "always" should be part of an explicit statement, such
> as "try", not some implied property of block structure introduced
> by a dangling clause (inside or outside).
Funny, during the perl6 RFC period, during the discussion of the exception
handling RFCs 88 and 119
Damian Conway wrote:
>
>return ( $stuff, $morestuff, $whatever ) always close F;
>
> I *really* like that keyword.
>
> Though I'd prefer to see it as a block suffix:
>
> sub {
> ...
> return $yadda_yadda;
> }
> always { close F }
In RF
Damian Conway wrote:
> Actually, I do agree that Perl 6 ought to provide a universal "destructor"
> mechanism on *any* block. For historical reasons, I suppose it should be
> C, though I would much prefer a more generic name, such as
> C.
Both of the exception handling RFCs discuss an "always" b
David Cantrell wrote:
> And in any case, I can think of three different ways of saying 1821 in
> English alone.
>
> One thousand eight hundred and twenty one
> One thousand eight hundred twenty one
> Eighteen hundred and twenty one
>
> As far as *I* am concerned, the middle one is wrong (although
Simon Cozens wrote:
> (Incidentally, has anyone noticed that John Porter and I appear to have
> *completely* different opinions about *everything*?)
Good thing you're both on the committee...
O O
<
\/
--
Glenn
=
Even if you're on the right track,
you'll get run over if you j
Damien Neil wrote:
> Having said that, I'm not fond of writing XML/HTML by hand. I'd far
> rather write an author-friendly language and have that translated to
> XML.
Indeed, this is the key problem with human use of XML. HTML was originally
simple enough to be human writable, its later, more
Bart Lateur wrote:
> On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
>
> >But setting $[ = 1 is the mathematically correct method for
> >array addressing and makes it easier for ordinary mortals to do
> >basic tasks with C, array addressing and the like.
>
> I sure don't want the fact t
"David L. Nicol" wrote:
> >
> > This is a new feature, so name conflict is the only issue.
> >
> > Thisseems compatiblewith otherextensionsto string
> > interpolation... whatever extensions get implemented should work here
> > too.
>
> it's not a new feature. It's amazing
Nathan Wiger wrote:
> (And if the RFC is proposing autoquoting only barewords, then I think
> that's _really_ inconsistent and should not be done.)
Isn't autoquoting only barewords precisely the type of autoquoting that => does?
So there is a precedent. I've been assuming all along that that is
"John L. Allen" wrote:
> On 29 Sep 2000, Perl6 RFC Librarian wrote:
>
> > Make Perl's powerful string interpolation facilities are available to
> > variables, in addition to literals.
> >
> > =head1 DESCRIPTION
> >
> > Given:
> >
> > $foo = 'def';
> > $bar = 'ghi';
> > $x = "abc$foo$bar";
> > $y
Russ Allbery wrote:
use 'strict' is probably the difference between our code... I tend not to use
it, because I wrote a bunch of code that didn't, initially, before I heard of
it (maybe before it existed? I started with Perl 4.something), and haven't
gotten it all converted so that it can be us
Russ Allbery wrote:
> Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> > In my opinion, which you probably will also not agree with, attempting
> > to toggle between the current undef semantics and tristate semantics is
> > like trying to stuff three values into on
Michael Maraist wrote:
> > my/our @array :hashsyntax;
> >
> > would hide the definition of %array in the same way that
> >
> > my/our %array
> >
> > would hide a prior definition of %array. And references to %array
> > would thenceforth actually be references to the keyed array @arr
Russ Allbery wrote:
> I'm not overlooking it; I just don't agree with you. There *is* a
> difference.
You are certainly welcome to not agree with me. And if you didn't overlook
it, that is fine.
In my opinion, which you probably will also not agree with, attempting to
toggle between the curre
Buddha Buck wrote:
> Ok, let's see if I can make some sense of this...
Thanks for trying. I think you have.
> You want a singleton scalar datatype in addition to the exising scalar
> datatypes of strings, numbers, references, filehandles, and undef that
> represents an unknown value, similar i
John Porter wrote:
> Glenn Linderman wrote:
> >
> > If they are the same, then you can't tell the different between a variable
> > that is yet uninitialized, and one that has been read in from the database,
> > containing a NULL. In my mind, that is horribl
Graham Barr wrote:
> On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
> > Russ Allbery wrote:
> >
> > > Why on earth would you want to do this in real code?
> >
> > I wouldn't, of course. This is just a demonstration that I want both
>
Philip Newton wrote:
> Having $seen{$word}++ turn $seen{$word} to undef is bad, if (undef)++
> assumes NULL semantics everywhere, hence "one more than unknown" = "still
> unknown".
Right. Applying NULL semantics to undef would be bad. The counterproposals to
RFC 263, along the lines of "use tr
Thanks, Paris, for your intervention, although I fear it was too late.
Well, since Tom claims to have put me in his kill file, he may never see
this. But for the record...
Tom Christiansen wrote:
> >Can't we all just play nice?
>
> Apparently not. Several of us attempted to explain why this
Tom Christiansen wrote:
> A null is a null byte, or a null character. Period.
ASCII, a standard that long predates Perl, defines the term NUL, not NULL, to refer
to a null byte or null character. You are not correct, period or otherwise.
> You are
> completely out of your mind if you expect t
Damien Neil wrote:
> I suggest that you read up on the difference between "use strrict" and
> "use warnings"/-w.
Thanks, yes, I figured out the "no warnings" issue afterwards.
> Furthermore, you may wish to take the five seconds necessary to
> understand WHY it prints that message when you prin
Peter Scott wrote:
> $employee{$empno}{SAlARY} -= 10_000; # IPO failure
> $employee{$empno}{FAX} = '888-555-1212';
>
> First one got the wrong key when my finger slipped on the shift key, second
> one got it when I misremembered FAX instead of FACSIMILE. But in neither
>
Paris Sinclair wrote:
> If
> you need additional semantics than provided by undef, why not make a
> module?
This might be workable. There are some thoughts on that. Personally, I
haven't used that much overloading in Perl to know whether it can be made to
work well enough to completely confor
John Porter wrote:
> > >$a = null;
> > >$b = ($a == 42);
> > >print defined($b)? "defined" : "not defined";
> >
> > >would print "not defined", maybe?
>
> defined() is the wrong operator to be using there. Rather,
The tri-state logic deals with "true", "false", and "unknown" (not
NUL
Peter Scott wrote:
> At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
> >OK, scalar variables. But I see code in the XML modules that check
> >defined (@array)
>
> Then they should be fixed. That doesn't do anything useful right now.
I tried to fix it according t
Tom Christiansen wrote:
> >> I'm not happy with your use of "coerce". There's no mutation. It simply
> >> *is* those things.
>
> >Fine. So, in particular, it _isn't_ null.
>
> Of course it's null. That's why it has length zero. Stop speaking
> SQL at me. I'm speaking Perl.
No, in that wond
Russ Allbery wrote:
> Why on earth would you want to do this in real code?
I wouldn't, of course. This is just a demonstration that I want both
semantics available concurrently.
> I don't believe you actually need both semantics active at the same time;
I do. Need might be a slightly stronge
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
> 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
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
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.
>
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.
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
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
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
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
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
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
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
"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
"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
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
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'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
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
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
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
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
&
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
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
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.
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.
&
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:
> 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
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
Nathan Torkington wrote:
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that ma
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
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) <<<
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
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
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.
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
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...
1 - 100 of 166 matches
Mail list logo
