Re: Status Summary; next steps
On Thu, 2002-11-28 at 14:59, Michael Lazzaro wrote: > But my worries are that we could not keep P6L sufficiently focused, > resulting in an even *bigger* tangle of threads; that we can't really > *have* the discussions without posting the proposed documentation too; > and that P6L would not respond to the more dedicated authors' proddings > for NO REALLY, DECIDE THIS NOW OR WE CAN'T MOVE ON. The level of detail > needed is quite tedious, I'm not sure how many people on P6L would be OK > with having the list be used for that level of fussiness. (?) > > So I, for one, am open to suggestions. We clearly shouldn't have the > same language discussions in two places, but at the same time we clearly > must have better-organized discussions than we've historically been > doing on p6l, in order for them to be of any use to the doc authors. > I think p6l will continue to be the shaking-out ground for new ideas, hashing out the A&E docs, and in general trying to present big picture issues to Larry et al. Yes, it doesn't get detailed. Yes, it doesn't stay focused. The ramifications and scope that they're working in often affects other parts of the language, with the resultant changes. (I had started documenting things early on, and the changes were going faster than I could make updates.) Besides, the devil's in the details, and who likes dancing with the devil? And that's where I think p6d steps in. The big and middle pictures have been painted, the directions has been set. If there's a question of direction, or a change of direction, throw it back. I'm not saying don't make decisions, I'm saying people shouldn't be surprised with what comes out of it. The design team shouldn't need to oversee day-to-day, just tweak the docs you produce. The summaries shouldn't need to report on the weekly discussions, just report on what you've released. Much like the old sub-lists would step away to discuss some particular topic head-to-toe, p6d should discuss every topic toe-to-toe. It'll evolve, but until then, there'll be the occasional nudge. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Status Summary; next steps
On Tue, 2002-11-26 at 13:36, Michael Lazzaro wrote: > The main difference is that p6-docs is intended to move very narrowly > from topic to topic, in a roughly predetermined order, focusing on each But not to move faster than the design of the language. > one until the more dedicated members start to bleed from the ears > and/or we're convinced we have *all* the answers we need from the > design team to completely describe the required Perl6 behavior. (Right Correct. To describe the required Perl6 behavior. Yes, that means you need to ask questions. Sometimes those questions may involve some hand-waving. Just please, *please* refrain from rampant p6l-ish speculation. > now, we're discussing primitive scalar types and values.) Then we > write the answers down, get it approved, and move on to the next > narrowly scoped topic. The discussion is moderated, and sometimes > tedious, if you're not interested in what's currently being discussed. No, I *am* interested in what's being discussed - the committing to stone (hopefully granite, but understandable if it's sandstone) of what's going to happen. What I'm not interested are the big brainstorming sessions - I simply don't have the time for them any more. (Nor will I in the foreseeable future. I can't even get back to the internals. )-: > > p6-lang is more of a free-for-all, where you can ask/propose stuff > regardless of what the current topic is. The discussion is more broad, > and distinctly _not_ structured. It's not a question of structure. I attend many meetings that are a highly structured waste of my time. :-) > > Neither p6l nor p6d have any inherent decision making capabilities; > those have been abrogated (willingly) to the design team. I certainly > expect the docs contributors to propose new ideas when/where > appropriate, just like p6l does. That's one of the reasons for going And that's where I take issue. If it's "just like p6l does", then do it on p6l. We ran into a similar scenario early on with the various p6-* lists, and more recently (and constantly) on p6i when broaching the subjects of Perl 6 versus Parrot. As you said, if the most active people are on both lists, then it shouldn't be a problem. The lists aren't supposed to be defined by their contributors, only by their contributions. > through things in excruciating detail, so we can find any potential > gotchas or places in which broader generalization may help. > > I would recommend posting to p6-documentation if you have an > issue/proposal with something the documentation project is currently > discussing, and p6-language if you have other random thoughts/questions > that p6d haven't gotten to yet. It's pretty much the same people, > after all. :-) Then why have two lists? Dammit, I need to quit asking rhetorical questions. Be kind to Piers. Be kind to the readers. Don't have separate but equal discussions in two different lists. Weed out the cruft, fill in the gaps. Interpolate, don't extrapolate. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
RE: Status Summary; next steps [x-bayes][x-adr]
On Tue, 2002-11-26 at 09:17, Garrett Goebel wrote: > > p6d exists to document the language. A task which consists of going over the > A&E's and Larry's posts to p6l, etc. and flushing them out into > deliverables: > > o Perl6/Parrot regression tests > o Language Specification derived from tests > o Core Perl Documentation / User Manual > > Flushing them out consists of: > o disambiguation > o isolating potential problems > o writing tests and documentation > > I have difficulty separating the pd6 disambiguation discussions from > language design... as I expect do others. Language design discussion belongs > on p6l. And I for one, would like to see a big red flag delimiting It certainly isn't black and white, and that's understandable. It's a paint-by-numbers project, only no one's really put the numbers in yet. There may be a general consensus that this should be green and that should be blue, and it's p6d's job to work out what shade, or why that can't be the case. Other sections may be arbitrarily colored, and those are a little more fuzzy, but p6d can usually test and document that, too. p6d shouldn't be drawing the picture, though. Let Larry look at the p6l and draw the elephant. You guys just make sure it doesn't turn out white. > speculation, when it occurs on p6d. Though there's the p6d argument that a > limited amount of speculation is called for, in that we should use the p6d > cabal to work our language design issues into a coherent refined proposal > before dumping them into the fray that is p6l. > > > > , and how does it differ from p6l? > > p6d differs from p6l, in that p6d has a specific goal: "document the > language". Whereas p6l is a rather more ambiguous forum for people to > influence Larry's design and explain it one another. > > That said, it is also hoped that p6d will also have a beneficial effect on > p6l. Where p6l undergoes an iterative wave of questions and proposals > re-examining issues covered in previous A&E's following each new release, > p6d hopes to annotate its documentation to include the various trade-offs > involving alternative syntax, semantics, implementation impacts, ideological > ax grinding, etc. so that p6l can refer people to the old arguments instead > of wasting ever more time on them. Yeah, I wanted the same thing with PDD 0. :-) Hopefully this will turn out better. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Status Summary; next steps
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote: > (2) The behavior of an explicit bool type, _if_ one exists, that stores > "truth", not "value". Such that C stores > true, not 0, and does so in "the most efficient way". If you don't already know whether it exists, or how it will roughly work (lexically), you shouldn't be discussing it on p6d. Kicked back to p6l. The efficiency of storage isn't of your concern. Tackle the linguistical questions first: Should an explicit bool type be part of the language? If so, how should it work? C storing only a truth property but no value makes little sense in the context of the larger language. So does handling truth as something other than a property. > (3) Context. How to determine it, how to force it. Hypothesis: There > is a one-to-one relationship between Type and Context, such that there > is a context that matches every type, and a type that matches every > context (except void). Again... > > (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. > Generic typecasting rules: how to define user classes that can typecast > to/from str, int, bool, etc. This gets into Perl6 OO, but we may need > to request some preliminary decisions before then, because the > implications are substantial. and again... > > Let's open these for discussion. Questions/proposals/issues, anyone? and again... what's the scope of p6d, and how does it differ from p6l? -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: labeled if blocks
On Mon, 2002-10-28 at 14:41, Larry Wall wrote: > And maybe: > > A bitwise operator is just a logic operator scoped to a set of bits. Hypo-operators. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
RE: atomicness and \n
On Tue, 2002-09-03 at 23:57, Luke Palmer wrote: > On Tue, 3 Sep 2002, Brent Dax wrote: > > > > How can you be sure that is implemented as a character > > class, as opposed to (say) an alternation? > > What's the difference? :) > > Neglecting internals, semantically what I the difference? > One *possible* semantic difference is a guaranteed matching order. Nothing (historically) has ever really dictated that character classes must match left-to-right, as alternation does. That's mainly because character classes have always been of a uniform width, in which case it is only going to match one thing and one thing only. Whether that will be an issue with variable-width characters in a class is largely going to rely on the semantics that are dictated. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Exegesis 4
On Wednesday 03 April 2002 18:24, Larry Wall wrote:
>
> Sure, just say
>
> { loop (my $i = intializer(); condition($i); $i = advance($i)) { ... }
}
>
> : Perhaps something like:
> :
> : initalizer() -> $i { LOOP: NEXT { $i = advance($i); redo LOOP if
> : condition($i);} ... }
> :
> : except I'm not sure that that would have the same semantics.
>
> Other than that C isn't going to be expecting a closure,
> and C would bypass the NEXT, and there's no loop there to
> C, and you'd have to make the parameter C<$i is rw>, why, it
> should work find. :-)
>
> : (Or, more generally, given a for loop with a "my", how sould perl52perl6
> : deal with it?
>
> Probably just by slapping an extra set of curlies around it.
Umm. didn't you say bare blocks were going away?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Perl6/Parrot status
On Thursday 07 February 2002 09:13, Ask Bjoern Hansen wrote: > Hi, > > I am tired of people thinking that we are not getting anywhere at > all, so if (some|any|every)one can send me a reasonably updated text > for the "Where are we" section at http://www.parrotcode.org/ and > likewise for http://dev.perl.org/perl6/status then I would most > appreciate it. :-) If there aren't any objections, I'll add this as a TODO along with the weekly summary. [ Which I haven't done for last week yet. :-( ] -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Re: Perl6 -- what is in a name?
On Monday 28 January 2002 21:54, [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > > The third group that won't be happy with Perl 6 are those who program > > in a limited subset of Perl - so limited, in fact, that they will > > most likely be bitten by minor changes in the language, without the > > benefit of experiencing the major improvements that those changes > > allowed. These people are, by and large, not professional > > programmers, but folks for whom Perl is a simple and powerful tool in > > their jobs, and it will drive them crazy when their toolkits and > > recipes stop working. I should know, I support multitudes of these > > people. > > Just out of curiosity, what percentage of Perl users would you say fall > into this category? I wouldn't. :-) If there's one thing that I have learned in my "travels" throughout the technical world, it's that Perl can and does show up in the strangest of places. And for every use that I've seen, there are probably a hundred more. Another thing that is difficult in classifying the third group is the delineation between Perl and the problem domain. If you use all of the core Perl features strictly to do web page generation, are you using a small or large subset of Perl? From a practical perspective, very little of a computer language is the language itself. I would, however, be so bold to say that these mailing lists are a poor representation of the Perl community at large, and of the group in question specifically. But even if they are a silent majority, do we need to cater to their unspoken requirements? That, ultimately, is *the* question. And the answer already lies within the Perl philosophy of making the hard things easy without making the easy things hard. Most of the minor changes that will affect the casual camel jockey are a change from the simple to the simple. They'll make the occasional mistake. And they'll get frustrated. But the changes won't be difficult to learn. In the meantime, many folks who have struggled to do wondrously difficult things in Perl will now do even more wondrously difficult things - and, what is more, those wondrously difficult things will make what was previously unaccessable available.Or so the theory goes. Of course, then there's Damian, who will reach the point of doing everything that's impossible simultaneously... and in constant time. > > And should follow-ups to this go, perhaps, to [EMAIL PROTECTED]? If we were to discuss *why* it's good for non-professional folks, probably. I'll let someone else cross-post if they feel it's necessary. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Perl6 -- what is in a name?
> Perl6 isn't going to make everyone happy. That's right, it isn't. Nor should it strive to. First off, there are the folks who've no clue what Perl even is. Perl 6 won't make them happy. On the other hand, they won't really be disappointed with it, either. But that's a rather silly demographic to use as an illustration. The second group are those that weren't happy with Perl 5. Or Perl 4. Or Perl 3. Perl 6 isn't going to win them over. Sorry. (This may also seem like a silly demographic, but in truth, it's not. People who don't like Perl 5 won't like Perl 6, which kind of demonstrates how similar the two really are.) The third group that won't be happy with Perl 6 are those who program in a limited subset of Perl - so limited, in fact, that they will most likely be bitten by minor changes in the language, without the benefit of experiencing the major improvements that those changes allowed. These people are, by and large, not professional programmers, but folks for whom Perl is a simple and powerful tool in their jobs, and it will drive them crazy when their toolkits and recipes stop working. I should know, I support multitudes of these people. The fourth group will, we should hope, be happy with Perl 6. These are the folks who do program in Perl, and are constantly fighting against limitations, either real or perceived. Some may be happier than others, of course. It all depends on what you consider to be important to you. I do very little structured OO programming, for instance, so a lot of the improvements in that area I will undoubtedly be oblivious to. But as long as I can continue slinging my one- to ten-liners, I'll be content. The final group, those that have yet to discover Perl, are a toss-up. Many of them will hate Perl 6, no matter what name it was called by. But others... they will learn and love Perl 6 the way some of learned and loved Perl 5... or Perl 4... or even Perl 1. So, what *is* in a name? If a rose by any other name would smell just as sweet, why continue to call it a rose? Because identifiers are a proxy for what they represent - an evocation of the object without benefit of having one. Calling them roses allows you to share the sight and smell (and touch!) of the flower, along with the emotions that are inevitably coupled with it. Calling Perl 6 Perl allows those who dislike the thorns to beware, and those that appreciate the beauty to properly care for it. The only people who will probably care - not just comment on it, but truly care - about the name are the people in the third group. But for them, it's usually necessary only to stress the version number as a part of the name. For these people, it isn't just Perl - it's Perl 5. Which Perl 6 is not. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: 123_456
On Friday 25 January 2002 12:34, Simon Cozens wrote: > Should we be allowed to use _ to group numbers, now that _ is concat? > If not _, then what? (if anything?) Sure, why not? '_' is still a valid character in an identifier. You'd still simply need disambiguating whitespace for concatenation. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc4: Parentheses
On Monday 21 January 2002 11:27, Larry Wall wrote:
> Compound statements in Perl 5 do have an implicit {} around the entire
> statement, but that has nothing to do with the required parentheses
> around the expressions, other than the fact that we're doing away with
> both of those special rules in Perl 6. But parentheses have always
> been totally transparent to any C contained within them. It's
> the implicit {} that was protecting the C condition from getting
> a warning like the C got (which got the warning because it's
> at the same scope level as C's declaration).
But the flies are spontaneously generating! ;-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Monday 21 January 2002 11:14, Larry Wall wrote: > So I'm not terribly interested in going out of my way to make statement > blocks parse exactly like terms in an ordinary expressions. If it > happens, it'll probably be by accident. That's fine. (And I agree.) All I really cared about was map, grep, and sort. The rest was was simply an extension to the implausable end. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc4: Parentheses
On Sunday 20 January 2002 21:00, Damian Conway wrote:
> Bryan C. Warnock asked:
> > Since the parentheses are no longer required, will the expressions
> > lose or retain their own scope level? (I'm assuming that whatever
> > rule applies, it will hold true if you do elect to use parantheses
> > anyway.)
>
> Err. Expressions don't have their own scope level, even in Perl 5.
They do in block conditional expressions. Try this:
#!/your/path/to/perl -w
my $x = 4;
if (my $x = 5) {
print "$x\n";
my $x = 6;
print "$x\n";
} elsif (my $x = 7) {
print "$x\n";
my $x = 6;
print "$x\n";
} else {
print "$x\n";
my $x = 6;
print "$x\n";
}
print "$x\n";
"my" variable $x masks earlier declaration in same scope at Perl/demo.pl
line 9. # the elsif masking the if
Found = in conditional, should be == at Perl/demo.pl line 9.
Found = in conditional, should be == at Perl/demo.pl line 5.
5
6
4
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Apoc4: "When do I put a semicolon after a curly?"
On Sunday 20 January 2002 21:43, Larry Wall wrote:
>
> I think it's too easy to have accidental non-void contexts, which is
> why I'm wanting to outlaw bare blocks at the statement level. But I
> don't think that fact influences your argument one way or the other.
> There's definitely some merit in what you say--I'm just not sure the
> distant context should outweigh the close context when the block could
> be arbitrarily long.
My concern is that we're simply replacing one set of questions ("why doesn't
this work the way I expect") with another set of questions ("why doesn't
this work the way I expect"). I'm sure that would hold true for any amount
of change, so I want to be prepared with the rationale and explanations.
Thanks for answering my queries.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Sunday 20 January 2002 20:57, Larry Wall wrote:
> I expect PRE and POST could inherit automatically according to the
> usual rules of DbC, though how you implement that is something other
> people have thought about more than me. I think that LAST doesn't
> inherit. If you want to share common code, there's this neat Perl 6
> invention called "subroutines" you can use.
Funny you should say that. The question I hadn't asked yet:
Since these blocks are all closures now, will the different methods for
passing code blocks be interchangeable (or simplified)?
User code code can pass '{ ... }' if a sub's prototype wants a coderef, to
better match map and grep; sort can take a bare block or the name of a sub,
but none of the three can take a reference to a sub. Whereas this mostly
makes (made) sense, can code truly start being interchangable? Can I write
reusable transformers and filters for map and grep, simply passing in a ref
to the proper routine rather than the code block? How would this interact
(or react) with curried code blocks?
If this is a good first step, how far can it extend? Could I write a sub,
and pass a reference to it directly to LAST, for instance:
LAST $coderef;
or would I simply wrap it?
LAST {
&$coderef;
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Sunday 20 January 2002 08:29, [EMAIL PROTECTED] wrote:
> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
>
> Close and close. As of two days ago, Larry's thinking was:
>
Note to self: Program flow
> BEGIN Executes at the beginning of compilation
> CHECK Executes at the end of compilation
> INITExecutes at the beginning of run
> END Executes at the end of run
Note to self: Block flow
> PRE Executes at block entry.
> Inherited if block is a method. No side-effects
>allowed.
> POSTExecutes at block exit.
> Inherited if block is a method. No side-effects
>allowed.
> NEXTExecutes on (explicit or implicit) call to next()
> within current block
> CATCH Executes on exception within current block
> LASTExecutes on any form of block exit.
> Not inherited (c.f. POST), even if block is a method.
> Side-effects allowed.
> KEEPSpecialized form of CATCH.
> Executes on "control" exception in the current block
> UNDOSpecialized form of CATCH.
> Executes on non-"control" exception in the current
>block
Is it POST, LAST or LAST, POST, at runtime?
How does one enforce the no side-effects rule, and how deeply does it
traverse?
Do I remember right that 'return' creates a control exception?
Do KEEP and UNDO take the place of CATCH within a block? (ie, you may either
CATCH, or you may KEEP and UNDO, but not both?) If all three are allowed,
what is the exception handling order?
Which blocks may you have more than one of within the same block, and in
what order will they execute?
In one cannot (or does not) inherit a PRE, POST, or LAST block, is there a
way to add one without recreating the entire block.
When you say inheritence (which implies a sub), not inheriting only applies
to the outer-most scope - the sub scope - currect? Any container blocks
should still have their full semantics preserved, so that an embedded while
block, for instance, would still have its corresponding LAST, I hope. If
that were the case, could you then get around the inheritence issue by
enclosing the entire body of the sub inside its own block? (I'm not saying
that that's a good idea, just asking whether it could be done.)
sub non_method {
loop {
PRE {
print "PRE\n"; # Is printing a side-effect?
...
}
POST {
print "POST\n";
...
}
LAST {
print "LAST\n";
...
}
code();
last;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Saturday 19 January 2002 22:05, Brent Dax wrote: > Is this list of special blocks complete and correct? > > BEGIN Executes at the beginning of compilation > CHECK Executes at the end of compilation > INITExecutes at the beginning of run > END Executes at the end of run > PRE Executes at beginning of block entry > POSTExecutes at end of block entry > NEXTExecutes on call to next() within current block > CATCH Executes on exception within current block > KEEPExecutes on normal exit of the current block > UNDOExecutes on "un-normal" exit of the current block That matches my list. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc 4?
On Saturday 19 January 2002 12:20, iain truskett wrote: > * Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]: > > On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: > > > http://www.perl.com/pub/a/2002/01/15/apo4.html > > [...] > > > I thought I had just missed it... but there's no trace of it in the > > archives of <[EMAIL PROTECTED]>. Or any other perl6 list. > > > > Don't tell me that is normal. > > It's a worry. Also odd is that Slashdot hasn't picked it up yet. Developers' section. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc4: "When do I put a semicolon after a curly?"
On Saturday 19 January 2002 12:24, Piers Cawley wrote:
> You're treating do, if, foreach as if they were keywords. I'm not
> entirely sure that that's still the case.
'do' perhaps. But not really. And it's irrelevant to my argument.
> And you're also forgetting
> the possibility of user implemented control type operators/methods.
No, I'm not. As a matter of fact, I had even wrote a section on
user-defined constructs, only to find that my arguments were exactly the
same, so I removed it as superfluous.
>
> Unless I'm very much mistaken you're suggesting that we special case
> the parser for 'do' and any user defined functions that take a block
> can go hang. Which I'm really not keen on.
Then you're very much mistaken. :-)
I'm saying that if you're going to DWIM an expression as a block, do it
based on the expression being used in the standard context of a block,
rather than the fact that the trailing '}' appears on a line by itself. In
other words, I'm very much for Larry's idea. Just put the burden on the
parser, rather than on the parser and the person.
That applies to *any* expressionish block - do, BEGIN, INIT, sub (sort of),
the old eval which is now gone, or a user-defined one. I simply picked on
do {} and BEGIN {} because they were the examples given in the Apocalypse.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: 'when' blocks versus statements
Why the double semantics of 'when'?
It implicitly breaks when used as a 'when' block, but does not as a 'when'
statement. It seems that a when should be a when should be a when, and a
when being a when would be a win.
The example given:
given $x {
warn("Odd value")when !/xxx/;
warn("No value"), break when undef;
when /aaa/ { break when 1; ... }
when /bbb/ { break when 2; ... }
when /ccc/ { break when 3; ... }
}
could be written as:
given $x {
warn("Odd value"), skip when !/xxx/;
warn("No value") when undef;
when /aaa/ { break when 1; ... }# No reason you can't
when /bbb/ { break when 2; ... }# explicitly break even when
when /ccc/ { break when 3; ... }# you'd implicitly
}
or even:
given $x {
warn("Odd value") if !/xxx/; # Since $_ is the localizer
warn("No value") when undef;
when /aaa/ { break if 1; ... }
when /bbb/ { break if 2; ... }
when /ccc/ { break if 3; ... }
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: The loop keyword
No examples are given, but are we to assume that this:
for ($x = 0; $x < 100; $x++) {
...
}
becomes this:
loop $x=0; $x < 100; $x++ {
...
}
How would you use an $x lexically scoped to the loop block?
Most of the other constructs seem to be using a '-> $x' construct.
loop my $x=0; $x < 100; $x++ {
...
}
?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: Parentheses
Interestingly, this one tweak to the whitespace rule also means that we'll
be able to simplify the parentheses out of other similar built-in constructs:
if $foo { ... }
elsif $bar { ... }
else { ... }
while $more { ... }
for 1..10 { ... }
I think throwing out two required punctuation characters for one required
whitespace is an excellent trade in terms of readability, particularly when
it already matches common practice. (You can still put in the parens if you
want them, of course, just for old times' sake.)
Since the parentheses are no longer required, will the expressions lose or
retain their own scope level? (I'm assuming that whatever rule applies, it
will hold true if you do elect to use parantheses anyway.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Apoc4: "When do I put a semicolon after a curly?"
The two current examples of an evil expression block are do {} and eval {},
which require a semicolon terminator. However, with eval {} leaving, that
leaves just do {}, which does (or should) fall more in line of thinking of
grep {}, map {}, and sort {}: the other expression blocks. For do {}, the
block just happens to be the only (and therefore, trailing) argument. (In
other words, from an language perspective, do {} really should be presented
more as 'do' and less as '{}'. Much of the block confusion came from the
specialization of do-while and do-until. But both of these are illegal in
Perl 6, so there's no longer a reason to propagate that misconception.)
With try {} appearing to be a proper block, that would leave do {} the only
beneficiary of the Lone Bracket hack. (For now. I continue this below.)
So, in essence, you are trading "you need to remember that do {} is just an
expression, treat is as such" to "do {} is an expression. You can write it
as a block (as long as the close bracket is on a line by itself), and we'll
tack on the semicolon for you, but don't write it as a block when you want
an expression, unless you put the rest of the expression on the same line as
the bracket." Although each individual rule is simple, the overall
semantics have become quite complex for such a small subsection of the
language. And attempting to leverage that against a lone bracket, I feel is
a mistake. From a linguistical perspective, that seems to be more
presentationally based, rather than contextual.
Most everything in Perl is done in context, so why not leverage that
instead? After all, the semi-colon will be needed to terminate an anonymous
hash assignment, yes?
my $ahash = {
foo => bar
};
It seems to me that when people use a block as a code block, they simply
don't make it do expressionish things. Like capture the return
value. Blocks are almost always - there are always Damians in the world -
used in a void context.
my $a = do {
}
No, it's not a block, it's an expression. It shouldn't even be presented as
a potential block. You've a do {} in the midst of a long string of things,
it shouldn't terminate simply because I'm formatting for clarity.
do {
...
}
could be a block. Particularly now that base blocks are forbidden, this
will be a block. The question is whether the expression continues
afterwords:
+ 1 for @x;
The parser should be able to determine whether the expression continues
on the next line. You either get an operator or a statement modifier, or
the block is terminated. But for the user who has to remember all the rules,
there's nothing to do. He just writes it. Contextual. Not presentational.
The Apo surmises that some other blocks may become expression blocks,
such as BEGIN {}. I assume CHECK {} and INIT {}, as well? END {} doesn't
make sense. How about any of the new blocks?
Now, you've added even more special cases to the semi-colon rule.:
BEGIN { foo() };
END { foo() }
Some will take them - sometimes - and others won't, at all. Sure, you could
always put a semicolon there, and create a null statement, but you don't do
that now, so why should you start?
Once again, I think the void contextual clues should be differentiating
between block and expression usage. Perl already exprects you to understand
differing behavior in void, scalar, and list context, and Perl 6 is expected
to add more. Why not continue in that direction here, instead of veering
off in some strange direction.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Perl 6's Exporter
On Saturday 22 December 2001 05:40 am, Brent Dax wrote: > BTW, can we genericize 'use' to work like an indirect-object method? > > use Data::Dumper; > Data::Dumper.use; #same thing Only if you can gel the compile-time semantics of compile-and-run. > # Well, I can't get it to run :-) > > Darn, I was hoping you had brought a Perl 6 binary back from the > future... :^) Still, can you give it a once-over and tell me if you > notice anything? If I had done that, I'd be submitting a hell of a lot more code than I have been. ;-) A quick glance through with tired eyes looked good, but I'll do a more thorough paper trace when a little more coherent. (At least I was able to mostly understand what you were doing.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Perl 6's Exporter
On Saturday 22 December 2001 02:29 am, Brent Dax wrote:
> I've been thinking about improvements that could be made to Exporter for
> Perl 6.
>
> 1. Choosing where to export to:
> use Data::Dumper 'Dumper' => 'dumpvar';
> #exports Data::Dumper::Dumper to Main::dumpvar (or whatever)
Where to import to. It's probably not a good idea to export into someone
else's namespace. (Pull vs Push).
> 2. Built-in switch handling:
> use Data::Dumper ('Dumper' : qw(+Indent=2 +Useqq));
> #imports Dumper, sets $Data::Dumper::Indent=2, and
> # does $Data::Dumper::Useqq is true
Is it more or less confusing (overall) to be mixing importation with simple,
non-imported data initialization, as opposed to having it all be imported
(with optional data initialization)?
> 3. Warnings about conflicts:
> use warnings 'Exporter';
> sub Dumper { ... }
> use Data::Dumper qw(Dumper);
> #prints out a warning (not just 'redefined subroutine', either).
> 4. For modules, saying 'use Exporter' should be enough to get import.
> If you don't want Exporter's import(), just C.
> 5. In addition to @EXPORT/@EXPORT_OK/%EXPORT_TAGS, provide a way to do
> it on the 'use Exporter' line.
>
> So, with those requirements and what knowledge of Perl 6 I have, I
> present a preliminary Exporter. I typed it directly into the mailer, so
> there's a good chance of mistakes. If anyone spots any mistakes in it,
> let me know.
Well, I can't get it to run :-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Hyper-operators and Underscore
On Saturday 06 October 2001 03:47 pm, Erik Lechak wrote:
> Thank you for the info. I am more engineer than computer scientist,
> so please excuse the ignorance behind these questions.
No problem.
>
> > Except that the operator truly is simply an underscore. But it's also a
> > valid identifier character, so where it may be confused with that, you
> > are simply required to make it less ambiguous to the parser.
> >
> > $a _= $b _ $c; # $a _= $b _$c;
> > ${a}_=${b}_$c;
> > %h{$s}_="Hello, "_"world!\n";
> >
> > As Larry said, no different that the other operators that also consist
> > of valid character identifiers.
>
> I understand that the operator is just the underscore. However, in the
> third edition of the camel book on page 49, the second paragraph, it
> states that "An identifier is a token that starts with a letter or
> underscore and contains only letters, digits, and underscores." Since
> there are no singel letter operators, no single digit operators, but now
> we see the advent of the underscore operator, it follows that the
> underscore will be the only operator that could be confused as part of the
> variable name.
'x' is a single letter operator.
>
> 1) My question is what other operator could be confused with an
> identifier?
Not including the list operators or control flow keywords:
eq, ne, gt, lt, ge, le, cmp, x, and, or, not, xor
$a = $bx4; # $a = "$b"x4; $a = $b x 4;
if ($one foo || $o nefoo) # if ("$o"ne foo); if ($o ne foo) ; if (${o}ne&foo)
etc...
>
> 2) Where did Larry say "no different that the other operators that also
> consist of valid character identifiers." ?
Hmm. It looks like he didn't. That must have been a point someone had made
in a subsequent posting. I apologize.
>
> > IIRC, '^' was considered earlier. (And it's shifted, BTW.)
>
> 3) What do you mean by shifted?
A caret on a standard US qwerty keyboard is "shift-6'. (In reponse to your
complaint (a), about the underscore requiring the shift key.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Hyper-operators and Underscore
blems as '+', in both its binary and unary form. Plus it's a range operator within a character class. > > Then I thought of it. In school whenever I separated a single word > into two words my paper would come back with a small red arch joining > the two words together into one. Of course that symbol was usually > followed by a -5 or something like that. So I scanned the keyboard for > something that looked like that small arch. Then I found it. The "^" > symbol. Since I have a problem with the hyper operator idea, Maybe it > could be used here. But what about xor. I can honestly say I have > never used "^" to mean xor. The Huffman coded concept should make the > use of xor rather than "^" a viable alternative. I read through > Apocolypse3 and saw this justification: IIRC, '^' was considered earlier. (And it's shifted, BTW.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: A3, the ';' operator, and hyper-operators
On Thursday 04 October 2001 12:18 am, Damian Conway wrote: >> ** Binary // >> >> Was a test for definedness *and* truthfulness considered? > > Err... the || operator *is* a test for that. Hmmph. So it is. All those wasted keystrokes that I'll never recover... how depressing. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: A3, the ';' operator, and hyper-operators
** Discussion for RFC 320:
What about filetests that already return something meaningful? I'll assume
that they still behave the same. (And thus, shouldn't be chained. Unless
you're doing something weird.)
It's also mentioned that they don't short-circuit, so what do post-failure
tests test against? (I'll assume 'undef', which a test will also return
'undef' against.)
** Miscellaneous
Why 'operator:+' instead of 'operator::+'? (Other than the potential
verbosity required to declare operators within a particular package.)
I would think it more intuitive to think of 'operator' as a provided package
(within every package).
Hmm, lexicals.
** Unary _
Space or no space?
sub _mysub {}
$a = _mysub;
Which behavior is changing?
** Binary //
Was a test for definedness *and* truthfulness considered? Personally, I
test for both, particularly within the context of defaulting. Of course,
you could still write:
$a = ($a // $b) || $b;
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Custom iterators
On Monday 24 September 2001 09:58 pm, Michael G Schwern wrote: > yield() [2] simply says "run the block associated with this method > once". Similar to the $block->() call, but since it's not a full > subroutine call, just a block enter/exit (like a normal iteration > through a loop) there's two important differences. A particular case of, or independent from, co-routines' yield()? > In fact, I'd go so far as to say junk the current meaning of the & > prototype, which has never really lived up to it's promises, ... Bingo. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Saturday 08 September 2001 04:14 pm, Brian Wheeler wrote: > While not math, per se, there are bitops (and, or, not, xor, eqv) and > shifts (though they can be simulated by "mul tx,ty,(2^bits)" and "div > tx,ty,(2^bits)") There will be bitops. > > I doubt rolls would be useful :) Vuja de. > > Are there going to be string ops as well, or would add and mul work on > string registers? Yes. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Saturday 08 September 2001 12:00 pm, Dan Sugalski wrote: > Okay, I'm whipping together the "fancy math" section of the interpreter > assembly language. I've got: > > sin, cos, tan : Plain ones > asin, acos, atan : arc-whatevers > shinh, cosh, tanh : Hyperbolic whatevers > log2, log10, log : Base 2, base 10, and explicit base logarithms > pow : Raise x to the y power > > Can anyone think of things I've forgotten? It's been a while since I've > done numeric work. > 1/x is often handy, although maybe not enough to justify its own opcode. (It is often used in other calculations, however, so perhaps one opcode would be better than 3.) sqrt has traditionally been provided in languages, although it (and all other roots) could simply be an power (inverse x). atan2 is also often traditionally provided in a language, since it identifies the proper quadrant. Others would include abs, floor, ceil, round, mod - don't know if those are basic or "fancy" to you. I suspect you may have those already The question arises what do you do as its opcode, and what languages features can be a series of opcodes. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Friday 07 September 2001 03:22 pm, raptor wrote:
> will the iterator variable be available in map, grep, join...etc...
Iterators haven't been defined yet, so it's hard to tell.
For map and grep, it's certainly feasible, depending on their implementation
- although neither are truly iterators.
For join, I don't see where you would access it.
>
> I was also wondering if the join syntax be extended in a way that it can
> support preffix and suffix... what i have in mind ... not necesary but :
> #pair
> join ($prefix => $suffix), @ary;
>
> so :
> my $select = join (qq{} => ''), @ary;
That's not really joining.
>
> or is better to stay like this :
> my $select;
> map { $select .= qq{$_} } @ary;
Definitely.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Friday 07 September 2001 12:56 am, Ken Fox wrote: > "Bryan C. Warnock" wrote: > > Generically speaking, modules aren't going to be running amok and making > > a mess of your current lexical scope - they'll be introducing, possibily > > repointing, and then possibly deleting specific symbols > > How much do you want to pay for this feature? 10% slower code? 50% > slower? Do you want the feature at any price? Which feature? The introduction of new lexicals solely at compile time? We can do that now. I've already demonstrated that this is a solvable problem. Although, admittedly, I wouldn't suggest actually *implementing* my solution, I'm sure someone far more clever than I can come up with a viable one. > > I don't like run-time frobbing of the symbol table. Not even > precise tweaking. ;) I think it's in bad style and inconsistent with > the purpose of lexicals. *But* bad style isn't a good argument > and I wouldn't be pursuing this if it were just a style issue. But it clears up a *lot* of problems that were introduced with local. Much like perlfunc says... You really probably want to be using "my" instead, because "local" isn't what most people think of as "local". See the Private Variables via my() entry in the perlsub manpage for details. Lexicals were never about speed, they were about containership. A lot of Perl's magic and power, however, only work when centered around globals and locals. Muckings there, however, cause true "action at a distance" - what I change here for my benefit may screw something up way over there that I can't see. Allowing this to take place with lexicals reduces those risk factors - do your magic here and only here. > > The trouble lies in running the code. Lexicals used to be known at > compile time. Now they can change practically anywhere. It's like > using C and having *everything* be volatile. Except worse because > you don't even know the address where something is going to be. Lexicals being known at compile-time was a side-effect of the containership. Yes, we want lexicals to be fast. Containing behavior lexically is slightly more important, IMO. If it runs dog-slow, we won't do it. If it runs just a tad slower, we probably should. > > A simple solution would be to allow lexical scope editing at > compile time, but not run-time. Change a BEGIN block's caller() so > that it is the scope being compiled instead of main. This achieves > the majority of the benefits (lexical imports at compile time) > without any downside. Nope. Think 'require'. > > There are two other things that are easy to add. If the > compiler knew in advance which lexicals might dynamically change, > it could generate better code and not slow everything down. A > trait called ":volatile" or something. IMHO this would also > show intent to the people reading the code that something funny > might happen to the variable. (Macros or compile-time injected > lexicals could declare the :volatile trait, so I would imagine > that some pretty interesting packages could still be written.) Except that magic will probably be going on behind the scenes, so you don't know it's magically. Otherwise, you'd just assign whatever it was to the lexical variable and be done with it -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
On Friday 07 September 2001 12:13 am, Ken Fox wrote:
> Damian Conway wrote:
> > Bzzzt! The line:
> >
> > %MY::{'$x'} = \$z;
> >
> > assigns a reference to $z to the *symbol table entry* for $x, not to $x
> > itself.
>
> So I should have said:
>
> %MY::{'$x'} = $z;
>
> That's pretty magical stuff isn't it? Sorry I used the wrong syntax.
> I'm just taking it from your "Perl 6 Overview" PDF slides. This stuff
> changes *fast*, eh?
No, he was buzzing me. I was still thinking in terms of pads, and missed
the extra pointer. You were correct... Forget what you just
unremembered
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 07:44 pm, Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x
> itself.
So you're saying that the symbol table entry contains a reference to the
variable it represents? Okay, I'll buy that for now.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 06:01 pm, Garrett Goebel wrote:
> From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > I think we have a language question... What should the following
> > print?
> >
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x, $$y, $z\n"
> >
> > a. "2, 1, 3"
> > b. "2, 2, 3"
> > c. "3, 1, 3"
> > d. "3, 3, 3"
> > e. exception: not enough Gnomes
> >
> > I think I would expect behavior (c), but it's not obvious to me.
>
> I would have said (c) as well.
>
> And if I can figure it out... it ain't that tricky.
%MY:: ain't no different than %main::, except its contents are heaviliy
restricted to the current scope level. Whatever you used to be able to do
with globals, you'll now be able to do with lexicals. You just lose the
globalness of it.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 05:52 pm, Ken Fox wrote:
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e. exception: not enough Gnomes
>
> I think I would expect behavior (c), but it's not obvious to me.
SCALAR(addr),SCALAR(addr), 3
$$x,$$$y,$z = "3,3,3"
My $x container contains 1. ($x = 1)
My $y container contains a ref to the $x container. ($x = 1, $y = \$x)
My $z container contain 2. ($x = 1, $y = \$x, $z = 2)
My $x container now contains a ref to the $z container.
($x = \$z, $y = \$x, $z = 2)
My $z container now contains 3.
($x = \$z, $y = \$x, $z = 3, or $$x = 3, $$y = \$z, $z = 3, or
$$x = 3, $$$y = 3, $z = 3)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> But surely %MY:: allows you to access/manipulate variables that are in
> scope, not just variables are defined in the current scope, ie
>
> my $x = 100;
> {
> print $MY::{'$x'};
> }
>
> I would expect that to print 100, not 'undef'. Are your expectations
> different?
Yes. I would expect that to print 'undef'. '$x' doesn't exist as a key in
%MY::
>
> I think any further discussion hinges on that.
Yes. My expectations are different. My expectations are exactly like my
previous PATH example.
my $x = 100;
{
$MY::{'$x'} = 200; # Equivalent to 'my $x = 200'
print $x;
}
print $x;
That should print 200, and 100, should it not?
You are creating a lexical in the current scope, and assigning it the value
of 200. You are not finding a currently existing $x and assigning it the
value of 200, resulting in 200 / 200.
But let's be a little more pragmatic about it, shall we? Look beyond the
fire and brimstone for a moment. As Dan said, we can already screw up your
entire world. So other than a couple clever hacks from Damian, how will
they be used?
Generically speaking, modules aren't going to be running amok and making a
mess of your current lexical scope - they'll be introducing, possibily
repointing, and then possibly deleting specific symbols out of that scope's
symbol table. Very precise actions - not random reassignment of values from
hither and yon. Furthermore, unlike the value determination of a variable,
which meanders through the various scopes looking for the most applicable
target, %MY:: table manipulation is a singular entity, and needs to be
treated as such. You certainly don't want to be targetting random scopes
'n' levels up. You know exactly which level you need control over - 99% of
the time, the immediate parent - and that is where any change should be
limited too.
Believe it or not, this feature is designed to reduce action at a distance -
why would we want to create even more?
my $x = 100;
{
use some_pragma; # Introduces some $x
foo($x);
bar($x);
}
# The original pragma's scope has ended... why should we be using the
# same $x? We shouldn't. The $x was created in the inner scope, and
# we're back to ours
%MY:: access the pad, not the variable.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
%MY:: manipulates my lexical pad. If, to resolve a variable, I have to
search backwards through multiple pads (that's a metaphysical search, so as
to not dictate a physical search as the only behavior), that's a different
beastie.
Consider it like, oh, PATH and executables:
`perl` will search PATH and execute the first perl found, but 'rm perl' will
not. It would only remove a perl in my current scope..., er, directory.
On Thursday 06 September 2001 08:28 am, Dave Mitchell wrote:
> > > my $x = 100;
> > > {
> > > my $x = (%MY::{'$x'} = \200, $x+1);
> > > print "inner=$x, ";
> > > }
> > > print "outer=$x";
> > >
> > > I'm guessing this prints inner=201, outer=200
Oops, I may have been wrong. This might give you {some random number}, 100,
depending on how the reference is handled.
What you are, in essence, doing, is creating a lexical $x in my current
scope, and setting that to be a reference to 200. You're then taking that
newly created lexical $x, adding 1 to it (which currently is adding one to
the address of the constant, but whatever), and that is being stored in,
effectively, itself.
> >
>
> I was just trying to confirm whether similar semantics apply to the use of
> %MY:: - ie when used where a lexical has been defined but not yet
> introduced, does %MY{'$x'} pick up the inner or outer lex?
>
> I especially wanted to confirm whether delete %MY{'$x'} will delete the
> outer $x because the inner one isn't yet quite in scope.
The delete should be no-oppish, as the lexical variable doesn't exists yet
in the current lexical scope. If you want to mess with your parent's scope,
you have to mess with it directly, not indirectly.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> One further worry of mine concerns the action of %MY:: on unintroduced
> variables (especially the action of delete).
>
> my $x = 100;
> {
> my $x = (%MY::{'$x'} = \200, $x+1);
> print "inner=$x, ";
> }
> print "outer=$x";
>
> I'm guessing this prints inner=201, outer=200
Perhaps I missed something, but %MY:: refers to my lexical scope, and not my
parents, correct?
Why isn't this inner=201, outer=100?
>
> As for
>
> my $x = 50;
> {
> my $x = 100;
> {
> my $x = (delete %MY::{'$x'}, $x+1);
> print "inner=$x, ";
> }
> print "middle=$x, ";
> }
> print "outer=$x";
>
> If delete 'reexposes' an outer version of that variable, then I'd
> speculate the output would be
>
> inner=51, middle=50, outer=50
Again, I though that %MY:: referred to my current scope, in which case the
delete doesn't do anything. That would make it 101, 100, 50.
Is my understanding incorrect?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Thursday 06 September 2001 07:15 am, David L. Nicol wrote:
> in file Localmodules.pm:
>
> use Pollutte::Locally;
> use Carp;
>
> and in blarf.pl:
>
> sub Carp {print "outer carp\n"};
sub frok { Carp(); }
>
> {
> use Localmodules.pm;
> local *{$_} foreach @PolluteList;
> Pollute();
> Carp("Inner Carp"); # goes to STDERR
frok();# We want this to print "outer carp"
>
> }
>
> Carp(); #prints "outer carp\n"
>
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
It's still largely incomplete, and getting a little weighty, so v.2 is up
on my web page:
http://members.home.net/bcwarno/Perl6/ref/statements.txt
I'm sure I didn't cover all the corrections from the first go round, so if I
missed anything, gently poke me in the side.
What's been added?
BEGIN|CHECK|END|INIT blocks
eval { block }
{ block } style code-refs
try / catch blocks
more definitions
scope diagrams
some detailed descriptions
a stub for continuations
What's been changed?
split the grep and map block entries
added a continue block to the iterating 'for' block construct
the definitions, many times :-)
What's left to do?
A lot. I apologize for it being so slow-going. The three big things
are to finish the detailed descriptions, do the comparisons and contrasts
(which will hopefully explain why "this" ne "that"), and then make any
recommendations. I still want to attribute most of the statements in the
document - or at least flag which ones have been set in stone.
I'm sure that many of my explanations may jar the more veteran of you, who
can more likely recite the pod and Camel explanations verbatim. Some of my
differentiations may seem pedantic. Thank you for your continuing patience
- if my madness were an object, there'd be a method to it.
As always, constructive criticism is welcome.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Labels
Hmm is this such a good thing?
my $a = 0;
GORK: while( 1 ) {
print "Rin ";
GORK: if ( 1 ) {
print "Tin ";
goto GORK if $b ^= 1;
print "\n";
next GORK;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote: > At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote: > >Yes, this is akin to redeclaring every lexical variable every time you > >introduce a new scope. Not pretty, I know. But if you want run-time > >semantics with compile-time resolution > > That is exactly what it is, alas. If we allow lexicals to get injected in, > we need to either do this (Basically having every non-package variable > getting an entry in the scope's pad) or search backward. I don't much like > either option, but I think this is the best of the lot. > > So much for the "Extra braces don't carry any runtime penalty to speak of" > speech in class... :) Well, they still wouldn't. Mostly. All the pads could *still* be set up at compile time. All lexicals within a scope would be grouped together, which might (doubtful) help reduce paging. If pads were still arrays, the original construction would consist of memcopys - about as cheap of duplication that you'll get. And the performance hits would be taken only by a) the unqualified globals, and b) the actual twiddling of the lexical variables (both in lookup, and in manipulation). If you're going to take hits, that's where to take them. Of course, then you've got the bloat to worry about. Which might make your decision to go ahead and be slow an easy one.... But why are we on the language list for this? Back to internals we go.. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Tuesday 04 September 2001 09:09 pm, Damian Conway wrote: > A C is a statement, just as an C or a C is a statement. Okay, then I simply need to rethink/redefine how I'm defining a statement, (which is currently in terms of the statement separator). -- Bryan C. Warnock [EMAIL PROTECTED]
Re: What's up with %MY?
On Tuesday 04 September 2001 08:32 pm, Dan Sugalski wrote:
> Absolutely nothing. The issue is speed. Looking back by name is, well,
> slow. The speed advantage that lexicals have is that we know both what pad
> a variable lives in and what offset in the pad it's living at. We don't
> have to do any runtime lookup--it's all compile time. If we lose that
> compile-time resolution, things get a lot slower. (Runtime lexical name
> lookup is a lot slower than runtime global lookup because we potentially
> have a lot of pads to walk up)
>
> Certainly doable. Just potentially slow, which is what I'm worried about.
> Making it not slow has both potential significant complexity and memory
> usage. If we have to, that's fine. Just want to make sure the cost is
> known before the decision's made. :)
Well, the ultimate trade-off for speed is memory. Right now, pads are
differential - what are the list of things that were defined in my lexical
scope. Those things are evaluated at compile-time to the pad ancestry (how
far up was something defined) and the pad offset (where within that pad) the
value of a lexical exists.
my $foo;
{
my $bar;
{
my $baz = $foo + $bar;
}
}
(Although I don't know why I'm explaining this to you, because you know this
far better than I do.)
Anyway, that's really...
[0][0];
{
[1][0];
{
[2][0] = [0][0] + [1][0];
}
}
# Pad 0 = [ foo ]
# Pad 1 = [ bar ]
# Pad 2 = [ baz]
...awful. But you get the idea.
Of course, you can't inject a new lexical foo at the inner-most loop because
it's already looking two pads up.
But what if we went ahead and made pads additive - comprehensive, so to
speak?
[0][0];
{
# Dup pad 0, and build on it.
[1][1];
{
# Dup pad 1, and build on it.
[2][2] = [2][0] + [2][1];
}
}
# Pad 0 = [ foo ]
# Pad 1 = [ foo, bar ]
# Pad 2 = [ foo, bar, baz ]
Yes, this is akin to redeclaring every lexical variable every time you
introduce a new scope. Not pretty, I know. But if you want run-time
semantics with compile-time resolution
Let's see what this buys us Enough for another gig of RAM, I hope.
To replace the innermost foo, all you do is change where [2][0] points.
To delete the innermost foo, all you do is replace it with the value from
the next most innermost foo, which (if you implement this as an array), at
the same offset. Of course, if the variable was introduced at that scope,
then you point to the global instead.
To add to the innermost scope Hmm. I'm not dumb enough to suggest
copying all the globals in there.. Okay, how about this? Package
qualified globals will always resolve in a global variable, so they continue
to handle lookups like before. So that leaves us unqualified globals to
take the brunt of the performance hit, which I'm okay with... so far.
Now, the unqualified globals need to first check to see if they've been
lexicalized. If they have been, they'd appear in the pad at an offset
beyond where the next higher pad left off. (Since otherwise, they'd have a
pad entry already.) Since most of the time, that would be empty, it'd only
be a brief glimpse before pursuing the global. If there are some, then it
would have to scan for itself, and use whatever was appropriate.
It's ugly but quick... er.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: What's up with %MY?
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things get tricky. Though I suppose we could
> put some sort of placeholder with auto-backsearch capabilities. Or
> something.
Other than the obvious run-time requirements of this, what's wrong with
simply looking in the current pad, seeing it's not there, then looking in
the previous pad...? (Assuming you know the variable by name)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Tuesday 04 September 2001 06:39 pm, Damian Conway wrote:
> the "expr" is more likely to be a "parameter_specification".
Urk. I'll wait for the movie, I think.
>> >> 6. [ LABEL: ] expr if expr;
>> >> 7. [ LABEL: ] expr unless expr;
>> >
>> > I'm not at all sure modifiers will be stackable, as this grammar
>> > implies.
>>
>> Er, parsing error. Are you saying I've got it right or wrong? (I'm
>> intending non-stackable.)
>
> H. I had assumed that your grammar implies a statement is an expr.
> But perhaps it didn't.
The simplest statement is an expression. I'm trying to couch the definition
of what composes an expression to exclude 'if', 'while', 'for', etc.
Apparently right poorly, at that.
>> Wouldn't a null statement be covered by a statement of 0 expressions?
>
> Oops. Yes. I missed that. So you just need to s/terminator/separator/
Done.
>> Would you *please* consider reforming the 'when expr : { block }'
>> clause as when ( expr ) { block }
>> ?
>
> That's Larry's syntax. And Larry's decision. For what it's worth, I have
> previously argued against that colon. And you'll note that Switch.pm
> doesn't require it (except in Perl 6 compatibility mode)
Okay... well, Larry, if you're listening in.
>
>> Secondly, do 'when' clauses have targettable labels?
>
> They are not 'clauses', they are statements. So yes, a C can
> definitely take a label.
>
>> given ( $a ) {
>> when /a/ : { foo($a); next BAR }
>> when /b/ : { ... }
>>BAR: when /c/ : { ... }
>> ...
>> }
>
> That would be:
>
> given ( $a ) {
> when /a/ : { foo($a); goto BAR }
> when /b/ : { ... }
> BAR: when /c/ : { ... }
> ...
> }
If they were statements, wouldn't that be:
when /a/ : { foo($a); goto BAR };
when /b/ : { ... };
BAR: when /c/ : { ... };
...
That's why I was considering them blocks, which I, of course, mislabelled
clauses. Like if blocks and while blocks.
>
> Using C would (presumably) cause control to head up-scope
> to the first *enclosing* block labelled 'BAR'.
But wasn't a bare 'next' supposed to continue on to the next statement?
given ( expr ) {
when /a/ : { foo; next }
when /b/ : { bar }
}
If /a/ is true, do foo(), and then continue on to the next statement.
If that was/is still the case, then wouldn't a 'next LABEL' imply continuing
on to the next statement labelled LABEL?
Of course, if it is no longer 'next', then that's fine, too. We want things
to be consistently different.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Tuesday 04 September 2001 11:17 am, Garrett Goebel wrote:
> > Er, scratch this. Blows up if the sub isn't prototyped. A
> > much *better* way is to make the prototype of any sub a
> > property (trait) of that sub. We can always query for a
> > property.
>
> This is possible now:
>
> $foo = sub ($) { print "hello world\n" };
> print prototype $foo;
Well, it's nice to know that when I reinvent the wheel, it's still round.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Tuesday 04 September 2001 12:27 am, Damian Conway wrote:
> C and C
[ LABEL: ]
try { block }
[ [ catch [ ( expr ) ] { block } ] ... ]
?
>
> (C is not nearly so certain.)
>
>> Conditional Statement Modifiers
>>
>> 6. [ LABEL: ] expr if expr;
>> 7. [ LABEL: ] expr unless expr;
>
> I'm not at all sure modifiers will be stackable, as this grammar implies.
Er, parsing error. Are you saying I've got it right or wrong? (I'm
intending non-stackable.)
>
>> Iterative Block Constructs
>>
>> 20. [ LABEL: ] for[each] [ scalar ] ( list ) { block } # Note 4
>
> I am hoping that Larry will also give us:
>
> [ LABEL: ] for[each] (scalar, scalar ...) ( list ) { block }
>
>> Subroutine Code Blocks # Note 6
>>
>> 21. sub identifier [ ( prototype ) ] [ :properties ] { block }
>> 22. sub [ ( prototype ) ] { block }# Note 7
>
> Currently:
>
> 21. sub identifier [ ( prototype ) ] [ is properties ] { block }
> 22. sub [ ( prototype ) ] [ is properties] { block } [is properties]
>
> Though I would *much* prefer to see:
>
> 21. sub identifier [ ( prototype ) ] [ :traits ] { block }
> 22. sub [ ( prototype ) ] [ :traits] { block } [is properties]
Ah, traits is what I meant. But that's not final yet?
>
>> A statement consists of zero or more expressions, followed by an
>> optional modifier and its expression, and either a statement
>> terminator (';') or a block closure ('}' or EOF).
>
> Need to recast this in terms of statement separators and null statements.
Wouldn't a null statement be covered by a statement of 0 expressions?
>
>> A block consists of zero or more blocks and statements. A file is
>> considered a block, delimited by the file boundaries. Semantically,
>> I will define a block only in terms of its affect on scoping.
>
>
> "its effect on scoping"
> (we probably don't care about its pyschological demeanor ;-)
>
Thanks,
And while I'm at it, I have some questions for you! Would you *please*
consider reforming the 'when expr : { block }' clause as
when ( expr ) { block }
?
'if', 'unless', 'elsif', 'given', 'while', 'until', the looping 'for[each]',
and potentially the 'catch' clauses all use that form - 'keyword ( expr ) {
block }'. 'when' is the odd man out.
Secondly, do 'when' clauses have targettable labels?
given ( $a ) {
when /a/ : { foo($a); next BAR }
when /b/ : { ... }
BAR: when /c/ : { ... }
...
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote: > The third value is a "peek" value. Do the runtime checking, but don't do > any magic variable stuff. As a matter of fact, don't run any user-code at > all. Simply return a true or false value if the arguments *would* match. > (This allows us to check incoming coderefs, to see that they take the > arguments that *they* expect. Similar to the whole "pointer to a function > that takse a pointer to a function, and an int." Of course, no checking > the return value. But they're supposed to handle your want()s.) Er, scratch this. Blows up if the sub isn't prototyped. A much *better* way is to make the prototype of any sub a property (trait) of that sub. We can always query for a property. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Prototypes
A few more ideas to put down, lest I lay wake all night, thoughts churning...
One.
Presumably, there will be an op for the actual calling of the subroutine.
That op can take an (extra) argument, with one of three values, that the
prototype checking can get to.
The first value indicates that these arguments were checked at compile time,
and there is no variable wrangling that needs to be done. The runtime
checking would be skipped. So foo($a,$b) calls for sub foo ($$) {} would be
skipped, but not calls by reference, or calls if the prototype was sub foo
(my $a, my $b) {}.
The second value indicates that these arguments have not been checked, check
them now. Inject those variables, etc., etc. This is for calls by
reference, calls where magic assignments need to be made, etc.
The third value is a "peek" value. Do the runtime checking, but don't do
any magic variable stuff. As a matter of fact, don't run any user-code at
all. Simply return a true or false value if the arguments *would* match.
(This allows us to check incoming coderefs, to see that they take the
arguments that *they* expect. Similar to the whole "pointer to a function
that takse a pointer to a function, and an int." Of course, no checking the
return value. But they're supposed to handle your want()s.)
Two.
Secondly, there's another issue with the prototyping code - magic.
Specifically, tied variables, (which some will say aren't magical. They're
pretty magical to me.)
Anyway, to do some checking, one could conceivably (depends on how specific
prototyping could go - you could say something as detailed as (my $a < 4;)
to handle bounds checking on your input as well) call FETCH on a
variable for which the FETCH is what's the word I'm thinking of? - the
FETCH just to check the code could change what the actual value to be used
later on would have been. Like a self-incrementing counter.
Anyway, the tie interfaces need to add a PEEK, which would return what the
next FETCH will return, when it is called. That will allow us to safely
test tied variables without screwing things up.
(Generally speaking, that should probably be done now for exactly the same
reason.)
Three.
We need to decide what happens when someone attempts to replace a prototyped
sub with another sub - whether that sub is not-prototyped, prototyped
exactly the same, or prototyped differently. Multiple dispatch on functions
could alter our approach to the third. Direct calls have already been
attested to at compile time. The call has just changed...
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Monday 03 September 2001 10:46 pm, Dan Sugalski wrote:
> At 10:32 PM 9/3/2001 -0400, Bryan C. Warnock wrote:
> >On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote:
> > > >To me, that seems only a language decision. This could certainly
> > > > handle that.
> > >
> > > Ah, but calling in the first way has two PMCs in as parameters, while
> > > the second has only one. Potentially at least. A world of difference
> > > there.
> >
> >A single PMC? (A list of pointers to PMCs?)
> >
> >Or, to think of it another way, how are you going to pass two scalars, or
> > an array of two scalars, to a sub with *no* prototype?
>
> We create a list, stuff our bits into the list, and pass the list. @_ will
> point to the list.
>
> Lists can access their contents as if they were a list of scalars even if
> they're not. (So we can avoid flattening in cases we don't need to)
>
Well, then that's how. Remember, this prototype idea, besides allowing
automatic variable setting and such, was really just a musing on how to get
prototype checking at runtime, where compile-time checking isn't possible.
{
my $a = sub ($$) { code };
gork($a);
}
sub gork {
my ($a) = shift;
$a->(@some_list); # <- Here
}
The reason prototypes aren't checked at "Here" is because there really isn't
a way to know what the prototype was. So you're just passing the list like
you normally would. Having the prototype checking code as part of the code
doesn't change anything above at all.
In other words, you can't think about how a prototype would affect the
calling convention, because, by definition, you don't know of any prototype
unless is a direct named sub call that you've checked at compile time.
Of course, I suppose that by default the runtime checking would be done even
for sub calls that have been compiled-time checked... Which defeats the
second purpose of compile-time checking (saving time during the run), but I
think we can find away around that...
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote: > >To me, that seems only a language decision. This could certainly handle > >that. > > Ah, but calling in the first way has two PMCs in as parameters, while the > second has only one. Potentially at least. A world of difference there. A single PMC? (A list of pointers to PMCs?) Or, to think of it another way, how are you going to pass two scalars, or an array of two scalars, to a sub with *no* prototype? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Prototypes
On Monday 03 September 2001 09:30 pm, Dan Sugalski wrote:
> A clever idea, and one I'd not though of. That's probably the best way to
> do it. Has some other issues, like do we allow prototypes like:
>
>sub foo ($$) {};
>
> to be called as:
>
>foo(@bar)
>
> if @bar has two elements in it?
To me, that seems only a language decision. This could certainly handle
that. The internals problem is figuring out how to signify all the
different variations you could allow. :-) (And how they could affect what
is being passed in.)
For instance, I knew the autoreferencing of an array with a (\@) prototype
was a bust (as in Perl 5). But, IIRC, Perl 6 is passing everything by
reference, with the user explicitly flattening any lists. You can always go
from references to lists, just not the other way around, so this still works.
There are a couple of other prototype tricks that we'd have to work out...
Unseparated bare code blocks for (&) prototypes come to mind.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: My, our, thems-over-theres.....
A while ago, I posted some inconsistencies with scope declarators.
(http:[EMAIL PROTECTED]/msg08028.html)
A few more related notions
$a = "test";
{
chop(my $a = our $a = "hello");
# The lexical is chopped
print "1-$a\n";
# But the global is printed
}
print "2-$a\n";
# The assignments are evaluated right-to-left, resulting in the lexical
# being chomped. But the rightmost declaration is the one propogated
# through the rest of the scope.
$b = "test";
{
chop($b = my $b = "hello");
# The global is chopped
print "1-$b\n";
# But the lexical is printed
}
print "2-$b\n";
# This one makes sense. The lexical is created and initialized with
# "hello". That value is then passed to whatever the current $b in
# use is - the global (by default). The lexical doesn't come fully into
# view until the next statement.
$c = "test";
{
chop(our $c = my $c = "hello");
# Bizarre warning... but the global is chopped.
print "1-$c\n";
# The lexical is printed
}
print "2-$c\n";
# Here, Perl recognizes that there were two variable declarations,
# (since 'our' currently affects all subsequent variables on the same line)
# The global is still chopped, because it was the last one assigned, but
# the lexical takes affect, since it was the last one (in left-to-right
# order) declared.
Obviously, this is most heinous code to write. And except for problems
centered around when the declarations take affect, it warns appropriately.
'our' is a true accessor, meaning you can query the value, or you can set it.
'my' and 'local' aren't. They set the value to 'undef' or the value you
pass in. (Perhaps it'd be easier to think of it as 'our $a =
$__PACKAGE__::a')
In either case, that means an assignment is ultimately involved.
Assignments are handled right-to-left, so I think the scope declarators
should be too. (Once all the other problems are fixed.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Monday 03 September 2001 01:06 pm, DavÃð Helgason wrote:
> We will be adding 'try' & 'catch'. 'finally' also? (or 'finalize' :-)
I've not heard anything definite on this.
>
> >16. [ LABEL: ] when expr : { block } # Note 5
> >
> >[Note 5. 'when' is only a valid construct when directly within a 'given'
> > construct.]
>
> Someone talked about given(expr) getting to be the same as for $_ (scalar
> expr). (Couldn't find that mail in my mailbox, wierd?). Perhaps with an
> added check that expr is actually a reference (though I can't really see
> why, unless for a bit of good old B&D).
If I understand you correctly, the discussion was that the expression in
'given ( expr )' will be evaluated in scalar context.
> >
> >21. sub identifier [ ( prototype ) ] [ :properties ] { block }
> >22. sub [ ( prototype ) ] { block }# Note 7
>
> Is it on purpose that coderefs can't have properties? This goes back to
> variable/value properties. I never liked value properties very much, but
> while it seems that ':inline' and ':multi' don't make a lot of sense here,
> ':memoized' does.
Yes, it does make sense to have properties there. I omitted them because I
couldn't think of any. I haven't seen any decision to the contrary, so I
may add them back in. (The may not do anything, but they'll be there. Much
like the prototypes for it.)
>
> So we should have:
> 22. sub [ ( prototype ) ] [ :value_properties ] { block }
> 22. sub [ ( prototype ) ] { block } [ :value_properties ] # Or
> better?
The first, as it's more consistent with # 21.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I could make
> a good language case for and against it. It adds overhead on sub calls,
> which is a bad thing generally. (I'd be OK with the declaration "All
> prototyped subs must have their prototypes known before the BEGIN phase is
> done"... :)
Well, here's a simple, yet stupid, idea. (And I'd be content with having
prototype declarations being a compile-time only requirement, too.)
Code injection, a la Perl's -p and -n switch.
sub foo (protoype) {
code
}
is compiled as
sub foo { {
my $proto = prototype;
# prototype checking code here. Must be non-destructive on @_
}
code
}
- It only affects the specific subroutines that declared prototypes in the
first place.
- With the ability to inject lexical variables up a scope, prototype
assignment would work...
sub foo (my $bar, my Dog $baz, my @array) {
# $bar, $baz, and @array are all visible
}
- It's certainly pluggable. It could even be written in Perl. That means
powerful prototyping capabilities.
- Automagically works with named subs and code references, subroutine
replacement a la 'goto &cref', and any other way you could think of calling
the subroutine.
- If the subroutine is ever replaced, the prototypes magically go away. (Or
are replaced by ones in the new code.)
- It could be standard enough (from an opcode generation perspective, that
B::Deparse would be able to reconstruct the original subroutine code.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks [first,last]
On Sunday 02 September 2001 06:27 pm, raptor wrote:
> ]- yep I didn't thougth about that I can be sure I'm at the last
> iteration only with some sort of 'callback' which will be called at the
> exit of the loop... but not as some sort of generalised-check condition..
Umm, it's simpler than that.
iterator (list) {
code;
}
# <- If you are here, you just completed your last iteration.
# (Unless you goto'd somewhere else, obviously. But that would
# skip the callback, too.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Prototypes
On Sunday 02 September 2001 08:18 pm, Michael G Schwern wrote:
> On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
> >
> > The following parses, but doesn't do anything, including warn.
> >
> > my $a = sub ($) { print };
>
> Warning because you said you take an argument and then did nothing
> with it... that could be useful (I can actually think of a few
> situations where you'd want to do that, but they're rare) but it would
> involve scanning the subroutine at compile time to see if you use @_
> and what bits of it you use and if they're the right bits, etc...
>
>
> But since the current prototyping system... has a highly positive
> pressure gradient compared to the surrounding air, hopefully we
> won't be saddled with it in Perl 6 and will be able to write something
> more sensible, like RFC 57 suggests:
>
> my $a = sub ($foo) { print }
>
> then it's simply a matter of seeing if that declared variable is ever
> used in the sub.
Oh. That's not even what I was talking about, but I see your point. I
shall file that question away for later.
I was referring to the prototype not being checked at all.
my $a = sub ($) { my $b = shift; print $b, "\n" };
$a->();
Nothing (other than the undefinedness of $b). I would expect either
a) a prototype mismatch error, or
b) A "prototype is useless with an anonymous subroutine" warning.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Prototypes
Are prototypes going to be checked at runtime now?
The following parses, but doesn't do anything, including warn.
my $a = sub ($) { print };
--
Bryan C. Warnock
[EMAIL PROTECTED]
Redo the next to last goto (was Re: LangSpec: Statements and Blocks)
A thread from last July, WRT bug ID 2717.003 [1], suggested that we may
want to revisit the behavior of flow control expressions within the context
of a subroutine.
The current behavior is to find the closest (labelled) enclosing loop
(dynamically, not lexically), and treat that as the target for the flow
control expression - unwinding any stacks necessary. It does
produce a warning with '-w'.
The following code demonstrates:
#!/usr/bin/perl -w
$a = 'a'; $c = 0;
sub frok {
return gork(@_);
}
sub gork {
my ($a) = @_;
redo if $a eq 'd' && ! $c++;
next if $a eq 'h';
last if $a eq 'o';
return ++$a;
}
while ( $a++ ) {
print "1. $a\n";
$a = frok($a);
print "2. $a\n";
}
continue {
print "3. $a\n";
}
print "Done\n";
The suggested alternative was to treat loop control expressions which would
exit the subroutine to be equivalent to 'return;'
The main argument against the current behavior related to "action at a
distance", and code needing to protect itself from poorly written callbacks.
FWIW, here's my opinion. (I'm in favor of the current behavior.)
1) The current behavior, however heinous, actually has a use. There's no
value added in having five ways to return undef.
2) It reflects the intended use. The programmer was most likely trying to
execute *some* form of loop control, however misguided they may have been.
Perhaps the subroutine was originally code in a larger loop, and the code
was shuffled off to a subroutine to make the loop simpler. Perhaps the
coder mistakenly thought the subroutine was a loop. The current behavior
allows the preservation of the first if it were intended, and warns on the
second, if it weren't.
Most likely, if a coder intends to return, they actually return. Granted,
there's an implicit return off the end of a function, and perhaps the coder
thought 'last' may get them there. But instead of returning the value of
the last statement, you return nothing. And with no warning. And that
helps 'last', but not the other three. 'next' is nonsensical, 'redo' even
more so, and a 'goto' that doesn't just doesn't seem right.
3) It's consistent. The same behavior currently happens within an eval
block. If you were to define 'return;', you'd have to also redress eval
behavior.
Does anyone wish to argue for any other behavior, or may we consider this
revisited?
[1] http://www.mail-archive.com/perl5-porters@perl.org/msg12899.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks [first,last]
On Sunday 02 September 2001 01:47 pm, raptor wrote:
> As we read in Damian Conway- Perl6-notes, there will by a var-iterator
> that can be used to see how many times the cycle has been "traversed" i.e.
>
> foreach my $el (@ary) {
>.. do something
> print $#; <--- print the index (or print $i )
> }
>
> shall we have :
>
> foreach my $el (@ary) {
> print $# if $#.first(); <--- print the index on the first iteration
I think it's just a simple counter.
print $# if $# == 0;
> i.e. 1
0
>.. do something
> print $# if $#.last(); <--- print the index on the first iteration
I don't know if (and if so, how) you would see if you were on the last
iteration. (And would that be last, as in the very last argument passed in,
or last, as in you're not going to iterate again?)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: LangSpec: Statements and Blocks
On Sunday 02 September 2001 12:48 am, Uri Guttman wrote:
>
> i don't consider sort/map/grep blocks to be basic like the others. also
> sort/map can take espressions which is a different syntax.
Yes, I'm not addressing sort/map/grep/do as much as demonstrating a block
that appears in one of those expressions. I will note that. They were
grouped within basic constructs because, well, frankly I didn't have
anywhere else to put them. (Block Expressions, perhaps?)
>
> what about eval BLOCK? i think that is being renamed to throw/catch but
> it takes a code block too.
Yep. Missed it. And that's a big one.
>
> BCW> Conditional Statement Modifiers
>
> BCW> 6. [ LABEL: ] expr if expr;
> BCW> 7. [ LABEL: ] expr until expr;
>^
> unless
Thanks.
>
> BCW> Looping Statement Modifiers
>
> BCW> 8. [ LABEL: ] expr while expr;
> BCW> 9. [ LABEL: ] do { block } while expr;# Note 2
>
> i see the note, but that is not special. just a simple expression with a
> modifier. now, if the do BLOCK while() were to support loop semantics,
> it would be special here.
Evaluation order.
>
> BCW> 10. [ LABEL: ] expr until expr;
> BCW> 11. [ LABEL: ] do { block } until expr;# Note 3
>
>
> BCW> Iterative Statement Modifiers
>
> BCW> 12. [ LABEL: ] expr for[each] list;# Note 4
>
>
> BCW> Conditional Block Constructs
>
> BCW> 13. [ LABEL: ] if ( expr ) { block }
> BCW>[ [ elsif ( expr ) { block } ] ... ]
> BCW>[ else { block } ]
> BCW> 14. [ LABEL: ] until ( expr ) { block }
> ^
>
> unless (again :-)
Ugh. What was I on?
>
>
>
> BCW> A statement consists of zero or more expressions, followed by an
> BCW> optional modifier and its expression, and either a statement
> BCW> terminator (';') or a block closure ('}' or EOF).
>
> how do you have multiple expressions in a statement? when you combine
> expressions you just get one larger expression.
I was specifically addressing the statement modifiers (trailing ifs,
UNLESSes, whiles, etc.). The modifiers themselves aren't really
expressions although they take them. If they were, then
'expr if expr while expr' would be legal.
>
> also perl has statement separators, not terminators. with that
> definition you don't need to mention block close or EOF.
I never really thought about it that way. Excellent point. I shall make
that change.
>
> BCW> Flow Control Expressions
>
> BCW> A. goto
> BCW> B.
>
> B. was intentionally left blank.
I got tired. :-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
LangSpec: Statements and Blocks
enced by their interaction with flow control. However, this definition isn't consistent, and I will avoid it.) Flow Control Expressions A. goto B. last next redo Detailed Descriptions (Here, I'll go into exactly how each one of these is different from all the others, and explain each construct's interaction with flow control expressions and internals) Notes 1. An expression which uses a block. 2. A specialized form of 5. 3. A specialized form of 7. 4. 'for' and 'foreach' are synonymous. 5. 'when' is only a valid construct when directly within a 'given' construct. 6. Subroutines are covered in depth in a separate document. 7. An anonymous subroutine is technically an expression. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: !< and !>
On Saturday 01 September 2001 05:40 pm, Russ Allbery wrote: > Sterin, Ilya <[EMAIL PROTECTED]> writes: > >> From: Russ Allbery [mailto:[EMAIL PROTECTED]] > >> > >> How is !< different from >=? > > > > It's just more syntax just like foo != bar > > is the same as (foo > bar || foo < bar). > > > > It might prove convenient to express the expression. > > It's the same number of characters. How can it be more convenient? You only have to manipulate the shift key once! ;-) I'm waiting for someone to say that in tri-state logic, '!<' != '>=' -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Source/Program metadata from within a program
On Friday 31 August 2001 01:13 am, Brent Dax wrote: > Cool--I'd suggest a special $*CODE filehandle, to match $*DATA (that > isn't going away, is it?). IIRC, $*DATA is going away, in favor of something a little more Inline::File-ish - i.e., an arbitrary number of arbitrarily named pseudohandles. But there's probably no reason that $*CODE couldn't specifically refer to the entire file. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Source/Program metadata from within a program
On Friday 31 August 2001 01:13 am, Brent Dax wrote: > # -Original Message- > # From: Dave Storrs [mailto:[EMAIL PROTECTED]] > # I'd also like to be able to access information on the > # particular perl that > # is running this program...e.g., does it support 64-bit nums, > # what is the > # endianness of the native numbers, does it support threads and > # (if so) what > # threading model (though this is probably a moot point in P6, > # perhaps it > # is something that could be included into 5.8.x). > > Can't this sort of thing be in Config.pm (or its equivalent)? Since > Parrot needs to know things like endian-ness and for reading precompiled > bytecode anyway, we might as well make it convenient... For the static information with the interpreter, yes, probably ~Config.pm. However, (once again thinking about precompiled bytecode), the appropriate static configuration info from the perl that compiled a particular unit may be nice, although most likely unnecessary. Although, with the exception of endianess and native extensions, the bytecode is supposed to be the same. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Source/Program metadata from within a program
On Friday 31 August 2001 01:13 am, Michael G Schwern wrote: > On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote: > > Access to the source code. > > Already got that. Not if we don't have the source. Or perhaps this will be the way we do it. Dunno. Perl Bytecode has a section for storing the source code. I was thinking more of that. > > > Compilation time. For each of my compilation units, I would like to > > know when it was compiled. Compilation unit scoped. > > You can already do that. Override CORE::GLOBAL::require/use/do. > > Your overridden require/use/do can mark the time it was called *and* > remember the *DATA filehandles. On an error, you can do: Not called. Compiled. Once again, I'm thinking of pre-compiled bytecode modules. > > When will we be seeing the CPAN module for this? Looks like you just wrote it. :-) -- Bryan C. Warnock [EMAIL PROTECTED]
Source/Program metadata from within a program
Many of Perl 5's global variables are becoming properties of various Perl 6 entities - $. and $/ for input filehandles, for instance. There is still a large subset of global information that describes the program itself - some of which has been called for removal (or at least burial within some module) - plus more information that we *could* access, because we would be carrying it around. The former being runtime information like.. $] $0 $$ $< $> $( $) $^C $^D $^H $^M $^O $^S $^T $^V $^W $^X Will this remain global? Will we have an introspective module that we can use to access this information? In either case, there is some more information that we may or may not have, that it would be nice to be able to have access to I will refrain from naming them, as noone ever likes how I name things Knowledge of the complete (relative) path to each component of a perl program, as it was loaded. For example, within Foo.pm as /usr/lib/perl6/Foo_v1_by_whomever/Foo.pm (from the @INC lookup). 'perl ../foo' as '../foo', regardless of what games I play with $0. If we're going to have multiple versions of modules, I would like to be able to report specifically which one it really is. If we could realpath() it, that'd be even better, but that's not for the builtins. File scoped. Most likely, you'll want access to the rest of the module's metadata, too. (If you specified wildcards, for instance.) Knowledge of whether a file was the perl program invoked, or if it were included from another file. For example, running 'perl foo' would have a true value for the file 'foo', but a false value for Foo.pm, which it may 'do', 'use', or 'require'. File scoped. Access to the source code. We're going to be carrying it around, unless we strip it. We might as well put it to good use within error messages and the like. If an error points me to foo:356, I want my DIE handler to dump the code surrounding that. Useful for when I'm on a server, far from the source code I didn't deploy with the compiled exectuables. This would more or less be how a remote debug would have to work anyway. Compilation time. For each of my compilation units, I would like to know when it was compiled. Compilation unit scoped. -- Bryan C. Warnock [EMAIL PROTECTED]
My, our, thems-over-theres.....
Three variable scope declarators, three different behaviors (as recent as
5.7.2)
(Set One)
$a = 'a';
{
my $a .= 'b', $a .= 'c' if $a .= 'd', $a .= 'e';
}
print $a, "\n"; # adec
$b = 'a';
{
local $b .= 'b', $b .= 'c' if $b .= 'd', $b .= 'e';
}
print $b, "\n";# ade
$c = 'a';
{
my $c = 'f';
our $c .= 'b', $c .= 'c' if $c .= 'd', $c .= 'e';
}
print $c, "\n";# adebc
(Set Two)
$a = 'a';
{
$a .= 'b', $a .= 'c' if my $a .= 'd', $a .= 'e';
}
print $a, "\n";# aebc
$b = 'a';
{
$b .= 'b', $b .= 'c' if local $b .= 'd', $b .= 'e';
}
print $b, "\n";# a
$c = 'a';
{
my $c = 'f';
$c .= 'b', $c .= 'c' if our $c .= 'd', $c .= 'e';
}
print $c, "\n"; # ade
I'm sure this makes absolute sense under-the-hood, and it is documented
(sort of) to behave this way, but isn't it a tad too inconsistent, even for
Perl? (Particularly 'my' vs 'our'. 'local' makes sense with its current
behavior, but I'd personally rather it were consistent, too.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
given when
More questions regarding the new 'given when' construct.
1) Is a 'when' clause required? Is it:
[ LABEL: ] given ( expr_1 ) {
when expr_2 : block
[ when expr_3 : block ...]
expr_n [;]
}
or
[ LABEL: ] given ( expr_1 ) {
[ when expr_2 : block ...]
expr_n [;]
}
?
2) In expressions 2 through n-1 - the equivalent to 'case' - you may refer
to the return value of expression 1 with $^_. Does this imply that
expression 1 will always (and only) be evaluated in scalar context? If not,
can you mix contexts across 'when' clauses? Is the value of $^_ then a
reference to the return value?
3) Can you refer to $^_ within expression n - the equivalent to 'default:'?
given ( a() ) {
print $^_; # No when clause? See #1
}
4) Can you refer to $^_ within the code blocks of each 'when' clause?
given ( a() ) {
when $^_ == 1 : { foo($^_) }
when $^_ == 2 : { bar( 5 + $^_ ) }
when $^_ == 3 : { ++$^_ and print $^_ } # Mutable? See #5
}
5) Is $^_ an alias, reference (See #2), or a copy of the return value of
expression 1, and is it mutable? Does it have the appropriate magic and
overloading capabilities?
6) How many times is expression 1 evaluated?
$a = 0;
given ( ++$a ) {
when $^_ > 5 : { #foo }
when $^_ > 4 : { #bar }
when $^_ > 3 : { #baz }
#foobar
}
I would expect that $a would equal '1' after #foobar executed. But if
multiple contexts are allowed (see question 2), how would
sub a { # returns something different based on scalar or array context }
given ( a() ) {
when $^_ =~ /foo/ : { #foo in scalar context, with "" overloading? }
when $^_[5] eq "bar" : { #bar in list context (bad variable) }
when $^_ : { #baz in boolean context? }
when $^_ + 5 > 15 : { #foobar in scalar, with addition overloading? }
#default
}
be evaluated? In particular, would the fourth 'when' clause (the second use
of scalar context) use the previously obtained scalar value?
7) The 'when' blocks are not fall-through, a la C's switch statement. You
can obtain a similar result by invoking 'next' within the 'when' block.
given ( $a ) {
when expr1 : { print "*" && next }
when expr2 : { print "*" }
}
Is this regardless of whether expr2 would have also evaluted true? (IOW,
does it truly jump to the next block?) If not, does it jump to the
expression after that (if it exists) and try again, or does it default
expression (since the original next expression evaluated false)?
8) Is the order of evaluation guaranteed? (I assume so, but just thought
I'd check.)
9) It has a lexical construct similar to a conditional block, so that
lexical variables declared in the 'given' expression are within the inner
scope, correct?
$a = 5;
given (my $a = 1) {
when $^_ == 1 : { print $a } # 1
print $a; # 1
}
print $a; # 5
10) I've already asked Damian this question on the side, but I'll repeat
(and expand) it here, to give me an even ten. Should it be a single default
expression, multiple default expressions, or a default block?
[ LABEL: ] given ( expr_1 ) {
...
expr_n [;]
}
[ LABEL: ] given ( expr_1 ) {
...
expr_n
[; expr_n+1 ... ] [;]
}
[ LABEL: ] given ( expr_1 ) {
...
block
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: properties, revisited
On Thursday 02 August 2001 10:38 pm, Edward Peschko wrote: > Statement: $bar isnt my_prop; > > This makes $bar keep all of its properties, removing my_prop; No. This gives $bar the negation of my_prop, whatever it may be. It may be its removal, it may be something else. > Anyways, just a clarification. Get rid of the distinction between 'value' > or 'variable' properties, and you have no clumsy syntax or confusion. No, you simply have a different clumsy syntax and different confusion. And you lose the distinction between properties, which, I agree, wouldn't be bad, except that there is a distinction between variables and the values they contain. For "out of band" data, properties sure have a strong affect on things. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: properties, revisited
On Thursday 02 August 2001 08:47 pm, Dan Sugalski wrote: > At 06:57 PM 8/2/2001 -0400, Bryan C. Warnock wrote: > >Here's how I'm documenting it. Corrections requested. > > > >Properties are by Perl thingy. (scalar, array, hash, reference, blessed > >reference?, file handle, etc) > > I think they're supposed to be both by perl thingie and by value. So: > I was generally classifying literals as scalars (even though I realize they're not scalars, they're literals - the specific properties overlapped). It seems the only consistent interpretation is that the differentiation between a variable property and a value property is what side of the assignent operator you're on. (Which is wrong, as I'll explore below. I'm leaving my misconceptions in place for whomever to examine, as a case study for further misconceptions.) >my $foo is const = 0 is true; my $bar is const = $foo is true; I'm assuming here that (assume $foo is mutable) that it's the value of $foo that is being tagged as true, and not $foo itself. (Not that it would make a lot of sense as a variable property.) But is that value tagged before or after the value itself has been retrieved? Is the value inside $foo above tagged as true or not? > the trueness of 0 is copied (since the value is copied, along with > properties on the value) while the constness of $foo is *not* copied, as > it's a variable property and those stick with the variables. Now that you've got me thinking about it, that brings up some interesting questions. $bar = $foo is my_prop = 0 is some_prop; ($bar = $foo is my_prop) = 0 is some_prop; $bar = ($foo is my_prop) = 0 is some_prop; Who's what when this is all done? How about void or boolean contexts? Damian uses this a lot in E2. $foo is chomped; $foo prompts; bar while ($foo is greedy); Hmmm. Actually, what makes *more* sense than that is the property itself. I think a property will need to tell Perl (or maybe handle it itself) whether it is a value property or a variable property. $bar is constant = $foo is true; # constant is a variable property, true is a value property. Therefore, # $bar is constant, and the constant isn't clonable. $bar is also true, and # that *is* clonable. But wait, what it we want to make $foo true? Or, actually, the value in $foo true? $foo is true; $foo = $foo is true? (And could that be shortened to '$foo is= true;'?) $foo is now true;? (Allow 'now' to refer to the thing holding the current value?) $bar is constant = $foo is now true; (And speaking of trueness, how do you turn it off if you want? You can't say '$bar is false', cause then the value is always false.) $foo is true = $bar is constant; # The value in $foo (gotten from $bar) is true. $bar is made constant. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: properties, revisited
On Friday 03 August 2001 04:09 pm, Brent Dax wrote:
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
>
> # i.e. which of these is illegal
> #
> # %foo{c} = 1; # error
> # %foo{a} = 2; # probably error, but it would be nice
> # # to have a form of hash-constness that
> # # locks only the keys
> # $foo{b}->increment; # OK
>
> That "form of hash-constness that locks only the keys" is currently being
> discussed on p5p; it's being called clamp. So you could probably say
>
> %foo is clamped;
>
> and get that behavior.
Both arrays and hashes probably warrant something. I understood 'clamp' on
p5p in verb context, but would rather see something a little more
descriptive as an adjective.
I was originally thinking 'fixed', but that makes the distinction between
changable and non-changeable internal values nebious - which is constant and
which is fixed?
I then thought about 'resizable' That wouldn't allow the addition or
deletion of keys (or indices), but would allow the internal values to be
changed.
Today, I don't particularly care anymore.
In any case, properties will be pushed to the bottom of my stack for things
to document. There's a lot of Perl 6 contending for the bottom position, it
seems.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: properties, revisited
Here's how I'm documenting it. Corrections requested. Properties are by Perl thingy. (scalar, array, hash, reference, blessed reference?, file handle, etc) That allows different things to be 'foo', for the appropriate definition of 'foo'. --- Second thought: Scribbling Servant from Savage writes: Damian, You mentioned in E2 that the chomped property relies on the insep property of the filehandle (formerly $/). Can I extrapolate that $. $, $\ $| will also be properties on filehandles? (How about $" for arrays?) Will they only be accessable as properties, or will there also be a proper member/method of some class (or metaclass)? The syntax (currently) is the same. Come to think of it, are properties really anything more than a nicer (IMHO), more Anglican replacement than traditional get_ and set_ methods? Properties interract with (potentially dynamic attributes), while member functions do the real work. -- Bryan C. Warnock [EMAIL PROTECTED]
properties, revisited
If I've got a set of matching properties, do I get to build hotels on my hashes? There are a number of properties "built into" Perl 6. Nearly all of these properties don't make sense across the board - eg, a scalar won't have a dimension, a hash won't prompt, etc. So given the two different sets that you must consider (variable versus value, and hash versus array versus scalar versus filehandle), are properties that are meaningless for some section usable by the user? (Realizing that there was talk about distinguishing between value and variable properties...) # scalar variable property doesn't allow $foo to be changed $foo is constant = 3; # But this doesn't make sense, as 3 is already constant. $foo = 3 is constant; # Error? Or simply user-defined? Example 2: $*ARGS is chomped; # Fine, but %hash is chomped; # Is this legal? An error? # (The chomp character is defined by the IRS attribute of a filehandle.) # Can I define something that says to chomp the values entered # into the hash? The keys? # What if the hash is tied to a filehandle? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: stealing something from plan9 os
On Wednesday 01 August 2001 10:04 pm, David L. Nicol wrote: > I hope this isn't too stale to talk about. > This is perl6-language. Nothing, it seems, is too stale to talk about. We're still brainstorming, even though the RFC period ended 10 months ago. > Please restrain from telling me that the discussion is over > and the "." decision is made ond over, for the moment. Okay, but. > > James Mastros wrote: (on June 21) > > > I still fail to see why "." is such an advantage over ->. > > The only real benifit I see is typing ease, and -> isn't that > > hard to type. That's what editor macros are for. > > What about replacing "->" with "/" ? Your idea aside, I think the substitution was more to gain the '.' than to replace the '->'. -- Bryan C. Warnock [EMAIL PROTECTED]
Extending POD (was (indented tables))
(migrated from perl-qa) On Wednesday 01 August 2001 03:10 pm, David L. Nicol wrote: > "Bryan C. Warnock" wrote: > > I didn't have a good solution for tables, mainly because I didn't like a > > tab, comma, or pipe separated solution. (Which isn't intended as > > commentary on Ziggy.) > > Here's a possibility -- new rows are indicated by a flush-left line, > each column has a line. (this happens to be how I like to lay out > my data data.) > > Table of Students: > > Last Name > First Name > Exam Grade > Semester Grade > Cup Size > Aardvark > Chris > D > B > A > > > The thing might end at the first blank line. It's too awkward to read and write, particular if you have a lot of columns. I toyed with automatic column detection for a while - (convert any tabs to spaces, convert whitespace to 1s, non-whitespace to 0s, and & all the lines together. Splitting on /(1+)/ allows determination on each individual column width, as well as the space between columns. Then generate the appropriate format on the fly, and fill it in with the heavy use of substrs. It was supposed to allow table creation in the same vein as "I'll figure out what you're trying to do, just do it.", and it worked fairly well for me. Couldn't handle multiline entries, was my biggest problem. Then I realized that I was doing it all in a fixed width font, and the whole thing was worthless in the customer's WYSIWYG environment. But I digress...) I basically came to the conclusion that there was no real easy way to produce a table without resorting to input that makes you focus more on the table itself than the data you're putting in. And when it comes to documentation, the latter is much more important than the former. Unlike Ziggy, however, we didn't have a lot of tables to produce, so the customer was content with table production in a spreadsheet, which I could then process during page generation. Obviously, that won't work for POD, and I do feel that POD needs table support. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: if then else otherwise ...
On Monday 30 July 2001 07:29 am, Bart Lateur wrote: > On Sun, 29 Jul 2001 19:36:43 -0400, Bryan C. Warnock wrote: > >$x = ($default,$a,$b)[$b<=>$a]; # Much like I did before > > Note that > > $x = cond? a : b > > does lazy evaluation, i.e. the value for a or for b is only fetched when > it's actually needed. In your construct, they're all fetched anyway, > before the condition is even checked. Excellent point. Something to remember for the future. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Lexicals within statement conditionals
On Monday 30 July 2001 05:37 am, Me wrote: > In a nutshell, you are viewing: > > foo if bar; > > as two statements rather than one, right? > Yep. The 5.7 docs explain it rather well, I think. Too bad I didn't read them until *after* I had posted and taken off for work. -- Bryan C. Warnock [EMAIL PROTECTED]
Lexicals within statement conditionals
Yes, this is semi-related to the 'my $a if 0;' behavior.
Out of morbid curiosity (since I'm working on documentation), given the
program that the following program generates:
#!/your/path/to/perl -w# perl 5.6.1
my @l = ('a' .. 'g');
my $my = 0;
for my $v (@l) {
my @a = map { "\$$v .= '$_'" } @l;
$a[$my++] = "my $a[$my]";
print shift @a, ";\n{\n",
join (", ", @a[@a/2 .. $#a]), " if ",
join (", ", @a[0 .. @a/2-1]), ";\n";
print <<"EOF";
print "$v: \$$v\\n";
}
print "$v: \$$v\\n";
EOF
}
__END__
I'm found tests B, C, and D a little surprising. I expected 'befg/acd',
'cefg/abd', and 'defg/abc' (lexical/global answers, respectively).
Although I now understand what it does, I'm still fuzzy on the why and how.
Can someone in the know give a clear enough explanation that I can document?
The rest of you can debate whether or not this behavior should change for
Perl 6.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: if then else otherwise ...
On Sunday 29 July 2001 04:32 pm, raptor wrote:
> index(ref $var, 'A') - 1 ? SCALAR-LVALUE-case : HASH-case : ARRAY-case;
That one is actually rather clever
Most of your examples, however, look like you are attempting to bandage some
poorly designed code upstream. (Perhaps not, but writing logic built around
<=> or cmp as a control flow is rarely a good idea.)
>
> $x = $a <=> $b ? $a : $default : $b;
>
This was your lone example that actually made some sense, and the only
non-standard answers (by which I mean conventional control flow methods) I
can think of are:
$x = ($default,$a,$b)[$b<=>$a]; # Much like I did before
($x) = sort { $a <=> $b or $default } ($a,$b);
# Since <=> and cmp were created more-or-less specifically for sort
The former is faster than the latter, but neither are as quick as the more
conventional structures.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: if then else otherwise ...
Linguistically, "if then else, otherwise" doesn't make sense, since 'else'
and 'otherwise' are synonymous.
? : : suffers from the same problem, just in terms of the ternary ?:
operator (which of course, wouldn't be ternary anymore) instead of English.
I'm not sure if there will be ambiguity where the standalone colon is being
used elsewhere, but I suspect that it would make parsing more difficult.
(At least in a BNF grammar.)
Regardless of how you perceive the results of <=> and cmp, it's still two
conditionals. Something has to make the differentiation between positive
and negative.
You're simply asking for another way of writing 'if {} elsif {} else {}',
because you don't like 'elsif'. Fine. As has been said before, use a
switch.
given ($cond) {
when 1:
when 0:
when -1:
}
Is the marker still ^_?
given ($cond) {
when ^_ > 0:
when ^_ < 0:
default: # Or whatever default will be named.
}
Still too verbose? Let's look at your example
> $whereCond = $cond ? ' field > $x AND ' : '' : ' field < $x AND';
> $Query = qq{ SELECT FROM ... WHERE $whereCond ...};
I think if you specify WHERE you need a clause.
'SELECT foo FROM bar WHERE' doesn't make sense.
my @c = qw( = > < );
$x = 60;
foreach my $cond (40 <=> $x,60 <=> $x,80 <=> $x) {
$query = qq{ SELECT ... FROM ... WHERE field $c[$cond] $x };
print "$query\n";
}
Even less to type. Maybe not all *that* clear, but no less than ?:, ?::,
and ?:?: all meaning different things.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: as long as we are discussing 'nice to have's...
On Monday 23 July 2001 14:05, Dave Storrs wrote: > No, I do not mean something like Devel::DProf; that is a > module. I mean something that is in the core binary, the same way that > the perl debugger is in the core binary. Except that the perl debugger is not in the perl binary. There are hooks in the binary that a program may use for debugging, profiling, and such. perl -d simply invokes one of those programs by default. In some sense, these hooks could simply be replaced by the previously mentioned (BEGIN|END) (BLOCK|STATEMENT) structure - since that is mainly what they are. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: my $howmany=wantarray; while($howmany--){push @R,onemore};
On Saturday 02 June 2001 11:21 am, Bryan C. Warnock wrote: > On Friday 01 June 2001 11:06 pm, David L. Nicol wrote: > > having wantarray return the number of items needed, or -1 for > > all of them, would work very nicely for user-written partial returners. > > > > Did anyone RFC that? > > RFC 21's expectation counts, I believe. > (Except it's ~0 vice -1 for all items.) On a side note, I was having difficulty finding an RFC yesterday as well, so I put together this rough index. Once I clean it up and verify the categories, I'll see if Ask can hang it off the main RFC page. (Some of the categories are still fairly hefty, I'm afraid. But 40 is better than 340.) Arrays, Lists, and Slices 21 Subroutines: Replace C with a generic C function 24 Data types: Semi-finite (lazy) lists 37 Positional Return Lists Considered Harmful 51 Angle brackets should accept filenames and lists 52 List context return from filesystem functions 81 Lazily evaluated list generation functions 82 Arrays: Apply operators element-wise in a list context 90 Arrays: merge() and unmerge() 91 Arrays: part and flatten 94 Rename @ARGV to @ARGS 105 Remove "In string @ must be \@" fatal error 109 Less line noise - let's get rid of @% 118 lvalue subs: parameters, explicit assignment, and wantarray() changes 134 Alternative array and hash slicing 148 Arrays: Add reshape() for multi-dimensional array reshaping 151 Merge C<$!>, C<$^E>, C<$@> and C<$?> 152 Replace invocant in @_ with self() builtin 166 Alternative lists and quoting of things 169 Proposed syntax for matrix element access and slicing. 175 Add C keyword to force list context (like C) 177 A Natural Syntax Extension For Chained References (aka Multidimensional Arrays/Hashes) 179 More functions from set theory to manipulate arrays 186 Standard support for opening i/o handles on scalars and arrays-of-scalars 202 Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207) 203 Arrays: Notation for declaring and creating arrays 204 Arrays: Use list reference for multidimensional array access 205 Arrays: New operator ';' for creating array slices 206 Arrays: @#arr for getting the dimensions of an array 207 Arrays: Efficient Array Loops 212 Make length(@array) work 231 Data: Multi-dimensional arrays/hashes and slices 238 length(@ary) deserves a warning 268 Keyed arrays 272 Arrays: transpose() 282 Open-ended slices 283 C in array context should return a histogram 299 C<@STACK> - a modifyable C 344 Elements of @_ should be read-only by default 360 Allow multiply matched groups in regexes to return a listref of all matches Building and Development 46 Use features of portable, free compilers and libraries 50 BiDirectional Support in PERL 55 Compilation: Remove requirement for final true value in require-d and do-ed files 61 Interfaces for linking C objects into perlsubs 121 linkable output mode 141 This Is The Last Major Revision 160 Function-call named parameters (with compiler optimizations) 172 Precompiled Perl scripts. 184 Perl should support an interactive mode. 210 Data/Binary Dumping and Freezing 225 Data: Superpositions 227 Extend the window to turn on taint mode 281 The Perl 6 Development Log 287 Improve Perl Persistance 292 Extensions to the perl debugger 297 Attributes for compiler hints 301 Cache byte-compiled programs and modules 304 C algorithm to be selectable at compile time 305 C<$^C> should be true when compiling 314 A parser is a many-layered thing Comments, POD, and documentation 5 Multiline Comments for Perl. 11 Examples encoded with =also for|begin|end POD commands 44 Bring Documentation Closer To Whatever It Documents 65 Add change bar functionality to pod 79 The Predefined POD Streams are C, C, and C 102 Inline Comments for Perl. 176 subroutine / generic entity documentation 216 POD should tolerate white space. 217 POD needs a reorder command. 240 Form a documentation working group to edit, clean, and produce documentation 280 Tweak POD's CEE 286 Add a "emit pod" runtime option to Perl 306 User-definable POD handling 325 POD and comments handling in perl 357 Perl should use XML for documentation instead of POD Context 21 Subroutines: Replace C with a generic C function 45 C<||> and C<&&> should propagate result context to both sides 52 List context return from filesystem functions 82 Arrays: Apply operators element-wise in a list context 98 context-based method overloading 118 lvalue subs: parameters, explicit assignment, and wantarray() changes 128 Subroutines: Extend subroutine contexts to include name parameters and lazy arguments 175 Add C keyword to force list context (like C) 226 Selective interpolation in single quotish context. 259 Builtins : Make use of hashref context
Re: my $howmany=wantarray; while($howmany--){push @R,onemore};
On Friday 01 June 2001 11:06 pm, David L. Nicol wrote: > having wantarray return the number of items needed, or -1 for > all of them, would work very nicely for user-written partial returners. > > Did anyone RFC that? RFC 21's expectation counts, I believe. (Except it's ~0 vice -1 for all items.) -- Bryan C. Warnock [EMAIL PROTECTED]
Parsing perl > 6.0
Jumping the gun a little
With the pluggable parser architecture, would it be a Good/Bad/Ugly Thing to
freeze the parser itself after each Perl release?
One of the omnipresent arguments against any change is how it affects legacy.
Although Perl 6[.0] is a recognizable departure from Perl 5.x syntax, so have
been Perl 5.x from Perl 5.(x-1) and will be Perl 6.x from Perl 6.(x-1), if
only to a lesser extent.
Perl 6 is planning on addressing the bulk of the Perl 5 legacy issue with a
pluggable parser capable of parsing Perl 5.n. Why not do the same thing in
the future with minor revs?
Currently, with each release, the parser is extended/fixed/modified in place
with the development of the next version. Instead, why not freeze the parser
in place at each release, and then use it as a jumping off point for the next
parser? The frozen parser could then be CPANned as a legacy parser.
Bennies:
- Guaranteed language basis for the future. Code written explicitly for Perl
6.0 will be parsed according to Perl 6.0 rules.(1) Code written generically
for perl can easily be "rolled back" if the next version of Perl breaks some
reliance on the older parsing rules.
- Fits within the "mix and match" module munging that is being planned. Perl
6.0 code could potentially interface with Perl 7.0 modules/packages/classes,
and vice versa.
- By definition, doesn't need to be maintained.(2) Once it's frozen, it's
frozen. This is behavior that people expect, however intentional or not the
behavior actually is. Er, was.
Troublespots:
- (1) Parsing would be consistant, but obviously runtime behavior could still
change, depending, for instance, on whether the parse-tree optimizer would be
coupled with the parser or with the underlying architecture. Future
optimizers may subtly change the behavior of a legacy parse-tree. This is
the same issue that will plague "compiled" code, so it needs to be addressed
somehow anyway.
- (2) Obviously, opcode deletion (or something similar) may require the
parser's output to be changed.
- Who wants umpteen different perl parsers lying around their code base?
Other impacts:
- C semantics would have to be changed. Or whatever the parser
identifier will be. You'll need to differentiate between an exact match and
a minimum match.
use perl 6.0;
use >= perl 6.0; # or use perl >= 6.0?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
On Tuesday 15 May 2001 21:17, Simon Cozens wrote: > On Tue, May 15, 2001 at 09:11:21PM -0400, Bryan C. Warnock wrote: > > What? You didn't test it before you posted it? For shame! ;-) > > Bah. Damian and I are working on ways of prototyping the Perl 6 > interpreter in Perl 5 for testing. We have the variable semantics sorted > out, but properties might be a little more difficult. my $surprise is zero; -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
On Tuesday 15 May 2001 21:07, Damian Conway wrote: > John Siracusa wrote: >> Okay, this part has me confused. > > And rightly so: it was a screw-up. I lost track of whether I was keeping > the property on the value or on the node reference and ended up doing > both. What? You didn't test it before you posted it? For shame! ;-) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: what I meant about hungarian notation
On Wednesday 09 May 2001 10:44, David Grove wrote:
> I used to request hungarian notation from programmers who worked for me,
> until I saw the actual compliance with that request culminate in a local
> variable named l_st_uliI. Of course, that's an "static unsigned int i"
> used as a simple iterator in local scope. Of course, written more
> appropriately, this would have just been "static unsigned int i". At that
> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
> much confusion as MicroSoft's redefinition of C, with thousands of
> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the
> most common).
Not mention the hoop-jumping required to keep variable names in sync with
code changes. (signed-ness, short->int->long, etc)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Apoc2 - concerns
On Saturday 05 May 2001 19:28, Uri Guttman wrote: > the proposed qh only fails with a key or value of => which is highly > unlikely and can be worked around as a value by inserting another => > > %foo = qh( foo bar => => baz ) > > is: > > %foo = ( foo => 1, bar => '=>', baz => 1 ) Or it could be %foo = ( foo => 1, bar => 1, '=>' => 'baz' ) But I like the concept of a quote hash. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Dot can DWIM without whitespace
On Wednesday 25 April 2001 21:37, Edward Peschko wrote: > > '.' is already, to some extent, space sensitive anyway, because it > > has to pull double duty as a decimal point, as well. > > > > '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator) > > beautiful. Then extending this is simple, consistent, easy to read, > compatible with perl5.. I'm not sure that that was the point I was trying to make. If nothing else, the '.' would then be responsible for *three* different actions. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Dot can DWIM without whitespace
On Wednesday 25 April 2001 18:33, Edward Peschko wrote: > On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote: > > On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote: > > > IMHO, . can DWIM in most cases even if it's both object deref > > > _and_ concat--without paying any attention to whitespace. > > > > Please, no. Some of us have to *teach* this language. > > Then I guess that either space sensitive '.' is the answer, or '_'. I > personally prefer the space sensitive '.' because it is compatible > with perl5, and I think people would have less difficulty with it > even if it was doing double duty in the language. And its visually > easy to spot the difference between the two constructs. '.' is already, to some extent, space sensitive anyway, because it has to pull double duty as a decimal point, as well. '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Schwartzian transforms
Since I'm supposed to be summarizing this thread for Simon's weekly write-up,
let me make sure I have the four(?) basic suggestions/stances.
1) There are too many variations/problems/issues to bother having Perl try to
handle them all. If folks want an optimized sort, they should continue to
use the ST, or roll something similar.
2) Perl should create some form of special syntax explicitly for doing an ST
on data. (Other than the special syntax of the ST, of course.)
3) Perl should provide a general memoization mechanism, usable outside sort,
but that could be used to get ST-like behavior from a regular sort routine.
sort { f'($a) f''($b) &| ... &| f``($a) f`($b) } @list; or
sort { $a->f' $b->f'' &| ... &| $a->f`` $b->f` } @list;
Each value in list would have the results for f() cached for subsequent
comparisons within the sort. This would eliminate the need for the ST.
4) Should should grok a sort as an ST.
sort { f'($a) f''($b) &| ... &| f``($a) f`($b) } @list; or
sort { $a->f' $b->f'' &| ... &| $a->f`` $b->f` } @list;
Perl should see this and think aha!
map { $_->[0] }
sort { $a->[1] $b->[2] &| ... &| $a->[-2] $b->[-1] }
map { [$_, f'($_), f''($_), ... , f``($_), f`($_)] } @list;
Did I grossly miss anyone's position?
On Wednesday 28 March 2001 15:02, Dan Sugalski wrote:
> At 11:59 AM 3/28/2001 -0500, John Porter wrote:
> >Dan Sugalski wrote:
> > >...
> > > subs inside the sort sub are called" then life becomes much easier.
> >
> >Easier for perl. Don't we want to make life easier for the programmer?
> >I mean, in general, it would be nice if there were a way to have
> >perl memoize for us, rather than have to arrange it ourself.
> >It could benefit a lot of situations besides sorting.
>
> I'm not talking about making it easier on perl so much as making it faster.
> Basically to give us the wiggle room to recognize some simple constructs
> like
>
> foo($a) <=> bar($b)
>
> or
>
> foo($a) cmp bar($b)
>
> and optimize them to a table build and sort. This would work for plain perl
> data structures as well, as we might potentially be doing a fair amount of
> data conversion through the variable vtable interface. (Not to mention the
> issues of data mangling for proper Unicode sorting support)
>
> Dan
>
> --"it's like this"---
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Schwartzian transforms
On Wednesday 28 March 2001 11:47, Dan Sugalski wrote: > At 11:22 AM 3/28/2001 -0500, John Porter wrote: > >Dan Sugalski wrote: > > > It doesn't really matter if the functions inside the sort function are > > > idempotent--what matters is whether it's OK for us to go and memoize > > > the things (or whatever else we might choose to do) > > > >Exactly, that's what I've been trying to say. > >And that's why I propose the :constant/:function/:pure/:stateless > >attribute, so that perl only has to trust the programmer to say > >which functions can be memoized. > > I'm actually considering whether we even need to care what the programmer's > said. If we can just flat-out say "We may optimize your sort function, and > we make no guarantees as to the number of times tied data is fetched or > subs inside the sort sub are called" then life becomes much easier. > But you can't. A complex sort can currently by simplified, if desired. To invert the behavior (simplification first), you'd still need a way to recomplexify it, for the folks who need a fetch every time. > Of course, we may not be able to say that, in which case hints of any sort > are a Good Thing. Yes. One way or t'other. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 22:03, Edward Peschko wrote: > > I *like* the interpretation of undef as 0 and "". It's useful. Sometimes. > > Sometimes it's not. And that's fine. > > No that's NOT fine. It leads to 'find the needle in the haystack' sort of > problems. If you get 1450 'use of undef value' errors, they are all useless. > > If you get 10 of them, and you know that the only time you are going to get > 'use of undef value' errors, they are very valuable. And how valuable they > are grows as the size of your project increases. > > > There's no reason in the world why that should replace undef -> 0 and "". > > See above. > > > > Or how about "I'm feeling particularly lazy today, I think I'll sleep in. > > Lets > > > worry about any mistakes I might make another day." > > > > Well, Laziness is One of the Three. > > Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by > default, because warnings and strict are great teaching tools. > > > Let me rephrase. > > Perl shouldn't bitch at me for valid perl. > > '-q'. None of that is the point. I don't disagree that having loads of warnings are a good thing. I don't disagree that having strict parsing rules, variable declarations, and the ilk are a good thing. There is no technical reason why warnings and strictness can't be the default. You with me so far? Everything you have said is perfectly valid, and if we were designing a brand-spanking new language, I might be arguing *for* you. But we're not, we're tweaking Perl. Perl, remember that language? The language that advertised all the above laziness? That the above laziness was part of its drawing power? This isn't an addition to the language that you're talking about - it's changing some of the fundamental behavior of the language. It's saying that no longer is Perl a loose, powerful language - oh, you want B&D? well, we can do that for you too - but rather that Perl is just another conventional programming language, (although if you flip this switch, you'll get its old, horrible behavior.) Sure, it will be easier to learn - it had better be, because *e-v-e-r-y-o-n-e* is going to have to learn it. Again. Look, most folks are probably sick of us going round and around about this, so I'll sum up my position. 1. There is no technical reason why warnings and strict can't be on by default, why undef must be able to promote to 0 or "", or just about any other feature a computer language can have. No technical reason. It may break some things, but those things can be fixed in their own right. 2. There are many non-technical reasons not to change codified behavior. This is why the last serious revamp of English spelling and grammar rules were aborted by the publication of the dictionary, why Americans adamantly refuse any doings with the metric system (except the 2 liter bottle), and why sports fans hate the instant replay. To change what some consider the philosophical essence of Perl is akin to a bait-and-switch, and I, for one, would feel cheated, (and if you'll allow me to wax melodramatic, betrayed). 3. While the argument is internal to us, I will remain steadfast in my stance against any arbitrary, widespread reversal of the language. 4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo these radical changes, I will, to the best of my meager abilities, attempt to implement them. My position may seem a bit extreme - after all, didn't I, in the second RFC, attempt to autoprint statements in a void context? I started in the middle of the road, but as arguments like this have continued, I've moved wy to the minimalist's side. Hey, overhaul Perl to your heart's content so that you're able to do x, y, and z; just so long as Perl itself doesn't do x, y, and z. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 16:03, John Porter wrote: > Bryan C. Warnock wrote: > > > > And there's a difference between warnings originating because something has > > gone wrong and those originating because I'm doing something particularly > > perlish. Unfortunately, -w doesn't (and probably can't) tell the > > difference. > > Can you give me an example of the former? > I can't think of any off the top of my head. Scalar value @foo[$bar] better written as $foo[$bar], for one. (But you probably would have thought of that if I had said something better than "something has gone wrong" which doesn't describe the above at all. I'm sorry, a completely horrible phrasing of what I was trying to say - I'll take me out back and shoot me now.) I'll try this again - the difference between a perceived user error, and a misused perl construct. The above error reflects an inability to distinguish between mulitple typos: either $foo or a list index. If part of Perl's breeding is autovivication and interpretation of undef as 0 or "" in the appropriate context, why should Perl bitch at me if I use it as such? Why should I have to ask permission to do so? I would rather say, and I think it would be more perlish to say, "I'm not feeling particularly perly today, can you check for anything clever, cause if there is, chances are it's a mistake." -- Bryan C. Warnock [EMAIL PROTECTED]
