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 AE 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 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 Cmy bool $y = (0 but true) 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? Cmy bool $y = (0 but true) 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: 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 AE'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 AE'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 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: 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 roundascii is implemented as a character class, as opposed to (say) an alternation? What's the difference? :) Neglecting internals, semantically what Iis 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 Cinitializer isn't going to be expecting a closure,
and Credo would bypass the NEXT, and there's no loop there to
Credo, 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: 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: 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: 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 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: [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 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 Cmy contained within them. It's
the implicit {} that was protecting the Cif condition from getting
a warning like the Celsif got (which got the warning because it's
at the same scope level as Cif's declaration).
But the flies are spontaneously generating! ;-)
--
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 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: 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]
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]
Apoc4: Parentheses
QUOTE
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.)
/QUOTE
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: 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: '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]
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]
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: [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: 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 Cuse Exporter().
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: 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: 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 = $bx4; $a = $b x 4;
if ($one foo || $o nefoo) # if ($one foo); if ($o ne foo) ; if (${o}nefoo)
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: 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: 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: 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: 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: 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{option value=$_} = '/option'), @ary;
That's not really joining.
or is better to stay like this :
my $select;
map { $select .= qq{option value=$_$_/option} } @ary;
Definitely.
--
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 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?
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 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]
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: 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]
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: 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 09:09 pm, Damian Conway wrote: A Cwhen is a statement, just as an Cif or a Cwhile 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 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: 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: 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 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
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: 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]
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: 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]
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]
LangSpec: Statements and Blocks
. 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: 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]
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, 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]
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]
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]
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: 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]
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: 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: 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 Cwantarray with a generic Cwant 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 Clist keyword to force list context (like Cscalar) 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 Ctr/// in array context should return a histogram 299 C@STACK - a modifyable Ccaller() 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 Csort 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 Cperl, Cdata, and Cdoc 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 CEltEgt 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 Cwantarray with a generic Cwant 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 Clist keyword to force list context (like Cscalar) 226 Selective interpolation in single quotish context. 259 Builtins : Make use of hashref context for garrulous builtins 283 Ctr/// in array context should return a histogram 285 Lazy Input / Context-sensitive
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: - Cuse 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: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: 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: Apoc2 - STDIN 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 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: 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: 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 GWBrecomplexify/GWB 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: 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) cmp f''($b) | ... | f``($a) cmp f`($b) } @list; or
sort { $a-f' cmp $b-f'' | ... | $a-f`` cmp $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) cmp f''($b) | ... | f``($a) cmp f`($b) } @list; or
sort { $a-f' cmp $b-f'' | ... | $a-f`` cmp $b-f` } @list;
Perl should see this and think aha!
map { $_-[0] }
sort { $a-[1] cmp $b-[2] | ... | $a-[-2] cmp $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: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 14:45, Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Yep; the perl manpage has said, since time immemorial, that | the fact that -w was not on by default is a BUG. I don't know that I would say time immemorial. It wasn't in the man for 4.036. I can only find man pages back to 5.002 right now, so I can't check any earlier than that in the 5 tree. However, it was meant to be (more than) slightly tongue-in-cheek. 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. sidetrack A friend of mine was attempting to install some commercial program (a DD character generator, IIRC) on a Windows box - one that didn't have a sound card. It wouldn't run. It always crashed while trying to talk to the sound card. He procured someone else's laptop to do a demo install, and it ran fine - there are open and close window sound effects, and this voice-over guy that gives instructions. The first instruction given in the setup box? If you'd like to turn off the voice, click this box. Nothing else is sound dependent. Somehow I think there's a lesson to be learned here. /sidetrack -- 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]
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 BD? 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: Closures and default lexical-scope for subs
On Friday 16 February 2001 09:24, Branden wrote: I said: Anyway, I don't see why `local' (and `our' and `my') should bind more strongly than , and = . Because the implicit global scope declarator binds that tightly. Because you lose the ability to mix scope declarators in an assigment. (my $a, $b, local $,, my $c) = @_; I suppose the counter argument is you could then write that as (my($a),our($b),local($,),my($c)) = @_; Surely that would then allow (my $a, $b, $c) = @_; to be the same as my ($a,$b,$c) = @_; Oh, wait, commas are now implicitly parenthesized, so that (my $a, $b, $c) = @_; can be written as my $a, $b, $c = @_; That's going to affect some compound expressions, but those can easily be fixed by liberal uses of the 'scalar' operator, er, function, er, term. Oh, wait. That also doesn't behave quite right. That can also be tweaked, I'm sure. But what does that give you? You've now taken several existing behaviors of the language and completely changed it for no *net* improvement to the language. (Okay, that may be subjective, but feel free to argue how what you've added significantly outweighs a) what you've changed, and b) the fact that you changed it.) Now, admittedly, I've not done very much language design, but even in generic software design: - you think hard before adding functionality, and that added functionality had better provide a net improvement to the product, - you think even harder before removing functionality, and that the removal of functionality had better provide a larger net improvement to the product, - you do a complete brain drain before changing existing functionality, and that change had better provide a huge net improvement to the product, - you don't make any of these decisions arbitrarily. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Friday 16 February 2001 11:20, Branden wrote: proposal. I don't think it works, because $a, $b, $c = @_;# $c gets 10 for @_=(1..10) mean a different thing that my $a, $b, $c = @_; # $c gets 3 for @_=(1..10) It does? The last code should behave as my $a, $b, ($c = @_); It doesn't? ie. $a, $b and $c are lexicals, and @_ is assigned to $c in scalar context. I'm sure I posted this example a while ago. It didn't make sense then, either. Are you saying you wish to declare three lexical variables ($a and $b in void context, and $c to be the scalar value of @_?) `my' DWIMs. But DWYM ne DWIM ne DWEM ne DWMPM ne DWSPM. This solution is like trying to solve the world's financial problems by taking the richest guy's wealth and distributing it among everyone else. It doesn't solve anything, it just redistributes the problem. I know this is bad for who already writes Perl code. Then why is it being discussed? But it would be very good for who learns Perl and doesn't understand exactly when he should and when he should not put parenthesis around `my's list of variables. Then maybe the documentation should be improved. Maybe makng a clearer delineation and how and why and when these work are in order. Particularly once attributes come out in full force, which will also bind more tightly than , or =. Simply offloading and compounding the problem isn't a viable solution. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Friday 16 February 2001 11:38, Branden wrote: (my($a),our($b),local($,),my($c)) = @_; What is it, anyway? A joke? (There's Perl poetry, why can't be there Perl jokes?) Who writes this kind of code anyway? Okay, you caught me, it was a contrived exampled. The actual code was (my($foo),local($"),our($bar),my($baz)) = @_; ;-) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thursday 15 February 2001 19:21, Edward Peschko wrote: How many times have I wanted to put 'use strict' in a module and forgotten about it? Then it isn't, technically, a perl problem. How many times have I wanted to use '-w' but was not able to because of all the junk that comes out of it? That also, technically, isn't a perl problem. Make it by default and a large portion of the problem is solved. Define "large portion" and "the problem." If you get really used to -q, then it rolls off the fingertips: '/usr/local/bin/perl -q'. If you really get used to "use strict;", then it rolls off the fingertips, too. of course, but they will fix a large part of them. You'd be amazed how many errors will be caught with 'use strict' and 'use warnings'... You'd be amazed how many errors *aren't* caught with strict and warnings. If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check But we don't want to check for '-w' and 'use strict'. We want to leave that up to the module owner. All I want is a clear policy towards warnings and strict. Thats a hell of a lot easier to achieve with something proactive. What can be more proactive than "Your code should work."? As for '-T', well, some modules don't *want* to be run in '-T' mode. Why not? Evvery module should handle untainted data, just in case, right? That is potentially far more dangerous than using a global in the wrong package, no? In my experience, its always been the proactive policies which work the best. Reactive policies have lots of shortcomings and are hard to set up. Which is easier to do - prevent a fire or put one out after its started? Well, speaking from experience, put one out. There are an unbelievable number of ways a fire can start, a lot of them unforeseeable. But most fires themselves fall into a half-dozen classes, with fairly standard firefighting techniques. And the more I think about it, you cannot make the project you describe proactive - ie: we will not accept your module *until* conditions x,y,z occur - this would be too onerous to accept for module developers. So you want to force people to adhere to strict rules, but it would be too onerous to force them to adhere to strict rules? (Personally, I don't care about the extra warnings, as long as I can shut them up. That doesn't really change perl's behavior. Forced strictness does.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Sunday 11 February 2001 19:08, Jan Dubois wrote: However, I couldn't solve the problem of "deterministic destruction behavior": Currently Perl will call DESTROY on any object as soon as the last reference to it goes out of scope. This becomes important if the object own scarce external resources (e.g. file handles or database connections) that are only freed during DESTROY. Postponing DESTROY until an indeterminate time in the future can lead to program failures due to resource exhaustion. But doesn't resource exhaustion usually trigger garbage collection and resource reallocation? (Not that this addresses the remainder of your post.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Garbage collection
crossed to -internals Jan Dubois: Not necessarily; you would have to implement it that way: When you try to open a file and you don't succeed, you run the garbage collector and try again. But what happens in the case of XS code: some external library tries to open a file and gets a failure. How would it trigger a GC in the Perl internals? It wouldn't know a thing that it had been embedded in a Perl app. But that would be the point of the API, no? Even in XS, you'd interface through perl for memory or file management. So the core would still be able to invoke the GC. Granted, these are last-ditch efforts anyway - what would really be needed to trigger? E[MN]FILE? ENOMEM? Weird cases of ENOSPC? If you happen to hit one, force a GC pass, and retry whatever the call was. Even if the GC is unsuccessful (at resource reclamation), wouldn't you still want Perl to panic, vice the XS code anyway? This scheme would only work if *all* resources including memory and garbage collection are handled by the OS (or at least by a virtual machine like JVM or .NET runtime). But this still doesn't solve the destruction order problem. Well, no. My thought would be if A needed to be destroyed before B, then B wouldn't/shouldn't be marked for GC until after A was destroyed. It might take several sweeps to clean an entire dependency tree, unfortunately. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re:
On Wednesday 31 December 1969 18:59, Branden wrote: Yes. Packaging is what's important. I actually expect to not have to install the `par' and have perl6's magic filehandles decompress a file from the package `on-the-fly'. I think zip is the way to go! Is there any platform/license or any other restricting issues we should care about zip? Is it ported to all platforms Perl currently runs on? Is there a Perl module for handling zips? I've always handled this by slapping the .tgz package into the DATA section of a perl script that DWIMs. Sort of a self-executable zip file. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: [FWP] sorting text in human-order
On Fri, 05 Jan 2001, Piers Cawley wrote: But, but... 0.21 is *not* 'point twenty one', it's 'point two one', otherwise you get into weirdness with: .21 and .210 being spoken as 'point twenty one' and 'point two hundred (?:and)? ten' and all of a sudden the '2' in that figure has gained an order of magnitude which is just plain *wrong*. Then it would be "one eight zero zero point two one." Yes, at least the U.S. used to teach that the gratuitous use of "and" was wrong - "one thousand eight hundred twenty-one," but the rules have been loosened for integer numbers. One thousand eight hundred twenty-one. One thousand eight hundred and twenty-one Eighteen hundred and twenty-one. One thousand eight hundred and twenty-one hundredths. One thousand eight hundred and two million, one hundred thousand ten millionths. How did we get on this subject? Oh, yes, sorting by the number spelled out... That should throw several cultures for a loop. Four and twenty blackbirds, baked 'e' and 'pi'. Ghod knows how this GST would have you pronounce 5.6.0, 'five and six and oh'? The computer kulture has its own rules for written and spoken grammar. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Expunge use English from Perl?
On Wed, 27 Sep 2000, Nathan Wiger wrote: Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 361 (v1) Simplifying split()
On Sun, 01 Oct 2000, Sean M. Burke wrote:
If you want to remove trailing fields, under Perl 6 you should have to
do it explicitly:
Perl 5: @x = split /:/, $bar;
be synonymous with
Perl 6: @x = split ':', $bar;
while(@x and !length $x[-1]) { pop @x }
Which, to me, is a good reason to keep the current behavior.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Fri, 22 Sep 2000, Glenn Linderman wrote: In my opinion, which you probably will also not agree with, attempting to toggle between the current undef semantics and tristate semantics is like trying to stuff three values into one bit. This comment assumes that the current undef is implemented by a bit in a variable structure; when the bit is in one state, it means the value is undef, and when the bit is in the other state, it means the value is not undef. If this is what you're assuming, no wonder there's a disconnect. Explore overloading. I think it's where you're likely to find your solution. (Particularly with vtables behind them.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins
On Wed, 20 Sep 2000, Damian Conway wrote: This RFC proposes the builtin functions that return a large number of values in an array context should also detect hashref contexts (see RFC 21) and return their data in a kinder, gentler format. You may want to add a reference to the various existing modules that provide this type of interface. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: IDEA: my() extensions and attribute declarations
On Wed, 20 Sep 2000, Nathan Wiger wrote: my int ($x, $y), char $z; # mix classes my int ($x, $y) :64bit, char $z :long; # and attrs nit my (int ($x, $y), char $z); my (int ($x, $y) :64bit, char $z :long); /nit -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 100 (v2) Embed full URI support into Perl
On Sun, 17 Sep 2000, Nathan Wiger wrote: The only comments received were on my crappy examples, which have been clarified. Well, sort of. More comments on "crappy" examples. :-) The key syntax benefit is #1. This lets us use URIs in any function to allow scripts that can be used on many platforms simultaneously: $fo = open 'C:\docs\private'; # non-portable $fo = open 'file://C|/docs/private';# portable unlink "/local/etc/script.conf";# non-portable unlink "file:///local/etc/script.conf"; # portable If portability is not a concern, then scripts can be written using the familiar, native syntax. Otherwise, all Perl funcs should be able to accept URIs so that writing portable programs is simple. Many asked "Hey, how are those two any more portable? The drive letter is still in there." Good point. I would argue that this is where Perl should DWIM. For example, if a script doing this: There's a big difference between construct-portable and content-portable. Content-portable is, IMHO, not Perl's responsibility. We only need to address construct-portable. Given that, the above are still "crappy" examples because you're trying to address both. It detracts from the actual idea you're proposing. (As you may have noticed from several posts. Michael Schwern's recent post on the subject is a good example.) I'd rather see you drop (or footnote) the discussion of how the various systems are going to map content among themselves, and focus more on what the construct allows. For instance, returning to some of the original implementation ideas, that the location information be passed to the protocol handler, which will then DWIM, as determined by the platform, protocol, etc, etc. Getting DOS and Unix to look at a portable construct. Sure. Needed, one way or another. Getting them to Do The Right Thing based a single, uberportable input string just ain't gonna happen, so I'd address that either separately (with the file:// implementation) or not at all. One of the big draws (to me) for URI support isn't even mentioned in the RFC, although it was discussed following v1, and that is adding DWIMmery to the open to support more than files and pipes. (We recently added URI support to one of our projects for this reason.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 - Request For New Pragma: Shell
On Wed, 13 Sep 2000, Michael G Schwern wrote: Sooo... what happens to the existing Shell.pm? The RFC title notwithstanding, the pragma would be, by convention, lowercase. (As reflected in the abstract.) Of course, should language features be added to allow scoping to be easily controlled, it could also be just as easily rolled in, although I think that might be counter-intuitive. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 - Request For New Pragma: Shell
On Wed, 13 Sep 2000, Michael G Schwern wrote: ...many good points, all of which I should have known. :-( I will modify the RFC to reflect that /\bshell\b/i is a poor name, due to the current Shell module. Personally, I don't particularly care what it's called - after all, I don't name things very meaningful anyway, now do I? All I care about is the underlying functionality. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 2 (v3) Request For New Pragma: Implicit
On Wed, 30 Aug 2000, Michael Maraist wrote: Good idea, but you have it backwards.. If anything, there should be an "explicit" keyword.. Remember, we want % perl -p -e 's/foo/bar/g' file.txt Oh, I know. I threw it in because someone mentioned wanting to turn it off. (There may have been some confusion in the default settings. The implicit arg would be 'on' by default. To turn it off would require: no implict arg; Use could then turn it back on again.) Trust me, I've no desire of removing the features that won me over in the first place. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, 24 Aug 2000, Nathan Torkington wrote: You'd obviously want to have a module that collected together your favourite new operators. But if they were lexically scoped, they'd be lexically scoped to the module they were defined in, i.e. your collection rather than your main program. We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Not that it adds much information, but this is the lament of RFC 40. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
On Wed, 23 Aug 2000, Buddha Buck wrote: Perhaps someone should RFC the new special variable ME, which is predefined to be the whole program. Who knows? Perhaps it would then make sense to use @_ at the top level, as if the program was invoked as "ME(@ARGV);"... Doesn't a lot of OO work (esp. on the Mac) tend to do this? The first thing they do in their application is instantiate an application (mainly, itself, without the application instantiation) and run it. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: ... as a term
On Wed, 23 Aug 2000, Bart Lateur wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) "The world"? This problem only exists in English! We pronounce it something similar to "way way way". I, personally, prefer the Stoogian "Whoop whoop whoop!" Although it's hard to stop at three. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFCs (Re: Ideas that need RFCs?)
On Fri, 18 Aug 2000, David L. Nicol wrote: There will Be No Perl7 Of course not. Odd numbers are the development releases. The next Perl after 6 will be 8. Seriously, while a worthwhile goal, this is rather short-sighted. The industry and the world will continue to change in spite (or because!) of our efforts here. We can make it easier for the users to adapt, but Perl will need to continue to evolve, as well. (As spoken by a one-eyebrow, knuckle-dragging Neanderthal) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Language WG report, August 16th 2000
On Wed, 16 Aug 2000, [EMAIL PROTECTED] wrote: The language group has generated the vast majority of the 100+ RFCs in existence, and is suffering under the deluge of 100-200 posts a day. I would prefer this to be down around 50, but no luck yet :-/ Part of the problem seems to be timezone related... the lag time between an RFC being posted, me seeing the thread and realising the need for a sublist, and Ask actually creating that list, means that you get 2-3 days of traffic before it can be moved elsewhere, and a single RFC can easily generate 50 posts. I think that all this... Several sublists have been spawned, but we're not sure how successful they are yet. They seem to have low traffic, which could mean that they simply aren't working (because nobody wants to use them), or that they *are* working (because the people previously discussing the subject on -language weren't deeply interested and just joining in for the hell of it, and the sublists scare off the dilletantes). I think that an NNTP interface would be *seriously* useful to the sublists. ... is the cause for this. All the discussion is taking place in the master list before the sublists are spawned. You can only express the opinion that foo is not bar and never should be so many times. (To be fair, I collapse my lists, and don't pay attention to what is posted to what list.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, 14 Aug 2000, Nathan Wiger wrote:
1. time() would still return UNIX epoch time. However, it
would not be in core, and would not be the primary
timekeeping method. It would be in Time::Local for
compatibility (along with localtime and gmtime).
2. mjdate() would return MJD. It _would_ be in core, and
it _would_ be the internal timekeeping method. All
of the new date functions would be designed to be based
off of it.
So, just to clarify:
1. The Perl 5 way in Perl 6:
use Time::Local;
$date = localtime time();
2. The Perl 6 native way:
$date = date mjdate();
Now, are we talking about the new default/de facto standard that the
users are being presented with? Or are we talking about the true
internal structure? ("and it _would_ be the internal timekeeping
method.")
I don't have an OS that reports time in MJD. It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.
For example:
# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;
Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally. This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime? Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?
(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)
I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
This all seems like a lot of work for (what I would consider to be) the common, default case - wanting to open a file native to my OS, on a filesystem seen by my OS. Or am I clue-lossy again? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
To nick some pits On Fri, 11 Aug 2000, Nathan Wiger wrote: Here is the justification. As most people write dates, they write something like this: 1/20/1976 2:34:02 4/5/981 11:05:09 Very few people I've met write dates like this habitually in the real world: 01/20/1976 02:34:02 04/05/0981 11:05:09 And I've never seen anyone write this: 1/20/1976 2:34:2 4/5/981 11:5:9 Notice that the hours/mins are always padded but the rest isn't. I think you meant minutes/seconds. If you're writing a program that uses the date as an actual date (and not as a file suffix, for example), you'll probably want to present what people are used to seeing, in this case the first one. And if you want a s/people/your audience/; file suffix, use what I suggested in the RFC: $backup_suffix = date time, '%Y%m%d%H%M%S'; Which would return something like "20001104120309". I've gone back and forth about this. I ultimately think that the above approach will end up with date() being more usable in more situations, even though it seems a little inconsistent. I think it returns what people want, it's just that people are inconsistent. I would say that various pockets of people are inconsistent with other pockets. Remember, localtime is already a very consistent interface from a lot of aspects, but it is horribly unusable because it doesn't return stuff in the form you want it. Nothing returns stuff in the form I want. That's why I use Perl. ;-) As long as this transformation remains simple, and the strftime interface is simple enough, I don't care what the interface is. Although, (and this may have already been mentioned/suggested/accepted/rejected), if you're going to have an object interface, perhaps the constructor can take the strftime string for use as the default scalar output? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 69 (v3) Standardize input record separator (for
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
Given this input file:
D O S CR LF0044 004F 0053 000D 000A
U n i x LF0055 006E 0069 0078 000A
M a c CR 004D 0061 0063 000D
l i n e LS006C 0069 006E 0065 2028
p a r a PS0070 0061 0072 0061 2029
l i n e006C 0069 006E 0065
This should work as expected on as many platforms as possible:
my @lines = FH;
The @lines array should contain six elements.
Well, if _I_ have an input file like the above, it most likely isn't
text.
Bart Lateur has suggested differentiating between ASCII-compatible
and UTF-16. Perhaps a flag?
Yes, that's how things are currently implemented in Perl 5, I believe
Nick said. (Well, not like you have impemented. Internally, per
string.)
open FOO... # syntax to follow, but assume an ASCII file
@foo = FOO; # Each string in @foo is flagged ASCII.
open BAR... # assume utf-16
@bar = BAR; # Each string in @bar is flagged utf-16.
@baz = map { $foo[$_] . $bar[$_] } ( 0 .. 10 );
# the first eleven lines of @foo are "promoted" to utf-16,
# the concatenation done, and stored to @baz, which is
# flagged utf-16.
open OUT_ASCII... # Open for writing ascii;
open OUT_UTF32... # open for writing utf-32;
print OUT_ASCII @baz; # Either an error, or data truncation. :(
print OUT_UTF32 @baz; # promotes all strings to utf-32 and writes them
The binmode function should treat data as binary and not translate
line disciplines. (No one objects to this so far?)
binmode should be a line discipline itself.
Whether $/ will remain in Perl 6 is uncertain, so this is not
necessarily about $/.
Agreed.
Bart Lateur suggested using a dedicated DFA regex engine.
Which was a good suggestion. My impression of line-disciplines as how
they would/could be used is to handle the splitting of an input string,
much as split would. split takes a regex, why not the $/ equivalent?
(Other than not knowing what to put back in a -l type context.)
Two major questions from me, I guess.
Aren't line disciplines mainly going to be emulated? IOW, would Perl
"line disciplines" necessary map 1-1 and onto sfio line disciplines?
I think of line disciplines as hints to open, or , actually, for how
to process the data. From this perspective, they could follow the
standard line discipline syntax of :foo, or use something as simple as
a Perl hash, and would not necessarily be limited to the open call.
(This is all a wag, don't take it as gospel.)
So you'd potentially have hints like so:
:bin
:text
:text=ascii
:text=utf8
:text=utf32
:text=ebcdic
:text=some_weird_proprietary_format
:block=size
:line=
:line=dos
:line=mac
:line=unix
:line=/like, you know?/
:mod=chomp
:mod=split
:mod=\do_some_funky_pre_processing
That would allow you to do stuff like the following.
open FOO, "foo_file", :text=ascii, :line=unix, :mod=chomp;
while (FOO)
{
# $_ = an ascii line, delimited to \n, but without the \n;
}
open FOO, "foo_file", :bin, :block=1024;
while (FOO)
{
# Now $_ is a block of 1024. Easy read. (I know,
# I know, what about eof()?
}
open FOO, "foo_file", :text, :line;
# Sample the input stream and make a best guess
$text_mode = taste FOO, "text";
$line_mode = taste FOO, "line";
spank FOO, text = $text_mode, line = $line_mode;
while (FOO)
{
# Reads with the right disciplines now
}
open FOO, "frozen_foo", :bin;
spank FOO, block = 48, mod = \thaw_struct;
while (FOO)
{
# Do something with the object that is $_
}
--
Bryan C. Warnock
([EMAIL PROTECTED])
