Re: PRE-POST methods [Was: Selective exporting of properties/methods]
[EMAIL PROTECTED] writes:
: ]- I can't remember but i think I read somewhere or it was discussed here (can't
:remember), but I think it was mentioned that Perl6 will have PRE and POST method/sub
:handlers probably specified as attribute, so that (syntax may be wrong):
:
: class XXX {
: method blah is PRE {}
: method blah {}
: method blah is POST {}
: }
:
: is ok.. not sure about the FALSE-condition that prohnobit the blah-method-call ?
Might just be a PRE and POST block within the method blah.
: One more thing I was wondering would it be possible to define a method/sub with
:different signatures but with the same name ? ( i think yes, ?Class::Multimethods?!
:was doing that aren't it ?)
I'm intending to allow overloading to the extent that the type system
supports it. I foresee that the main difficulty will be knowing the
the types on the caller end, not on the definition end.
: PS. One thing just pooped to me... is the class { } a block so that we can do all
:block mumbo-jumbo with it :)
Well, sure, but it probably only executes inline with the surrounding
code, just as any module initialization code does in Perl 5. I don't
think it's a BEGIN variant.
Larry
Re: Why not {,n} in quantifiers?
Trey Harris writes:
: One of the little bugaboos that got me a lot my first N years of doing
: Perl was that {m,} is a quantifier meaning m or more, but {,n} is *not*
: a quantifier meaning up to n. People like symmetry, and it seems
: logical that {,n} would DWIM, but it doesn't. I still make the mistake on
: occassion.
:
: I can only think of one reason to disallow it (unless there's a parsing
: issue somewhere that I can't immediately see): some people might expect
: DWIM behavior to be implicit M=0, and others might expect M=1. But I
: honestly don't see that as compelling--if you read {m,} as m or more,
: and {,n} as n or less, then I think M should clearly default to 0.
:
: Is there something I'm missing here? If not, why not add some DWIMiness
: and make {,n} work?
It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe we'll
have something like this:
Perl 5 Perl 6
{1,3} 1..3
{3} 3
{3,}3+
{0,3} 3-
Then again, maybe not...
Larry
Re: Why not {,n} in quantifiers?
Aaron Sherman writes:
: Hopefully there will be some replacement. I can't count the number of
: times I've relied on things like:
:
: $b = qr/\d{1,3}/;
: if (ip = ($addr =~ /($b)\.($b)\.($b)\.($b)/)) {
: die $0: \$addr\: bad IP\n if grep {$_255} ip;
: print(0x,(map {sprintf %02x, $_} ip),\n);
: } else {
: die $0: \$addr\ is not an IP address\n;
: }
:
: It would be a shame to loose that.
Bear in mind we have to translate Perl 5 to Perl 6, so it's quite unlikely
that we would drop the general case. The only question here is what it
ought to look like in the general re-huffmanization of regexen.
Larry
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
Aaron Sherman writes: : Should a tied and/or lazy array be forced to present a length on demand, : or can length return undef on indeterminate arrays? An array implementation can return anything it jolly well pleases, but I'd say undef would be a reasonable thing to return if the length is indeterminate. Then you can at least get warnings if you try to use the undefined value later. The class could even tag the undef with a property containing an unthrown exception that explains why the length is indeterminate, since Perl 6 will support interesting values of undef. Larry
Re: Why not {,n} in quantifiers?
Miko O'Sullivan writes:
: From: Larry Wall [EMAIL PROTECTED]
: It's unlikely that {n,m} will still have that meaning in Perl 6. Maybe
: we'll
: have something like this:
:
: Perl 5 Perl 6
: {1,3} 1..3
: {3} 3
: {3,} 3+
: {0,3} 3-
:
: What are your feelings on multiple ranges for matches? E.g. the following
: expression means 1 to 3, 5, or 10 or more:
:
: 1..3|5|10+
My feelings are that nobody has ever asked me for it before, so it's
not something worth making special syntax for. On the other hand, if
instead of inventing new syntax we stick to a more Perlish syntax, we
could generalize it to an ordinary slice kind of list:
1..3,5,10..Inf
But you'd still have the complexity of making it work, and it still
seems like something almost nobody would ever use. And you could get
the same effect with an appropriate assertion:
(...)* { @$+.length =~ (1..3,5,10..Inf) or fail }
That's assuming that quantified captures produce arrays rather than
the final match as Perl 5 does.
Larry
Re: Perl6 currying
Angel Faus writes:
: Hi,
:
: I was reading Damian's new excellent diary entry in which he explains the
: new currying syntax for Perl6.
:
: (For the lazy ones it's reachable at
: http://www.yetanother.org/damian/diary_latest.html)
:
: This new feature allows to partially fill place-holder functions, such as:
:
: my div = {$^x / $^y};
:
: my half= div(y=2};
: print half(6); # 3
:
: This is a very neat feature, and very useful, as it's explained very well on
: Damian's page.
:
: But I am not sure I like the syntax. The problems I see are:
:
: - You only can curry placeholder-generated functions. So if you intend to
: make a function curryiable, you are forced to use place-holders, even if
: that's not the cleanest way of programming it.
I think that if you use an explicit signature, the declared variable
$^a is really just $a, so you wouldn't have to have arrows all over
the body of your function.
: - This means that the creator of a function needs to impose a policy on
: whether he expects the function users to use currying or not. A module
: creator and user could have different point of views about it, creating
: unnecessary conflict between the human race.
Well, yes, as I've been telling people (and as you point out below), we
need the policy anyway if we're going to support defaults. But yes,
there could certainly be difference of opinion between the creater and
the usor.
: - From the caller point of view, the only distinction between a function
: call and a currying pseudo-call, is the number of parameters.
:
:div(6,3) # is a function call
:div(6)# creates a new curryied function
:
: So, in order to see if a expression is a function call or a magic currying,
: you need to count (!) the number of parameters, without any visual clue
: suggesting it.
:
: - You cannot use advanced perl 6 features (like optional strict typing, or
: default values for function parameters), on curryiable functions.
There is the additional problem that you have a function returning a
completely different type (unrelated to its declared return type, if
any) depending on the argument count.
: I would instead propose that every function object supports a curry
: method, that performs such operation.
:
: For example:
:
: sub div($x,$y) {$x / $y}; # of div = {$^x / $^y}
:
: my half = div.curry(y=2);
: print half(6); # 3
:
: This solves the unnecessary placeholder-currying marriage, and it is
: certainly a more explicit syntax.
Yes, I've been wondering myself whether there ought to be some way
for the caller to override the prefs of the declaration with respect
to currying. Though it's possible that there's some overhead in making
any function curriable, since you essentially have to keep the original
template around in order to instantiantiate it whichever way. Imagine
if every function in C++ were really a generic on every parameter...
: Incidentally, a newbie user would learn that there is a curry method being
: called, and could google curry perl and even find some useful docs.
:
: (In my humble opinion, this is something that is too many times forgotten in
: the perl world. With the ultra-compact, idiomatic syntax, it is __very__
: hard to learn perl the google way).
I think that's a very valid point. I lucked out by naming Perl with
a word that wasn't a word. It's harder to search for Ruby.
: What do you think about it?
My one quibble with your proposal is that I think we still need
self-declaring, self-ordering parameters, and it could be argued that
if they exist they might as well curry automatically. Though perhaps
good style would dictate use of the curry method anyway. Certainly it
can also be argued that currying is not going to happen often enough in
stock Perl that it needs that ultimate in Huffman coding, the null
operator.
If we're going to make it a method, however, it's possible that curry
is the wrong popular name, despite its being the correct technical name.
There's really nothing about the word curry that suggest partial
binding to the casual reader. Perhaps we really want something like:
my half = div.prebind(y = 2);
or:
my half = div.rewrite(y = 2);
or even:
my half = div.assume(y = 2);
I think I like that last one the best. Maybe it would read better as
assuming. But that's getting a bit long for Mr Huffman. Maybe it's
finally time to reach into our bag of English topicalizers and pull out
with:
my half = div.with(y = 2);
Larry
Re: Perl6 currying
3uke Palmer writes: : Perhaps if it's generated with placeholders, the C.curry would be : implicit. That way we can stay terse when the situation is simple. Like : with Damian's Cgiven...Cwhen example. When I'm writing scripts, I : don't want to type those 6 characters, but if I'm doing structured : programming, the clearer the better. To parallel this, when I'm writing : scripts, I'm going to use placeholder functions, but in structured : programming, I'm probably not. I don't think the switch example is actually currying. It's really just using a self-declared parameter, which the switch statement is smart enough to feed the proper other argument to. Offhand I don't see a generalization of it that would let us pass in fancier curries usefully--it's got to resolve to a function that has a boolean result. What would a switch (or a C=~ for that matter) do with a two-argument curry? And is that red, yellow, or green curry? Larry
Re: Accessor methods ?
Aaron Sherman writes: : Alternately, I think we should be able to mark subs as 'final' or 'inline' : to indicate our guarantee that they won't be modified. Of course, it'll : conflict with auto memoizing or auto currying modules that'd want to : override it, but that's their fault. :) : : Yes, I suggested inline or const I can't imagine that we would : want to do without this, regardless of what we call it. Otherwise, : auto-accessors will always be slower than using the variable. Would : everyone agree that this property should default to being set for : auto-accessors? No, that would undo the whole point of making them accessors in the first place. : And even though distributed .pbc files and seperate compilation are some : goals of perl6, I still think we're okay. If we inline a function in : module A, and module A changes, Perl6 should ensure that the original : version is still loaded for our code, and thus our inlining should still : be valid. : : Oh, that one's easy (I think/hope/pray). : : There're three stages: : : 1. compile time -- When a module or program is byte-coded : 2. load time -- When byte-code is loaded off of disk : 3. run time -- When the program begins to execute : : There are complexities, but you get the idea. Load time, I assume is : also when BEGIN executes. Actually, BEGIN has to execute at compile time. INIT runs between load time and run time. : In this model, you only ever inline at load time ***OR*** when the : compiler is attempting to produce a self-contained byte-code executable : (e.g. one which has all of the modules in it), in which case it executes : that part of the load time process early. If you like, call this a : sub-stage of load time, which I shall dub link time. Link time can : only happen once per program, so it must happen when we actually know : what all of the program components are. It seems like an assumption that link time can only happen once. An incremental linker might feel like it can relink any time it feels like it. Some very useful programs never completely know what their components are. : Any other way of doing this would seem to me to be a very dangerous : weapon to brandish so close to so many unsuspecting feet. :-( We've never shied away from issuing people enough rope. But I don't think that has to be the case here. We'll likely have an inline property. : Another avenue is that of self-modifying code. I know it would break : threads, or cause code duplication between threads, but when A changes, we : can either re-inline the new subroutine, or eliminate the 'if-else' check : to avoid the branch we know will be false from then on. Creating code : which optimizes itself as it's run based upon internal profiling would be : cool. But that's the topic of a different thread. :) : : Code that does this by changing sub references should still work. Code : that does this by changing its own internal representation gets what it : paid for. But methods don't have a unique sub ref until you know the type. One could inline a jump table of sub refs based on known types, and default to ordinary method lookup for unknown types. But there's no guarantee that would actually be faster than a decent vtable lookup. Larry
Re: Using closures for regex control
Me writes:
: [modified repost due to warnock's dilemma]
:
: Would something like these DWIM?
:
: # match pat1 _ pat2 and capture pat2 match:
: / pat1 { ($foo) = / pat2 / } /
Yes, though I think we'll see people doing it more like this:
/ pat1 ( pat2 ) { $foo = $-1 } /
We might allow something like
/ pat1 $foo=( pat2 ) /
as a shorthand for that. But in the general case, the closure can
put the value anywhere, and this will be particularly important for
building parse trees.
: # match pat1 _ 'foo bar':
: / pat1 { 'foo bar' } /
Probably not. I can think of several other good uses for return values
from inner closures, such as building a parse tree. But at the moment
I'm thinking that the return value will be ignored. If so, {'foo bar'}
might be the way to inline comments in place of (?#foo bar).
: # match pat2 if not pat1
: / { ! /pat1/ } pat2 } /
Same issue. You can always write / { /pat1/ or fail } pat2 /. I don't
think the return of the closure will be interpreted as a boolean.
Closures will be used for side effects, and I'd hate to see a lot of
closures ending in a cryptic C0;. It's better to make the assertions
explicit. Could even have a unary fail unless operator:
/ { assert /pat1/ } pat2 } /
There might be a better word than assert.
: # match pat2 if pat1 behind
: / { .lookbehind /pat1/ } pat2 } /
Sure, presuming .lookbehind knows how to fail. But after: pat1 is
much more readable, I think.
Larry
Re: Backslashes
Luke Palmer writes:
: I'm sort of side-tracking from the trend of discussions, but I was just
: thinking that I always found it annoying how you had to double backslashes
: in single-quoted strings. I like the bash's behavior with regard to this
: much better... I mean, the whole idea behind single-quoted strings is that
: there are no escape sequences. If someone really needs to put a single
: quote in a single-quoted strings, what's wrong with this?:
:
: 'You think I' _ q{'} _ 'm knit-picking!'
:
: The analagous holds for q{} sequences. Furthermore, here documents don't
: mimic this behavior:
: print 'EOT'
: Foo\\bar
: EOT
:
: Print's precisely Foo\\bar. So are we doing something about this?
Well, if anything, we're going the other direction, and enriching what
you can do with a backslash in single quotes slightly. But it ought
to be pretty easy to define your own hyperquotes. We might also have
options on quotes like we do on regexen. Then we could tell it what
to interpolate and what not to:
q:bsahfmc/\t $foo array %hash func() $obj.method() { closure }/
'Course, that's pretty klunky. So maybe we have something like an
immediate subroutine definition:
my sub qa is quote(bsahfmc) {...}
qa/\t $foo array %hash func() $obj.method() { closure }/
Then you could say something like:
my sub q is quote() {...}
'You think I' _ q{'} _ 'm knit-picking!'
to get the behavior you want.
Larry
Re: Using closures for regex control
Me writes:
: : Would something like these DWIM?
: :
: : # match pat1 _ pat2 and capture pat2 match:
: : / pat1 { ($foo) = / pat2 / } /
:
: Yes
:
: So a match in a closure starts where the outer match
: was. Simple enough.
:
: Will:
:
: # match pat1 _ pat2 _ pat3 and capture pat2 match:
: / pat1 { ($foo) = / pat2 / } pat3 /
:
: work?
As long as they're all working off of the same regex state, I
don't see why not. Except that you'd better have a () in
pat2 to capture something, if we keep the same rules as Perl 5.
: I don't think the return of the closure will be interpreted as
: [a string to be matched or a boolean success indicator or
: indeed anything, at least not something that the regex
: pays attention to]. Closures will be used for side effects,
: and I'd hate to see a lot of closures ending in a cryptic C0;.
:
: Right.
:
: Here's a thought, no need to respond just yet:
: Perhaps the regex could look to see if the return
: value has one of a set of properties. If it does not,
: the regex ignores the return value. Otherwise it
: uses the value in accord with the property:
:
: # match pat1 _ 'foo bar':
: / pat1 { 'foo bar' is pat } /
:
: Not exactly a compelling example, but the point is
: this might be an appropriate way for closure return
: values to participate in regex matching operation.
I don't see why you can't just use $('foo bar') for that. Or
$('foo bar') if you really want a pattern and not a string.
: Aiui, one has regular perl code (not regex) read
: access to what is *matched by* a parens, but not
: write access to the *matching of* a parens.
:
: So, one can do:
:
: / pat1 ( pat2 ) { $foo = $-1 } /
:
: to read the value, but not
:
: # made up, no thought applied, syntax
: # match pat1 _ pat2 _ pat2
: / pat1 { .match 2 } ( pat2 ) /
:
: where .match is followed by an expression that
: applies some control to the next parens. I'm out
: of my depth here, but can you see what I'm trying
: to get to? To see how far one can have closures,
: and hence regular perl syntax, take on regex
: control duties.
The entire state of the regex match is potentially available via the
topic object. The only question is what the object is willing to
let you modify (and whether there's a better syntax already).
To answer the deeper question, yes, it's probably possible to run the
entire control structure using nothing but closures. We could also
change Perl's syntax to use nothing but parens, but we're not gonna. :-)
Larry
Re: Perl6 currying
We've pretty much settled on div.prebind(y = 2) as the most informative and least conflictive. Larry
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Dave Mitchell: : (Please CC me on replies) : : Actually, now I come to think of it, please don't CC on replies. One thing I : really hated about Perl 6 was the number of people sniping from the sidelines : providing no useful contribution. And now I've become one. Urgh. Don't stress. Whenever I see someone sniping from the sidelines, I take it as a clue that I haven't communicated well enough. : One word: CPAN. : : I understand this argument, but it is bogus, and doesn't address my point. : Either we're breaking backwards compatibility and doing something very new, or : we're seeking to retain compatibility with the past. Which is it to be? Whenever someone asks Which is it to be?, I always suspect they're setting up a false dichotomy. In this case, you're ignoring a very real engineering issue, which is migration strategy. Your question is posed in the eternal present tense, but this is a temporal issue. When they're building a new interchange on an interstate highway, they don't tear down the old one and then put up the new one. The traffic has to keep flowing. So over the course of time there will be various odd temporary roads that take you through and around the construction area, and you're always afraid the temporary scaffolding is going to come down on your head. But eventually the scaffolding does come down, and what's left is all concrete, and nobody remembers how the old road went. When DEC first invented the VAX, they put in an emulation of PDP-11 assembly language, because they knew it would take time for people to migrate. Eventually the emulation went away. Anyway, you seem to be saying that two features of Perl 5 scaffolding will ruin Perl 6. I think you haven't really thought about migration strategy long enough. : Yes, there's a lot of legacy crap out there. Much of the important parts of it : are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go : through the CPAN argument: : : * Allowing CPAN code to be run in Perl 6 tantamounts to legitimizing its : use. In what sense does Perl 6 de-legitimize Perl 5 code? Perl 5 is as legitimate as it is. Perl 6 neither adds to nor takes anything away from that. Perl 6 may be better, but only if you have the Perl 6 code to run. We have to get there from here, and there has to be gentle but relentless pressure to migrate, but if Perl 6 really is better, that pressure will be there. Treating Perl 5 programs (and by extension, Perl 5 programmers) as illigitimate is not going to speed up the process. : * Legitimizing the legacy code means it'll never get ported to Perl 6 No, requiring everyone to translate everything all at once means nothing will get ported. Open source projects only know how to do things piecemeal. They don't know how to do things all at once. : * Producing Perl 5 results in a Perl 6 world may not make much sense : anyway. Don't understand what you're saying there. Data is data, and most results aren't either Perl 5 or Perl 6 results. They're just data. : * Subtle differences between P5 usage and P6 usage would give module : authors a support nightmare. Once you have a working P6 module, you can throw away the P5 module, or at least treat it as no-longer-supported. : * Some of those authors may not know about or want to support a Perl 6 : use of their module anyway. (Thank you for your bug report, but it : appears to be written in a different language.) Dinosaurs happen. But eventually they evolve into birds. : * Digging a pit for module authors to fall into considered unfriendly. Yeah, but we're using the extra dirt to raise a mountain for them to climb. The capacity for greater good always comes with the capacity for greater evil. : * It's still a backwards compatibility sop. Perl 4 libraries had to be : rewritten for Perl 5. I don't see why Perl 5 libraries should escape. Perl 5 libraries do have to be rewritten (or translated) for Perl 6. But that will only happen if Parrot can emulate Perl 5 long enough for people to climb each rung of the ladder one step at a time. Most people can't leap tall buildings in a single bound. Larry
Re: Half measures all round
On Tue, 4 Jun 2002, Simon Cozens wrote: : Steve Simmons: : We have said that perl5 will be *mostly* mechanically translatable into : perl6. : : And we shall keep saying this until we believe that it is true? No, we'll keep saying this until we make it true. Faith without works is dead. Larry
Re: Half measures all round
On Tue, 4 Jun 2002, Dave Mitchell wrote: Having said that, I have real, real doubts that Perl 6 will ever be able to execute Perl 5 code natively. Its not just a case a writing a new parser and some P5-specific ops; P5 has so many special features, boundary conditions and pecularies, that to get P6 to execute P5 is a task equivalent to reimplementing P5 from scratch. I'm wondering if instead, we continue to maintain the P5 src tree, and embed P5 within P6 (embed in the sense of Apache and Mod_perl). Sick and ugly, but maybe more practical than the alternatives. It also means that the P6 src doesn't have to be saddled with knowing (much) about P5. Eventually of course the P5 bit would have to be thrown away. That's exactly what I've been arguing for all along. Grr And that's why I see the package hack and the new :p5 modifier as having the weight of two features, not the weight of an entire re-implementation of Perl 5. It's really not that difficult to run two interpreters in the same process. I already made Perl and Java run together nicely. If anything the impedence mismatch between Perl 5 and Perl 6 will be even less. Scaffolding is supposed to be ugly. You wouldn't believe how ugly the transitional form between Perl 4 and Perl 5 was, when half the opcodes were interpreted by the old stacked interpreter, and half by the new stackless one. Larry
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, John Siracusa wrote: : On 6/4/02 12:22 PM, David Wheeler wrote: : I think that if we can agree to forego backwards compatibility, we might : also be in a better position to set up a CP6AN with much better quality : control. All of the most important modules will be ported very quickly : (e.g., the DBI), and a lot of the cruft will be left to die (at least from : the Perl 6 perspective). : : Speaking of CPAN for Perl 6 (or CP6AN, or 6PAN), what's the status of : this effort? Do we even have a vague idea of the requirements? Or does : everyone think CPAN (and module distribution/installation in general) as it : exists now it pretty much okay, and just needs some tweaks to work with Perl : 6 code? I really hope that's not the case! :) I haven't gotten to that Apocalypse yet. :-) : In the spirit of Simon's desire to see radical changes when appropriate, I : propose the following high-level goals for 6PAN (yes, that's my favorite of : the bunch ;) : : 1. Multiple versions of the same module may be installed on a single system : with no possibility of conflicts. That means no conflicts of any kind, : whether it be in Perl code, XS-ish stuff, private shared libs, etc. Yes, I'm already on record that multiple installed versions will coexist peacably, certainly on disk, and to the extent that they can in memory. We can't stop two versions of a module from fighting over a shared resource, for instance. Two different database modules may have to figure out who really has the connection to the database engine, and who just thinks they have the connection. Possibly it would help to have package variables that are explicitly shared among different versions of the same package when they represent a shared object. : 2. Module packaging, expansion, and installation only requires a working : install of Perl 6 (unless the module contains non-Perl code, such as C, : etc., in which case the appropriate tools for C builds need to be present: : cc/gcc, ld, make, and so on). Requiring make and friends to install pure : perl files is a legacy relic, IMO. Certainly, though it's trivially easy to come up with something that's even uglier than make. Been done many times... : 3. Module removal should be as easy as installation. Fine. There ought to be something in the metadata that says, This version of this module hasn't been used since 2017. Then you can clear out the deadwood easily. Course, disk space will be a little cheaper by then, so maybe we'll just hang onto everything forever. : I can think of many other worthy high-level goals, but these are the most : important, IMO. And number one is by far the most important to me. A few : natural extensions of it are: : : 1a. Modules may be use-ed in several ways (syntax ignored for now): : : # Note ...installed on this system is implied at the end : # of each of the following descriptions : : Use the latest stable version of module Foo (probably the default) : Use the latest version of module Foo : Use the latest stable version of module Foo 1.xx : Use the latest version of module Foo 1.xx : Use module Foo 1.2 Yes, there have to be ways of getting at modules by their long names, their short names, and various intermediate wildcard names. Perl 6 will have to keep track of which version you used, so when you use the short name, it knows which long name you really mean. : 1b. 6PAN modules comply with an informal contract to maintain : backward-compatibility within all N.MM versions, where N is constant. In : other words, incompatible API changes are only allowed by incrementing the : major version (e.g. going from 1.xx to 2.xx), and upgrades from one minor : version to the next (e.g. 1.05 to 1.11) MUST be safe (i.e. : backward-compatible). Fine. We can separate out interface from implementation better in the language too. : 1c. Distinctions like alpha, beta, and stable need to be made : according to some convention (a la $VERSION...perhaps $STATUS?) Can probably burn that bridge when we get to it. : I don't think the implementation details are too hard to hash out (he says, : optimistically... ;) But to meet these goals, they have to be thought about : early on. Some of them even require hooks in the language proper (e.g. : use/require extensions.) Those are details, the like of which would be easy to determine at the last moment. But the underlying mechanisms have to be design in, yes. : Thoughts? Or has this stuff already been hashed out elsewhere and I missed : it? :) It's here and there. Some of it has been in my speeches, and some in the Apocalypses. Larry
Re: A5: Is this right?
On Thu, 6 Jun 2002, Buddha Buck wrote:
At 11:31 AM 06-06-2002 -0700, Brent Dax wrote:
I had gotten the impression that a literal string separated by whitespace
was an atom, so
rule foofoobar { foo 1,2 bar }
would match 'foobar' or 'foofoobar'. If so, I think !metachar needs to
be replaced by !metachar+
Nope, still gotta use [foo] if you want an atom larger than a character
(whatever a character is...)
Larry
Re: A5: Is this right?
On Fri, 7 Jun 2002, Damian Conway wrote:
Brent Dax wrote:
grammar Perl6::Regex {
rule metachar { [{(\[\])}:*+?\\|]}
rule ws { [[\h\v]|\#\N*]*}
Or just:
rule ws { [\s|\#\N*]* }
Just as a practical matter, given that you tend to have runs of
whitespace,
rule ws { [ \s+ | \#\N* ]* }
will probably run faster. At least, that would certainly run
faster with Perl 5's engine. Can't speak for Perl 6's, of course.
As a different kind of practical matter, if we put spaces around
our square brackets and vertical bars, it won't look so much like
a character class. I know we're all from the old school, but we
should therefore be even more alert against excessive regex
compaction.
Larry
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, David Wheeler wrote: I was hoping for a magic array that would hold the actual *matches*, rather than pointers to their character positions. A5 says that $0 is that array. Larry
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Dave Storrs wrote: Just to be sure I understood: you meant that (A) yes, you can use fail in a subroutine outside a regex, and (B) if you do, it is no different from die. Is that correct? Depends on the caller's use of use fatal. If they don't use fatal, it returns undef. Larry
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Peschko, Edward wrote:
: Let me get this straight. the grammar of Perl is reprogrammable,
: and expressed in perl6. And a script is parsed using this grammar,
: on the fly, hence portions of scripts could have different grammars
: than other parts.
Where have you been for the last two years? This is not news.
: So exactly how is this going to be fast? I'm assuming that perl
: gets its speed in parsing its own code by having the parser/lexer
: code written in C and compiled to machine code form - as I see it,
: there would be a lot of overhead in running any modifiable on-the-fly
: parser - wouldn't the parser itself have to be recompiled each time
: the script was being parsed, before any compilation pass was made?
No, the standard parser will be distributed as Parrot machine code.
This is a conventional language bootstrap on an unconventional machine.
: And if the syntax of the regex engine *itself* was being modified,
: wouldn't there have to be a 'source' regex engine that was used to
: parse the modified regex engine, bootstrap itself, and which then
: would be used to compile perl?
No, you're confusing the run-time engine with the parser. The regex
engine is Parrot itself, which is written in C. There is no separate
regex engine.
: And what's the deal with this caller(MY).parser stuff?
That indicates in the abstract that we're switching parsers for
the rest of the caller's lexical scope. Don't take the particular
notation too seriously. But it's fundamental to Perl 6 that
the mumble of
mumble { ... }
is allowed to have control of how the ... is parsed.
: Oh boy now I've gone and done it. *My* head's exploded.
If your head has exploded, you should avoid sausage factories.
Larry
Re: Apoc 5 questions/comments
On Mon, 10 Jun 2002, Dave Storrs wrote: I assume that 'fatal.pm' is a new pragma. Already exists for Perl 5, actually. 1) What (if anything) does it do, aside from turning 'fail' into a fatal exception when used outside a regex? What fatal currently does is wrap built-ins that might return undef with code that will die when undef is returned. I'm just generalizing that to having a keyword that fails in whatever way the calling context desires, whether by returning undef, throwing an exception, or backtracking the current regex. 2) Do you need to use it before you can (usefully) use 'fail' INSIDE a regex? (I would assume not, but thought I'd check.) No, it'll be built-in. You'll only need to invoke the pragma to change the defaults. Larry
RE: lex behavior
On Thu, 13 Jun 2002, David Whipp wrote: : Second, we should eliminate as much of the syntactic noise as possible: : : max b.*a b.*s : : would be nice -- with parenthesis, or the like, needed only when things : become ambiguous. I think, though am not sure, that having whitespace act as : an arglist separator in assertions makes it cleaner. There are definitely : strong counter-arguments. But I would like to minimize the clutter: and the : baseline is that alternation requires only one character. That would be problematic as a default rule. You wouldn't be able to write assertions like: before a | b To get more syntactic control would take something like a macro facility. But that has its own problems. Regexes will be tough to debug even without that. I think the biggest drawback is that it goes against the shiny new policy about (in)significant whitespace. On the other hand, it might be possible with regex introspection to dissect the alternatives of max b.*a | b.*s and evaluate them separately. But the most straightforward way to match longest is probably to use :any to get a superposition of matches, and then pull out the longest match. Perhaps there could be a :longest that does that internally, and could optimize away cases that couldn't possibly be longest. (And possibly even invoke a DFA optimizer to make it one pass, in the absence of internal captures.) Larry
Re: More 6PAN musings: local namespaces
On Tue, 18 Jun 2002, John Siracusa wrote: : On 6/18/02 6:10 PM, Damian Conway wrote: : Larry has previously mentioned the prospect of Perl 6 module names being : extended to include version number and author. : : If this were to be done, would seem reasonable for the author component to : simply be the author's CPAN username. These are guaranteed unique, are : frequently mnemonic, are necessary prerequisites for putting a module on the : CPAN in any case, and also map straight onto email addresses through which : authors can be contacted. : : That's fine for what it is, but I don't think it has the right granularity : for the problem I described in my original post. If Acme wants to create : custom Acme modules in-house and ensure that they will play well with : modules from anyplace else, they can't very well rely on a CPAN author name : to isolate their namespace. So they're back to making up their own : convention under Local:: (and risking conflicts with other companies that : try to do the same), or using Acme:: (whoops! CPAN conflict!), etc. I expect to end up with a multi-level system, where you can use anything from a DNS name (guaranteed to contain dots) through author IDs (no dots) to blessed top-level names for universally acclaimed modules, for some definition of universal. Plus the technological fix of aliasing, as several of you have discussed. Basically, we name interfaces at a more abstract level than we do implementations. Devil in the details, as usual... Larry
Re: Perl 6 Summary
Are you sure Ruby isn't just using dynamic variables? My information may be old, but that's all it seemed like to me. A certain amount of confusion naturally arises in the Ruby world because of the absence of explicit declaration, so the name binding rules get to be rather complicated. In fact, that's the basic underlying problem with Ruby, as far as I can tell. In pursuing the principle of least surprise, they've merely swept the surprises elsewhere. Waterbed theory of surprise, if you will... Larry
Re: Perl 6, The Good Parts Version
On Wed, 3 Jul 2002, Janek Schleicher wrote: : Trey Harris wrote at Wed, 03 Jul 2002 19:44:45 +0200: : : In a message dated Wed, 3 Jul 2002, Michael G Schwern writes: : Attributes : Transcending mere objects and classes, Perl 6 introduces adverbs. : : confused Attributes are adjectives, not adverbs. Aren't they? : : Attributes describe the behaviour of sub routines, I think. : As a sub routine is a Doing word - a verb, : I would say an attribute can be an adverb. When a sub is declared, it's just an object, and so any properties you apply to it at that point really are functioning as adjectives. Perl 6 will support adverbs, but that's just a way to pass additional arguments to something like the range operator. It really does modify the operation, not the operator. And it's syntactically distinguished from adjectives. Admittedly the concepts mush together in many natural languages. But please don't continue to call the adjectives attributes. They're properties now. We're reserving the term attribute for object instance variables. That is, attributes are formally defined per-class, whereas properties are defined per-object on an ad hoc basis. It will reduce confusion if we can keep those terms straight. It was a mistake to call what Perl 5 has attributes, because that's a standard industry term for instance variables. Larry
Re: Perl 6 Summary
On Wed, 3 Jul 2002, Ashley Winters wrote:
: Creepy. Here's my creepy thought for the day: is there a possibility for a
: prototype which would implicitly wrap a sub{} around a passed-in argument?
: i.e. lazy evaluation via sub prototype?
:
: sub check_it_out ($idx is rw, $val is rw) {
: $idx = 0;
: $val = 7;
: }
That'd have to be more like:
sub check_it_out (idx is rw, val is rw) {
idx() = 0;
val() = 7;
}
Note that that's almost a macro definition:
sub check_it_out is inline (idx is rw, val is rw) {
idx() = 0;
val() = 7;
}
That might not be enough info, though. May need to declare
the parameters to have no arguments:
sub check_it_out is inline (idx() is rw, val() is rw) {
idx() = 0;
val() = 7;
}
Larry
Re: what's new continued
On Wed, 3 Jul 2002, Damian Conway wrote:
: Date: Wed, 03 Jul 2002 19:33:33 -0400
: From: Damian Conway [EMAIL PROTECTED]
: To: [EMAIL PROTECTED] [EMAIL PROTECTED]
: Subject: Re: what's new continued
:
: Comments (otherwise you have things pretty much right):
I didn't see the original here.
: we can even have hyper-assignment :
:
: my ($a, $b) ^= new Foo;
:
: This is unlikely to do what you wanted. It creates a new Foo object and then
: assigns a reference to that one object to both $a and $b. It doesn't create two
: Foo objects. (But maybe one object referenced twice is what you wanted).
It *might* possibly work to hyper the constructor:
my ($a, $b) = ^new Foo
: 7.) Quantum superpositions ===
:
: if ($x == any($a, $b, $c) { ... }
The wave function of QS has not yet collapsed in Perl 6.
It's still in the same state(s) as the cat.
Larry
Re: greedy/non-greedy regex assertions
On Thu, 4 Jul 2002, Ashley Winters wrote:
: On Thursday 04 July 2002 10:47 am, Larry Wall wrote:
: On Thu, 4 Jul 2002, Ashley Winters wrote:
: So I'd guess that we just don't talk about :-1, but rather say that
:
: *$min..$max
:
: is naturally greedy, and as with any quantifier you write
:
: *$min..$max?
:
: to get minimal matching.
:
: I would expect /a*1..2?/ to mean /[a*1..2]?/ just looking at it. How can ?
: ever mean non-greedy unless it follows a metachar [*+?]?
Well, that's exactly how {1,2}? works in Perl 5, and {1,2} isn't a metacharacter.
It is, however, a quantifier.
In general, it makes no sense to put the quantifier ? after a zero-width
assertion. It'd mean Check this assertion but I don't care if it matches.
: But sigh, it would fix so many novice bugs to make minimal matching
: the default...
:
: I agree wholeheartedly. *sigh*
I wasn't seriously proposing it, of course, since it would instead
inspire a whole new set of novice bugs:
Gee, how come this:
my ($num) = /(\d*)/
always sets $num to zero?
We'll stick with greedy matching by default, and take our current
set of lumps...
Larry
Re: Ruby iterators and blocks (was: Perl 6 Summary)
On 4 Jul 2002, Erik [ISO-8859-1] Bågfors wrote: : On Thu, 2002-07-04 at 11:19, Andy Wardley wrote: : I personally believe this approach is flawed, especially considering the fact : that there is no way (that I know of) to force block parameters to be truly : lexically scoped or temporary (i.e. 'my' or 'local' in Perlspeak). Much too : easy to mangle existing variables like this. : : Most people agree. In the future there will be a way of doing that. : Matz himself has said so. Indeed, Ruby is the main reason I decided to keep my explicit in Perl 6. :-) Larry
Re: $RS paragraph mode going away?
On Fri, 5 Jul 2002, Trey Harris wrote:
: Did I hear somewhere that paragraph mode (i.e., C$/ = '') is going away?
: I can't find it in my archives, so maybe it was one of my feverish Perl 6
: dreams (of which I've had too many lately, after spending a few days in
: training with Damian ;-) but I think I heard it said by someone with
: authority at some point.
Paragraph mode is not going away--it's merely going elsewhere. :-)
: If so, what's the rationale? Another case of you can't do it right
: internationally, so better not to do it at all?
No, it's simply that using a global variable to control something
that should be a filehandle attribute is the wrong way to go about it.
: I'm just looking at the huge number of stanza-based files and
: system-utility output sysadmins deal with every day using C$/ = '', and
: thinking yeah, I could just write a grammar, but it's just a simple regex
: match in paragraph mode...
No problem, you'll just say something like:
$fh = open $filename, :para;
for $fh - $para { ... }
Eventually the Perl 5 folks will get around to implementing such
user-oriented layers in Perl 5, but at the moment they're still working
on the encoding-oriented layers, which is fine.
Likewise, you won't undefine $/ to slurp a file. You just put in
a :slurp layer:
$fh = open $filename, :slurp;
$text = $fh;
Of course, that's kind of silly. Really, when you want the entire
file, you should just use the slurp function:
$text = slurp $filename;
That's particularly handy on standard input:
$text = slurp $*IN;
It's kind of klunky to bind a mode to an existing handle:
mode $*IN: :slurp;
$text = $*IN;
I suppose that slurp with no arguments should slurp from ARGS.
Like Perl 5, it should probably slurp one file per, er, slurp,
rather than automatically concatenating all the files.
for slurp - $file { ... }
Larry
Re: Perl6 grammar (take IV)
On Sat, 6 Jul 2002, Trey Harris wrote:
: In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
: - Implicit currying variables ($^a etc) are in. I thought I had read
:somewhere they were gone in favor of closure args, but people seem
:to be using them, and they're not hard to put in.
:
: My understanding is that they still exist as placeholder variables, but
: no longer implicitly curry. I.e.,
:
: {$^a + $^b}
:
: is a synonym for
:
: - $a, $b {$a + $b}
That is correct. Currying will be done via some explicit method.
Sentiment at yapc favored something resembling:
incr := add.assuming(x = 1);
Larry
Re: Perl 6 Summary
On Sun, 7 Jul 2002, Thom Boyer wrote: : Has there been any indication whether those suggestions have met : with Larry's approval? There will certainly be support for that sort of thing in Parrot, up to and including continuations. Otherwise we cannot hope to host all these other languages. Exactly how Perl will make the interface known to its users is still up for grabs. Hopefully we can be specific enough that the compiler can figure out when it has to use continuations and when it can use some lighter mechanism. From a language design point of view, we want fancy control structures to just kind of sneak into people's consciences just as closures did in Perl 5. The capabilities should be there, but they should just work the way you expect when you get to having any expectations whatsover. It'd be really nice to find a way to explain continuations to people without inflicting the typical torturous explanations on people who aren't interested in brain pretzels. Perhaps we should just explain continuations in terms of time travel. Most people think they understand time travel, even when they don't. A continuation is just a funny label for a point in time, and you have a way of sending messages from the future back to that point in time. Another way of looking at it is that a continuation is a hypothesis about the future, and calling the continuation is a way of saying oops about that hypothesis. Basically, we need to find the right oversimplification to make people think they understand it. Kind of like cancelling the dx's and dy's in calculus--the physics profs always tell you to do that, while warning you not to tell the math profs they're telling you to do that, because it doesn't always work, except in real life. Larry
Re: Light ideas
On Fri, 2 Aug 2002, Nicholas Clark wrote:
: On Fri, Aug 02, 2002 at 08:53:51AM -0400, Trey Harris wrote:
: (With the possible exception of modules that disobey the laws of physics,
: but I'm not putting anything past Larry... no strict 'physics' ;)
:
: Yay!
:
: $ cat infinite_compression.pl
: #!/usr/local/bin/perl6
: use strict; # Hopefully this triggers the p5 to p6 convertor.
: use warnings;
: no strict 'physics';
: use Compress::SnakeOil;
:
: while my $infile (ARGV) {
: my $outfile = $infile.inf;
: compress_file (infile = $infile, outfile = $outfile, level = Infinite);
: die Problem compressing $infile to $outfile unless -z $outfile;
: }
: __END__
:
:
: I do hope that works. :-)
Infinite compression works great. Unfortunately, it's lossy.
And done right, it requires infinite time.
Larry
Re: 'while {' in Perl 6
On Fri, 9 Aug 2002, Adam Lopresto wrote:
: I was wondering whether the Perl 'while (){' idiom will continue to be
: supported in Perl 6? I seem to recall people posting example code the list
: using it (although I can't dig any up), but it seems to me that if Perl 6's
: lazy list implementation is sufficiently smart, it could just be replaced with
: 'for {'. The only issues I can see are people using inside the loop, and
: maybe something about the scope of $_. (Does a topicalized $_ change the value
: of $_ outside of the loop?)
Of the two constructs, I lean toward only making Cfor topicalize.
Possibly you can force an explicit topicalization on a Cwhile
like this:
while something() - $_ { ... }
(Had an interesting typo there. I put = insteaqd of -. I wonder
how much trouble that sort of thing is gonna cause. Maybe pairs
can be disallowed or warned about where a pointy sub might be
expected.)
Larry
Re: Copy-restore on parameters? (was Re: Autovivi)
On Thu, 15 Aug 2002, Deven T. Corzine wrote: : I've got another idea. How about using a copy-restore technique? I suspect that would make Perl 6's sub calls even slower than Perl 5's. Larry
RE: Balanced Matches in Regexps?
On Sat, 17 Aug 2002, Brent Dax wrote:
: Peter Behroozi:
: # After reading over Apocalypse 5 one more time, I noticed that
: # balanced matches (like capturing nested parenthetical
: # comments ((like this))) had been glossed over in the
: # rejection of RFC 145. What was not even mentioned in the
:
: rule parenthesized { \( ( -[()] | parenthesized ) \) }
:
: The key to balanced delimiters is recursion. A5 gives us convenient
: recursion; therefore, it gives us balanced delimiters.
That being said, there may well be a builtin self rule that refers
to the current rule without having to name it. That lets you write
anonymous recursive rules, or possibly a generic rule that could
have more than one name.
Larry
Re: Balanced Matches in Regexps? + tr and hashes
On 17 Aug 2002, Peter Behroozi wrote: : However, since you forced me to read through A5 again, I now have : another question :). Since we can now do : : $string.tr %hash; : : what happens when the keys of %hash have overlapping ranges by accident : or otherwise? Are there any other options than reporting an overlap : (hard), auto-sorting the key-value pairs (medium), or not allowing : hashes (easy)? Doing tr efficiently generally requires precompilation, so in the case of a hash, the compiled result would be stored as a run-time property. So we can really do whatever processing we want, on the assumption that the hash will change much less frequently than it gets used. Alternatively, we could restrict hashes to single character translations. But under UTF-8 that doesn't guarantee a constant string length (as measured in bytes). But I would guess that hashes would be used for even longer sequences of characters too, so some amount of preprocessing would be desirable to determine if one key was a prefix of another. Maybe it wants to get translated to some sort of trie parser. Really just depends on how much memory we want to throw at it to make it fast. Larry
Re: rule, rx and sub
On Mon, 26 Aug 2002, Glenn Linderman wrote: : Damian Conway wrote: : For an Crx without modifiers, (...) are certainly unambiguous as delimiters. : So I think they should be allowed. Of course, it's Larry's call and he may : well prefer the simplicity of a blanket prohibition. : : So one thing that bothers me in the whole discussion of rule vs rx : differences and similarities, is that there was a previous discussion : that said regular expression and regex should be deprecated terms : because the rules and patterns are no longer regular, but if rx isn't a : short form of regex, what is it a short form of? And if it is a short : form of regex, shouldn't it be deprecated too (respelled)? I'm enough of a linguist to know that we can tweak what people mean by regular expression, but there's no way on earth we can stop them from using the term. Ten years from now Friedl's book will still be called Mastering Regular Expressions, I suspect. So I'm taking a cue from Friedl, and encouraging use of the technical term regex as a way to not precisely mean regular expression. People who want to go further can use the term rule, at the risk of not being understood outside Perl circles. Larry
Re: Hypothetical synonyms
On 27 Aug 2002, Aaron Sherman wrote:
: I just wrote this code in Perl5:
:
: $stuff = (defined($1)?$1:$2) if /^\s*(?:(.*?)|(\S+))/;
:
: This is a common practice for me when I parse configuration and data
: files whose formats I define. It's nice to be able to quote fields that
: have spaces, and this is an easy way to parse the result.
:
: In Perl6, it looks like what I would like here is very close, but I'm
: not sure. Certainly, I could do:
:
: $stuff = ($1 // $2) if m{^\s*[(.*?)|(\S+)]};
:
: But I would far prefer:
:
: $stuff = $field if m{^\s*[
: (.*?) {let $field=$1} |
: (\S+) {let $field=$2}]};
:
: even though it's longer.
That seems like a lot of extra work. I'd prefer to see something like:
my stuff;
m{^\s*[
$stuff:=(.*?) |
$stuff:=(\S+)
]};
: Is this possible, or does the underlying implementation of hypothetical
: variables pretty much rule it out?
I don't see any particular reason why a top-level regex can't refer to
variables in the surrounding scope, either by default, or via a :modifier
of some sort. It's only down in the sub-rules that we have to make sure
there's a hash to poke such hypotheticals into.
Larry
Re: Hypothetical synonyms
On 27 Aug 2002, Uri Guttman wrote:
: LW == Larry Wall [EMAIL PROTECTED] writes:
: LW m{^\s*[
: LW $stuff:=(.*?) |
: LW $stuff:=(\S+)
: LW ]};
:
: couldn't that be reduced to:
:
: m{^\s* $stuff := [ (.*?) | (\S+) ] };
:
: the | will only return one of the grabbed chunks and the result of the
: [] group would be assigned to $stuff.
That too.
Larry
Re: Hypothetical synonyms
On 27 Aug 2002, Uri Guttman wrote: : and quoteline might even default to for its delim which would make : that line: : : my ($fields) = /(quotelike|\S+)/; That just looks like: my $field = /shellword/; Larry
Re: auto deserialization
On Wed, 28 Aug 2002, David Wheeler wrote:
: I have to agree with this. Ideally, IMO, there'd be some magic going on
: behind the scenes (maybe with a pragma?) that automatically typed
: variables so we wouldn't have to be so redundant, the code would look
: more like (most) Perl 5 OO stuff, and I'd save my tendonitis. What I
: mean (ignoring for the moment the even simpler syntax suggested earlier
: in this thread) is this:
:
:my $date = Date.new('June 25, 2002');
:
: Would automatically type C$date as a Date object.
Assignment is wrong for conferring compile-time properties, I think.
Maybe something more like:
my Date $date is new('June 25, 2002');
except that this implies the constructor args would be evaluated at
compile time. We need to suppress that somehow. We almost need some
kind of topicalization:
my Date $date = .new('June 25, 2002');
but I think that's taking topicalization a bit too far. The ordinary
way to suppress early evaluation is by defining a closure. I've argued
before for something like a topicalized closure property:
my Date $date is first { .init 'June 25, 2002' };
though first might be too early. The init should be inline with
the declaration, so maybe it's
my Date $date is now { .init 'June 25, 2002' };
That might be so common that we could make syntactic sugar for it:
my Date $date { .init 'June 25, 2002' };
That's evaluating the closure for a side effect. Or we could evaluate
it for its return value, factoring the init out into the implementation
of now, and just get:
my Date $date { 'June 25, 2002' };
Either way, this makes data declarations more like sub declarations
in syntax, though the semantics of what you do with the final closure
when are obviously different. That is, for ordinary data a bare {...}
is equivalent to is now, while for a subroutine definition it's more
like is on_demand.
Whatever. My coffee stream hasn't yet suppressed my stream of consciousness.
Larry
Re: Does ::: constrain the pattern engine implementation?
On Wed, 28 Aug 2002, Deven T. Corzine wrote: : I'm not saying we should dump the operators -- if we get more power by : assuming a backtracking implementation, maybe that's a worthwhile tradeoff. : : On the other hand, if we can keep the implementation possibilities more : open, that's always a worthwhile goal, even if we're not sure if or when : we'll ever take advantage of those possibilities, or if we even could... That is a worthy consideration, but expressiveness takes precedence over it in this case. DFAs are really only good for telling you *whether* and *where* a pattern matches as a whole. They are relatively useless for telling you *how* a pattern matches. For instance, a DFA can tell you that you have a valid computer program, but can't hand you back the syntax tree, because it has no way to decide between shifting and reducing. It has to do both simultaneously. : It seems like backtracking is a Bad Thing, in that it leads to reprocessing : data that we've already looked at. On the other hand, it seems to be a : Necessary Evil because of the memory costs of avoiding backtracking, and : because we might have to give up valuable features without backtracking. : : It may be that backreferences already demand backtracking. Or some other : feature might. I don't know; I haven't thought it through. I believe you are correct that backrefs require backtracking. Maybe some smart person will find a way to trace back through the states by which a DFA matched to retrieve backref info, but that's probably worth a PhD or two. Minimal matching is also difficult in a DFA, I suspect. : If we must have backtracking, so be it. But if that's a tradeoff we're : making for more expressive and powerful patterns, we should still at least : make that tradeoff with our eyes open. And if the tradeoff can be avoided, : that's even better. I refer you to http:://history.org/grandmother/teach/egg/suck. :-) That's a tradeoff I knowingly made in Perl 1. I saw that awk had a DFA implementation, and suffered for it as a useful tool. And it's not just the backrefs. An NFA can easily incorporate strategies such as Boyer-Moore, which actually skips looking at many of the characters, or the scream algorithm used by study, which can skip even more. All the DFAs I've seen have to look at every character, albeit only once. I suppose it's theoretically possible to compile to a Boyer-Moore-ish state machine, but I've never seen it done. Add to that the fact that most real-life patterns don't generally do much backtracking, because they're written to succeed, not to fail. This pattern never backtracks, for instance: my ($num) = /^Items: (\d+)/; I'm not against applying a DFA implementation where it's useful and practical, but just because it's the best in some limited theoretical framework doesn't cut it for me. Humans do a great deal of backtracking in real life, once the limits of their parallel pattern matching circuits are exceeded. Even in language we often have to reparse sentences that are garden pathological. Why should computers be exempt? :-) Larry
Re: Does ::: constrain the pattern engine implementation?
On Wed, 28 Aug 2002, Deven T. Corzine wrote: : I'd like to do that, if I can find the time. It would be interesting to : make a small experimental prototype to see if DFA construction could really : improve performance over backtracking, but it would probably need to be a : very restricted subset of regex operations to test the idea... That'd be cool. : However, while I'm still on perl6-language, I have two language issues to : discuss first: : : (1) Can we have a :study modifier in Perl 6 for patterns? : : It could be a no-op if necessary, but it could take the place of Perl 5's : study operator and indicate that the programmer WANTS the pattern : optimized for maximum runtime speed, even at the cost of compile time or : memory. (Hey, how about a :cram modifier for extreme optimization? :-) Well, studied isn't really a property of a pattern--it's a property of a string that knows it will have multiple patterns matched against it. One could put a :study on the first pattern, but that's somewhat deceptive. : (2) Would simple alternation impede DFA-style optimizations? : : Currently, a pattern like (Jun|June) would never match June because the : leftmost match Jun would always take precedence, despite the normal : longest-match behavior of regexes in general. This example could be : implemented in a DFA; would that always be the case? Well, June can match if what follows fails to match after Jun. : Would it be better for the matching of (Jun|June) to be undefined and : implementation-dependent? Or is it best to require leftmost semantics? Well, the semantics shouldn't generally wobble around like that, but it'd be pretty easy to let them wobble on purpose via pragma (or via :modifier, which are really just pragmas that scope to regex groups). Larry
RE: rule, rx and sub
On Wed, 28 Aug 2002, Thom Boyer wrote: : Damian Conway wrote: : Any subroutine/function like Cif that has a signature (parameter list) : that ends in a Csub argument can be parsed without the trailing : semicolon. So Cif's signature is: : : sub if (bool $condition, block); : : So what does the signature for Cwhile look like? I've been wondering about : this for a long time, and I've searched the Apocalypses and the : perl6-language archive for an answer, but I've had no success. : : It seems like Cwhile's signature might be something like one of these: : : sub while (bool $test, body); : sub while (test, body); : : But neither of these really works. That's correct. Maybe something like sub while (test is expr, body); But that would be shorthand for something more general--see below. : The first would imply that the test is evaluated only once (and that once is : before 'sub while' is even called). That'd be useless. : : The second would allow multiple evaluations of the test condition (since : it's a closure). But it seems that it would also require the test expression : to have curly braces around it. And possibly a comma between the test-block : and the body-block. That'd be ugly. Maybe we could have something like: sub while (test is rx/expr/, body); or some such. That probably isn't sufficient to pick expr out of Perl's grammar rather than the current lexical scope. : I can create a hypothetical bareblock rule that says: : : When an argument's declaration contains an ampersand sigil, : then you can pass an expression block (i.e., a simple : expression w/o surrounding curlies) to that argument. : : Is there such a rule for Perl 6? Not at the moment. It'd be pure obfuscation if people did that where curlies *are* expected. I still want the curlies required on an else, for instance. : On the positive side, this would be an reasonable generalization of the Perl : 5 handling of expressions given to map or grep. I don't particularly like the old map and grep syntax. : On the negative side, this : rule makes it impossible to have such arguments fulfilled by evaluating an : expression that returns the desired closure (i.e., the expression you type : as an argument isn't intended to be the block you pass, but rather it is : intended to generate the block you want to pass). Well, we could make the same sort of rule that we (eventually) did for bare blocks--if you want to return a closure in that circumstance you'd have to use sub' (or return, in the case of a bare block). : In summary: assuming Perl 6 allows user-defined while-ish structures, how : would it be done? I think the secret is to allow easy attachment of regex rules to sub and parameter declarations. There's little point in re-inventing regex syntax using declarations. The whole point of making Perl 6 parse itself with regexes is to make this sort of stuff easy. Larry
Re: auto deserialization
On Thu, 29 Aug 2002, Steffen Mueller wrote: : Nicholas Clark wrote: : [...] : If the compiler were able to see that my Date $bday = 'June 25, 2002'; : is one statement that both types $bday as Date, and then assigns a : constant to it, is it possible to do the conversion of that constant : to a constant $bday object at compile time? (and hence get compile : time checking) Without affecting general run time behaviour. : : While that may be possible (I can't tell, I gladly take Dan's word for it), : it doesn't make much sense IMHO. It means that you can only initialize those : objects with constants. That's not a problem for people who know Perl well, : but it is going to be one hell of a confusion for anybody learning Perl. I : can see people whining on clpm why they can't do my Dog $rex = : sub_returning_string();. Again IMHO, taking Perl's flexibility in *some* : cases is much worse than making it Java. We're not going to define it so they can only initialize with constants. That would be silly. I think Dan is talking about the case where we can detect that it is a constant at compile time. As such, it's just constant folding, on the assumption that we also know the constructor isn't going to change. Again, though, assignment to a normal variable is unlikely to invoke a constructor in any case. Larry
Re: rule, rx and sub
On Wed, 28 Aug 2002, Sean O'Rourke wrote:
: Being able to specify fixed arguments after a splat looks illegal, or at
: least immoral. It opens the door to backtracking in argument parsing,
: e.g.:
:
: sub foo (*@args, func, *@more_args, $arg, func) { ... }
:
: Saying specifically a list of arrays. Also, would that list gobble up
: everything, or would it actually allow that coderef on the end?
:
: I would expect it to be a syntax error, since the slurp parameter has to
: be the last.
This sort of thing must be done with real parsing rules. These can return
a list of args as a single args argument without having to play with splat.
Larry
Re: Hypothetical synonyms
Don't forget you can parameterize rules with subrules. I don't see any reason you couldn't write a pick (.*?) | (\S+) kind of rule and do whatever you like with the submatched bits. Larry
Re: declaring if and while (was: rule, rx and sub)
On Thu, 29 Aug 2002, Thomas A. Boyer wrote: : Am I getting this straight? As straight as any of us are getting it thus far. :-) The process is intended to be convergent. That doesn't guarantee it will converge, but that's the intention. When I'm playing golf, I always expect to knock the ball into the hole. And I'm happy if the ball ends up closer to the hole than it was. Larry
Re: backtracking into { code }
On Fri, 30 Aug 2002, Ken Fox wrote:
: Ok, thanks. (The followed by a colon is just to explain the behavior,
: right? It's illegal to follow a code block with a colon, isn't it?)
I don't see why it should be illegal--it could be useful if the closure
has played continuation games of some sort to get backtracking.
In the normal case it's a no-op, since closures don't normally get
control back when backtracked over.
: After talking to Aaron yesterday, I was wondering if sub-rules are
: meant to backtrack at all.
:
: Does the following example backtrack into foo?
:
:rule foo { b+ }
:rule bar { a foo b }
Yes, it must. It's only rules embedded in closures that are exempt
by default, I think.
Larry
Re: backtracking into { code }
On Fri, 30 Aug 2002, Ken Fox wrote: : Apoc 5 has It is an error to use : on any atom that does no : backtracking. Code blocks don't backtrack (at least that's what : I understood Damian to say). Code blocks don't backtrack *by default*. But you can do anything in a closure. : Are zero width atoms treated specially? Code blocks are zero width *by default*. But you can do anything in a closure. : And can you give me an example of a continuation game? That sounds : sort of like my original question. Nope. I don't understand continuations. :-) : Great news about backtracking into sub-rules. Perl 6 is going to : be a lovely system to work with. I think it's going to suffer a bit : from the same declarative-face vs procedural-heart** that Prolog : does, but it hits the little language target perfectly. There's a famous book called Golf is Not a Game of Perfect. : ** Prolog uses a cut (!) operator to control backtracking just like : Perl 6. A big problem (at least for me...) is learning when ! just : makes things run faster vs. when ! gives me the wrong answer. Maybe : I just haven't used Prolog enough to get my brain wrapped around it. The purists would say that the cut operator is always the wrong answer even when it gives the right answer. I am not a purist. In case you hadn't noticed... Larry
Re: Regex query
On 20 Sep 2002, Simon Cozens wrote: : their names. also if you use a scalar to grab something which is in a : quantified outer rule what is put in the var? a ref to a list of the : grabbed things? : : *nod* Something I'd like to know. Yes, in fact any list forced into scalar context will make a ref in Perl 6: $arrayref = (1,2,3); Larry
Re: hotplug regexes, other misc regex questions
On Sun, 15 Sep 2002, Steve Fink wrote:
: What should this do:
:
: my $x = the letter x;
: print yes if $x =~ /the { $x .= ! } .* !/;
Depends. I think it may be necessary for speed and safety reasons
to set COW on the string we're matching, so that you're always matching
against the original string. Perhaps we can make it work in the specific
case of concatenation, since we want to it to work for extensible
strings coming from a filehandle. But if a fast implementation needs to
keep pointers into a string rather than offsets from the beginning,
we're asking for core dumps if the string is modified out from under the
pointers, or we have to adjust all known pointers any time the string
may be modified.
: Does this print yes?
:
: print yes if helo =~ /hel { .pos-- } lo/;
Yes, that isn't modifying the string.
: Would it be correct for this to print 0? Would it be correct for this
: to print 2?
:
: my $n = 0;
: aargh =~ /a* { $n++ } aargh/;
: print $n;
:
: It might want to print zero because if regexes are not required to pay
: attention to modifications in the input string, then it can optimize
: away the a*.
Implementation dependent, but there will probably be a :modifier to
specifically turn off optimizations.
: What possible outputs are legal for this:
:
: aaa =~ /( a { print 1 } | a { print 2 })* { print \n } x/
Lots. :-)
Larry
RE: Passing arguments
On Thu, 19 Sep 2002, Brent Dax wrote:
: Aaron Sherman:
: # topicalize: To default to C$_ in a prototype (thus
: # acquiring the caller's current topic).
:
: Well, to topicalize a region of code is actually to specify a different
: topic, that is, a different value for $_. For example:
:
: $foo = new X;
: $bar = new Y;
:
: given $foo {
: print $_.type, \n;#prints X
:
: given $bar {
: #XXX we're using 'given' for this too, right?
: print $_.type, \n;#prints Y
: }
: }
Yes.
: (An aside: it strikes me that you could use Cgiven as a scoped lexical
: alias, i.e.
:
: my $foo=foo;
: my $bar=bar;
:
: print $foo;
:
: given $bar - $foo {
: print $foo;
: }
:
: print $foo;
:
: #prints foobarfoo
:
: Hmm...)
Sure, though it also aliases to $_.
: # signatureless sub: A sub that does not specify a prototype,
: # and thus has a default prototype of:
: #
: # sub($_//=$_){};
: #
: # ne?
:
: More like:
:
: a sub that was created with the arrow (-) or a bare block and
: does not specify a prototype, and thus has a default prototype
: of:
:
: - ($_ //= $OUTER::_) { };
OUTER only works for lexical scopes. What you want is out-of-band access
to the $_ in the surrounding dynamic context
: Or some such. (Maybe C$_ //= $_ will work, but I have reservations
: about that--especially about the possibility of that picking up $_
: dynamically instead of lexically. In some cases you want $_
: dynamically, in others lexically. Perhaps C$_ is topic('lexical') and
: C$_ is topic('dynamic')?)
The current thinking as of Zurich is that the given passes in
separate from the ordinary parameters:
sub ($a,$b,$c) is given($x) {...}
That binds the dynamically surrounding $_ to $x as an out-of-band
parameter. Can also bind to $_ to make it the current topic.
Not sure of the syntax for pointy subs yet. Maybe
- ($a,$b,$c) is given($x) {...}
Larry
Re: Regex query
On 20 Sep 2002, Aaron Sherman wrote: : Is that any list as oppopsed to any array? Or is that arrayref in a : numeric context the length of the array? In other words does this do : what I think I think it does? : : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) Larry
RE: Passing arguments
On Fri, 20 Sep 2002, Brent Dax wrote:
: Larry Wall:
: # That binds the dynamically surrounding $_ to $x as an
: # out-of-band parameter. Can also bind to $_ to make it the
: # current topic.
:
: The problem I have with that is this:
:
: sub for_trace(*@array, block) {
: loop($_=0; $_ array; $_++) {
: print $_:\n;
:
: {
: my $coreprint=CORE::print;
: my $lastnl=1;
:
: temp CORE::print := sub ($fh: *@args) {
: $fh.$coreprint(\t) if $lastnl;
:
: $fh.$coreprint(args);
:
: $lastnl = args[@args.last] =~
: /\n $/;
: }
:
: block(array[$_]);
: }
:
: print \n
: }
: }
:
: $_=x;
: list=qw(y z);
:
: for_trace list - $x {
: print $_;
: }
:
: Which of these does this print?
:
: 0:
: 0
: 1:
: 1
:
: 0:
: y
: 1:
: z
:
: 0:
: x
: 1:
: x
:
: The correct behavior (IMHO) is the third, though I could see the
: second. But the first is unacceptable.
The rule says the innermost topicalizer wins, and pointy sub always
topicalizes its first argument, so the second behavior is what happens.
The third behavior can always be forced with $OUTER::_. But it would
be better stylistically to name it something other than $_--which is
part of the reason we decided to make the topicalizers always alias
$_ in addition to whatever else they might alias. It's much better
to keep the pronouns referring to small-scale topics rather than
large scale.
Larry
RE: Passing arguments
On 20 Sep 2002, Aaron Sherman wrote:
: On Fri, 2002-09-20 at 10:36, Larry Wall wrote:
: On Thu, 19 Sep 2002, Brent Dax wrote:
:
: : (An aside: it strikes me that you could use Cgiven as a scoped lexical
: : alias, i.e.
: : given $bar - $foo {
: : print $foo;
: : }
:
: Sure, though it also aliases to $_.
:
:
: Does that mean that I can't
:
: for $x - $_ {
: for $y - $z {
: print $_, $z\n;
: }
: }
:
: And expect to get different values?
That's correct. Name the outer topic explicitly, not the inner one.
: : # signatureless sub: A sub that does not specify a prototype,
: : # and thus has a default prototype of:
: : #
: : # sub($_//=$_){};
: : #
: : # ne?
: :
: : More like:
: :
: : a sub that was created with the arrow (-) or a bare block and
: : does not specify a prototype, and thus has a default prototype
: : of:
: :
: : - ($_ //= $OUTER::_) { };
:
: OUTER only works for lexical scopes. What you want is out-of-band access
: to the $_ in the surrounding dynamic context
:
:
: I assumed that's what C//=$_ was. It does have the disadvantage of
: looking like variable assignment, though.
I don't think we want to allow binding of defaults to variables of
the outer lexical scope. $_ is kind of special that way.
: The current thinking as of Zurich is that the given passes in
: separate from the ordinary parameters:
:
: sub ($a,$b,$c) is given($x) {...}
:
:
: Ok, that seems saner.
:
: That binds the dynamically surrounding $_ to $x as an out-of-band
: parameter. Can also bind to $_ to make it the current topic.
:
: Not sure of the syntax for pointy subs yet. Maybe
:
: - ($a,$b,$c) is given($x) {...}
:
: I was with you up until this last example. Can you give a surrounding
: context so I can see how that would be used?
Exactly the same as the previous example.
Larry
RE: Passing arguments
On 20 Sep 2002, Aaron Sherman wrote: : I assumed that's what C//=$_ was. It does have the disadvantage of : looking like variable assignment, though. BTW, latest leaning is toward = rather than //= for parameter defaults, since it can, in fact, be undef if the parameter is supplied, while //= seems to imply otherwise. And //= is too visually disruptive to the signature. Larry
Re: hotplug regexes, other misc regex questions
On Fri, 20 Sep 2002, Sean O'Rourke wrote: : On Fri, 20 Sep 2002, Larry Wall wrote: : But if a fast implementation needs to keep pointers into a string : rather than offsets from the beginning, we're asking for core dumps if : the string is modified out from under the pointers, or we have to : adjust all known pointers any time the string may be modified. : : With the current Parrot GC, keeping pointers into the string while doing : unrelated allocation will get you a core dump, since the string body might : be copied. So unless the regex engine copies strings off into its own : private non-collected storage, we're stuck with offsets anyways. That's fine, if it's a constraint. I had thought perhaps COW would allow a locked-down copy to work with without forcing unnecessary copying, but I suppose it doesn't hook into GC at that level. I'd also hoped it would solve any $-style inefficiencies. But hey, that's not my job this time around... :-) Larry
Re: Regex query
On Fri, 20 Sep 2002, John Williams wrote:
: On Fri, 20 Sep 2002, Larry Wall wrote:
:
: Yes, in fact any list forced into scalar context will make a ref in Perl 6:
:
: $arrayref = (1,2,3);
:
: That would seem to obviate the need for brackets to define array
: references. Is there any case where [1,2,3] would be needed instead of
: (1,2,3)?
Sure, in a list context. [1,2,3] is really short for scalar(1,2,3).
: Also, does any list include a list of pairs? Because that would look
: more like a hash than a list.
:
: $ref = ( one = 1, two = 2, three = 3);
Sure. If you really want a hash, use {...}. (Extra rules apply
for parameter lists, though.)
Larry
RE: Passing arguments
On Fri, 20 Sep 2002, Sean O'Rourke wrote:
: On Fri, 20 Sep 2002, Larry Wall wrote:
: The current thinking as of Zurich is that the given passes in
: separate from the ordinary parameters:
:
: sub ($a,$b,$c) is given($x) {...}
:
: That binds the dynamically surrounding $_ to $x as an out-of-band
: parameter. Can also bind to $_ to make it the current topic.
:
: Does this mean that we allow/encourage uses of $_ other than as a default
: for an optional argument? I think it would be less confusing and
: error-prone to associate the underscore-aliasing with the parameter $_
: will be replacing, i.e. this
:
: sub foo($a, $b = given) { ... }
:
: vs this
:
: sub foo($a; $b) is given($b) { ... }
:
: or this
:
: sub foo($a; $b) is given($c) {
: $b //= $c;
: ...
: }
We want to be able to write CORE::print, among other things.
: Furthermore, if the caller can pass undef for the second parameter, I
: don't see a way to distinguish in the third variant between a legitimately
: passed undef, for which we don't want $_, and a missing optional argument,
: for which we do.
You can check for that with exists.
We felt you could use exists to check a parameter for having been passed.
BTW, I may be out of touch for a week. Don't know if I'll have
Internet access where I'll be. YAPC::Europe is just going through
the final announcements as I type, so my current connection will go
away soon.
Larry
Re: RFC: [] as the solitary list constructor
}; Larry
Re: RFC: [] as the solitary list constructor
On 6 Oct 2002, Smylers wrote: : Do parens still provide list context on the left side of an assignment? Er, kind of. More precisely, use of parens on the left provides a flattening list context on the right side, just as in Perl 5. I guess I did not make clear that a basic Perl 6 design decision was that = will appear to work exactly as it does in Perl 5, while all the new semantics get put into := instead. In fact, = doesn't work exactly the same, because it lazily evaluates things like ranges and other potentially infinite lists. But that should be more or less transparent. Larry
Re: RFC: [] as the solitary list constructor
On Sun, 6 Oct 2002, Trey Harris wrote: : In a message dated Sun, 6 Oct 2002, Noah White writes: : On Sunday, October 6, 2002, at 01:50 AM, Brent Dax wrote: : : Parens don't construct lists EVER! They only group elements : syntactically. One common use of parens is to surround a : comma-separated list, but the *commas* are creating the list, *not* the : parens! : : : Following this rule would mean that : :$a = (); # $a is a list reference with 0 elements : : should not be a list reference at all and would appear inconsistent. : : No, because there are zero commas. Squint and you can see them. :-) Actually, () has -1 commas, which is why it's not ambiguous. Rather, it's ($x) that has zero commas, so it's naturally ambiguous, and thus must depend on context to determine whether to produce a scalar or a list value. Seriously, () is just a special token. We could easily have used a special token like NULLLIST instead. What does INTERCAL use? Larry
Re: RFC: [] as the solitary list constructor
On Sat, 5 Oct 2002, Chip Salzenberg wrote:
: According to Larry Wall:
: I suppose we could make comma merely puke in scalar context rather
: than DWIM, at least optionally.
:
: I rather like Perl 5's scalar comma operator.
Most of the uses of which are actually in void context, where it
doesn't matter if we technically build a list and throw it away,
or throw away all but the last value, then throw that one away too.
Which is why it got decided the way it was. If you really want the
last value, you can always use
(LIST)[-1]
which could be construed as better documentation. Admittedly it's
not quite the same, since LIST is evaluated in list context.
Anyway, if we did outlaw comma in scalar context, it would not apply
to void context, or we couldn't write:
loop ($a=0, $b=1; $c; $a++, $b++) { ... }
: : $a = ();# $a is a list reference with 0 elements
: : $a = (10); # $a is the scalar 10
: : $a = (10, 20); # $a is a list reference with 2 elements
:
: I don't think that's an important inconsistency.
:
: What if $a and $b are both array refs, and maintenance programmer
: changes:
: for $a, $b { print }
: to:
: for $a { print }
: Will that end up iterating across $a? The equivalent of that gotcha
: was forever bugging me in Python (gack).
No, in list context reference scalars must still be explicitly
dereferenced. The $ on the front still means something occasionally.
It's only in scalar contexts that $ can be autodereffed as an array
now, so that someone can say
push $a, list;
But if you say
push $a, $a;
you get the ref in $a pushed onto $a, as it currently stands.
Larry
Re: for loop and streams
On Fri, 27 Sep 2002, Dan Sugalski wrote: : At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote: : On Thu, 26 Sep 2002, Paul Johnson wrote: : Is that sufficiently vague? : : Not vague enough, because the current implementation manages to miss the : broad side of that semantic barn... : : The intention is to allow aggregates to have different default return : values, IIRC. Right now we return undef as the default, when : accessing elements that don't exist, but there are cases where you : might want something else. (Numeric-only arrays might want to return : 0, and string-only ones , for example) We can certainly have arrays that know how to return default values. But my apocalyptic remarks about dwimming were specifically with respect to hyperoperators that might have specific ideas about how to deal with differing arrays. That behavior should in turn be distinguished from what I said about parallel Cfor loops. Those run until all streams are exhausted, because otherwise there's no way for the code within the loop to tell the loop to run longer. If you assume you should run longer, it's always possible for the loop to terminate itself early. In the particular case where one or another stream is infinite, the loop will run forever unless terminated explicitly by either loop control or detonation of the warhead. : Different operators doing different things sounds awful to me, because it : makes it hard to predict what will happen, because new operators will have : to be able to control what they do with their operands, and because new : types of array-like operands will have to tell operators how to treat : them. Blech. : : Well... no, not really. : : I think this vagueness is my fault, as I badger Larry and Damian : about it on occasion. Well, I'm never vague, except when I am. : The reason it's vague is that the Right Thing depends on the types of : the variables on either side of an operator. Multiplying two matrices : should work differently than multiplying two multidimensional arrays, : or two vectors, or a vector by a matrix. : : We should get the default behaviour defined and in use so people get : a handle on how things work, but we do want to make sure people keep : in mind that it's the default behaviour, not the required behaviour. Right-o. A system is expert friendly if it has the right options. It's novice friendly if it has the right defaults. Larry
Re: perl6 operator precedence table
On Thu, 26 Sep 2002, Sean O'Rourke wrote:
: Thanks for taking the time to write this out.
:
: On Thu, 26 Sep 2002, John Williams wrote:
: perl6 operator precedence
:
: leftterms and list operators (leftward) [] {} () quotes
: left. and unary .
: nonassoc++ --
: leftis but
:
: This would lead to some scary things, I think:
:
: $a = 3 + 4 but false
: = (= $a (+ 3 (but 4 false)))
:
: Of course, so does having low precedence:
:
: $a = 3 but false + 4
: = (= $a (but 3 (+ false 4)))
:
: but I think the latter is unnatural enough that it deserves parens, so I'd
: put 'but' above comma (and probably '='), but below just about everything
: else.
Could perhaps unify with C... Wouldn't hurt for it to be non-associative like C...
: Larry mentions that other precedence unifications are possible. I can see
: the following as possibilites. Are there others?
: with
: | with ||
:
: It seems like a good idea to me to encourage people to think of bitwise
: ops as mathematical, not logical, so I'd rather see them with different
: precedences. Plus, anything that significantly goes against people's
: hard-wired C expectations will just lead to confusion and pain. Finally,
: having '|' below '' will probably lead to strange things, e.g.
:
: 1|2 3|4
: = 1 | (2 3) | 4
I'd be more inclined to unify and | with * and +, since that's
exactly what they are in Boolean algebra, where 1*1 == 1. I think
the argument that it breaks C compatibily is weak in this case,
since almost everyone admits that C is broken in this respect.
Alternately, we take | and away from bitwise ops and do something
more useful with them. I have been asked privately by a sight
impaired person to consider using | as the separator for parallel
streams rather than the almost invisible ; character, for instance.
Being a bit sight impaired myself at the moment, I have great empathy...
Larry
Re: perl6 operator precedence table
On Thu, 26 Sep 2002, John Williams wrote:
: I'm trying to write a revised operator precedence table for perl6,
: similar to the one in perlop.pod.
:
: This is what I have come up with based on Apocalypse 3 and Exegesis 3.
: Does anyone have comments? I'm not sure if the precedence
: for : (adverb) or 'is' and 'but' are quite right.
Me either.
: perl6 operator precedence
:
:leftterms and list operators (leftward) [] {} () quotes
:left. and unary .
Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
:nonassoc++ --
:leftis but
Should probably be down about where .. is, maybe same as.
:right **
:right ! \ and unary ~ + - * _
Probably unary ? goes here too.
:left=~ !~
Probably should be the same as all the other comparison ops.
:left* / % x
And maybe.
:left+ - _
And | maybe.
:left
Can be argued these are really just multiplicative. Or even exponential.
:right named unary operators, -X
:left = = lt gt le ge == != = eq ne cmp
:left
:left| ~
Not sure what to do with ~ if we move and |. Probably just follows |.
:left
:left|| ~~ //
:nonassoc.. ...
Maybe but here. Maybe is too, though compile-time declarations
don't necessarily have the same syntactic constraints as ordinary
expressions.
:right ??::
:right = := **= += -= _= *= /= %= x= = |= ~=
: = = = ||= ~~= //=
:left, =
= is no longer a comma. I think it has to be tighter than , now,
or we can't say
a = a, b = b
Perhaps it goes in as another nonassoc .. operator.
:left;
:left:
While semicolon is definitely looser than comma, it's not clear where
colon should go yet.
:nonassoclist operators (rightward)
:right not
I've also considered unifying Cnot with the list operators, which are
actually right associative, or you couldn't say
print sort 1,2,3;
On the other hand, it would be strange for Cnot to give its right
side a list context.
:leftand
:leftor xor err
Those are fine. :-)
Larry
Re: Fw: perl6 operator precedence table
On Thu, 26 Sep 2002, Joe Gottman wrote:
: Apocalypse 4 mentions unary '?' . Since this is used to force boolean
: context, I would assume that it has the same precedence as unary '+' and
: '_' which force numeric and string context respectively. By the way, has
: anyone come up with a use for binary '?' yet?
More likely to be a postfix operator. Maybe it even means the same thing:
if ?foo() {...}
if foo()? {...}
I've always wondered what the ! postfix operator means. The mathematicians
think they know. :-)
There's this basic rule that says you can't have an operator for both binary
and postfix, since it's expecting an operator in either case, rather than a
term (which is how we recognize prefix operators). The one exception I can
think of is that we might allow .. as a postfix operator, but only if followed
by a right bracket. That would let us say
a[0..]
rather than
a[0..Inf]
But that's a special case.
Larry
Re: perl6 operator precedence table
On Wed, 9 Oct 2002, John Williams wrote:
: On Tue, 8 Oct 2002, Larry Wall wrote:
:
: : but I think the latter is unnatural enough that it deserves parens, so I'd
: : put 'but' above comma (and probably '='), but below just about everything
: : else.
:
: Could perhaps unify with C... Wouldn't hurt for it to be
: non-associative like C...
:
: 'Is' and 'but' return their left operand to allow chaining, so don't 'is'
: and 'but' need to be left associative so the following will work?
:
: 0 but true but string('zero rows affected')
It might be clearer to require the parens there to disambiguate
(0 but true) but string('zero rows affected')
from
0 but (true but string('zero rows affected'))
But you're probably right that people will expect it to just stack more
properties on the leftmost argument.
: I'd be more inclined to unify and | with * and +, since that's
: exactly what they are in Boolean algebra, where 1*1 == 1. I think
: the argument that it breaks C compatibily is weak in this case,
: since almost everyone admits that C is broken in this respect.
:
: Good point.
:
: Alternately, we take | and away from bitwise ops and do something
: more useful with them. I have been asked privately by a sight
: impaired person to consider using | as the separator for parallel
: streams rather than the almost invisible ; character, for instance.
: Being a bit sight impaired myself at the moment, I have great empathy...
:
: | and do one thing different from + and *. They impose integer context
: on their operands, rather that just numeric.
Not if you use them on strings.
: How about moving ** down to just above *? There's no precedence from C,
: and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
: what the intuitive behavior should be for the other unary operators
: though.
Seems to me we once had it that way, and people complained.
: I can post a revised table if the associativity of 'but' is clarified.
I wonder if we can combine .. with but. What if .. could also be
left associative? What would 1 .. 10 .. 10 mean? Maybe:
[1,2,3,4,5,6,7,8,9,10],
[2,3,4,5,6,7,8,9,10],
[3,4,5,6,7,8,9,10],
[4,5,6,7,8,9,10],
[5,6,7,8,9,10],
[6,7,8,9,10],
[7,8,9,10],
[8,9,10],
[9,10],
[10]
Hmm. I guess 1 .. (0 ..) would then mean something like:
[],
[1],
[1,2],
[1,2,3],
[1,2,3,4],
[1,2,3,4,5],
[1,2,3,4,5,6],
[1,2,3,4,5,6,7],
[1,2,3,4,5,6,7,8],
[1,2,3,4,5,6,7,8,9],
[1,2,3,4,5,6,7,8,9,10],
...
That strikes me as potentially useful to someone.
Larry
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Nicholas Clark wrote:
: On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote:
: There's this basic rule that says you can't have an operator for both binary
: and postfix, since it's expecting an operator in either case, rather than a
: term (which is how we recognize prefix operators). The one exception I can
: think of is that we might allow .. as a postfix operator, but only if followed
: by a right bracket. That would let us say
:
: a[0..]
:
: rather than
:
: a[0..Inf]
:
: But that's a special case.
:
: Would that mean that three other special cases of postfix .. might exist?
:
: 0..; # useful for return 0..;
I bet the PDLers want to be able to say: a[0..; 0..:10; 0..:100]
: (0..) # pass infinite lists as parameters with less typing
: {0..} # not sure, but it follows on
I meant those too when I said bracket.
If only we had Unicode editors, we could just force everyone to use
the infinity symbol where they mean it. It seems a shame to make a
special case of the .. operator. Maybe we should ... to mean and so
on forever:
a[0...; 0...:10; 0...:100]
Except then we couldn't use it to mean what Ruby means by it, which
might be handier in real life. (It means to exclude the endpoint,
so 0...4 is the same as 0..3. But then, that's kind of odd too.)
Larry
Re: Fw: perl6 operator precedence table
On Wed, 9 Oct 2002, Brad Hughes wrote: : Larry Wall wrote: : [...] : Maybe we should ... to mean and so on forever: : : a[0...; 0...:10; 0...:100] : : Except then we couldn't use it to mean what Ruby means by it, which : might be handier in real life. : : No more yada-yada-yada? Still have yada-yada-yada. That's ... when a term is expected, not when an operator is expected. Just don't write 1,2,3... when you mean 1,2,3,... Or vice versa. Larry
Re: Interface lists (was Re: Interfaces)
On Mon, 30 Sep 2002, Michael G Schwern wrote:
: On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
: [EMAIL PROTECTED] (Michael G Schwern) writes:
: method _do_internal_init ($num) is private {
:
: Just thinking aloud, would
: sub foo is method is private is integer is fungible {
:
: be better written as
: sub foo is fungible private integer method {
:
: or not?
It's potentially ambiguous. Here's a bad example, but there are probably
better ones:
my $foo is rw cmp ;
Plus we have to worry about arguments to properties, if we allow
anything other than (). I'd personally like to see some properties
that can take a closure as their argument, but the parser would have
to know that in advance or the method property above would slurp
up the subroutine block by accident. Or the sub block itself needs
a keyword.
: How about seperated by commas, like any other list?
:
: method foo is fungible, private, integer {
Is ambiguous:
my ($foo is foo, bar, $bar is baz) = (1,2);
Also, precedence of comma with respect to assignment causes problems.
We may be able to relax this later somehow, but for now we're saying
that is...is...is... isn't all that onerous.
To which the only correct reply is, but...but...but... :-)
Larry
Re: Interfaces
On Mon, 7 Oct 2002, chromatic wrote: : On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote: : : I like the class Vehicle is interface as a shorthand for declaring every : method of a class to be an interface. : : Perhaps associating a property with a class can be shorthand for associating : that property with every method of the class? Not in general, since the class needs to be able to have properties apart from from its methods, such as its parent classes. But a particular property such as interface could certainly be set up to be distributive over the methods or attributes. Larry
Re: Interfaces
On Mon, 7 Oct 2002, Andy Wardley wrote: : Nicholas Clark wrote: : I think that the first syntax : : class Car::Q is Car renames(eject = ejector_seat) : is CD_Player renames(drive = cd_drive); : : makes it more clear that I'd like to pick and choose which methods : the composite object gets from which parent. : : But now you've turned composition back into inheritance, and I think it's : important to be able to distinguish between the two. : : The car is definately not a CD player, it just has one. : : I think we need a more flexible syntax for specifying how interfaces : should be constructed in the case of composed objects, rather than : turning composition into inheritance to avoid the problem. Yes, that's important. If you've got a CD_Player *object*, it doesn't do anyone any good to pretend it's a car *object*. We too often lose sight of the fact that objects should behave like objects. That's what OO really means, after all. OO isn't about inheritance Anyway, I don't see offhand why composition can't simply be done with attributes as it is in C++, especially since attributes manifest as methods outside the class. I don't think $car.cd.eject() is all that horrible to contemplate. Larry
Re: remote generators and a macro language proposal
On Thu, 10 Oct 2002, Chip Salzenberg wrote:
: According to Luke Palmer:
: for ( grep { $_{smoker} and $_{age} 18 } Subscribers ) {
: .send($Cigarette_Advertisement)
: }
:
: Hm, would this work too:
:
: for ( grep { .{smoker} and .{age} 18 } Subscribers )
: { .send($ciggie_ad) }
:
: ? I think .{x} reads better than $_{x} , esp. in parallel with the
: method call in the same loop.
Didn't see the original, but if those are attributes, why wouldn't
it just be:
for grep { .smoker and .age 18 } Subscribers {
.send($ciggie_ad)
}
'Course, this might be more readable:
for Subscribers {
.send($ciggie_ad) if .smoker and .age 18;
}
Most smokers don't know what grep means, after all...
Larry
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Chris Dutton wrote:
: Wasn't class MyClass; supposed to work along the line of Perl5's
: package MyClass; and make everything following that statement the
: definition of MyClass?
Yes, though we're thinking of limiting that construct to the front
of a file, along with module MyModule;. That is, we discourage
people from writing
{
class MyClass;
...
}
when they mean
class MyClass {
...
}
Larry
Re: Delegation syntax
: Problem:
:
: You want to use delegation rather than inheritance to
: add some capabilities of one class or object to
: another class or object.
:
: Solution:
:
: Use a PROXY block:
:
: class MyClass {
:
: PROXY {
: attr $left_front_wheel is Wheel;
: attr $right_front_wheel is Wheel;
:
: when 'steer'{ $left_front_wheel, $right_front_wheel }
: }
: ...
: }
I think this is falling into the use overload gobbledygook trap.
If something is part of the method interface, it ought to be declared
as a method. It's the *implementation* syntax that should be screwed
around with to do delegation. Something like:
method steer is really(Wheel) is also(???) { .profit!!! }
I guess now we need C??? and C!!! tokens now to go with C
:::---)))
Larry
Re: perl6 operator precedence table
On Fri, 11 Oct 2002, Jonathan Scott Duff wrote:
: On Fri, Oct 11, 2002 at 03:21:38PM +0100, Aaron Crane wrote:
: Vaguely heretical, I know, but I'd be inclined to do something like this:
:
:Perl 5 Proposed Perl 6
:$x $y $x $y
:$x || $y $x | $y
:
: Larry just added nice character doubling ops to be more consistent and
: here you want to take two of them away? :-)
I doubt I'd muck with the doubled ones.
I'm wondering whether the single ones could indicate parallel streams.
We had the difficulty of specifying whether the Cfor loop should
terminate on the shorter or the longer stream. We could say that |
terminates on the longer, and on the shorter. Possibly there's
some relationship with any() and all() in there as well. The | could
generally be construed as a comma that doesn't guarantee ordering.
So cases could be written
when 1 | 2 | 3 {...}
as well as with comma. Saying
when 1 2 3 {...}
might be short for
when all(1,2,3) {...}
:$x $ybitand($x, $y)
:$x | $ybitor($x, $y)
:
: Using functions instead of operators for these operations seems reasonable
: to me given how often they're useful.
:
: How about these?
:
: $x band $y
: $x bor $y
:
: Of course, then people will probably expect these too:
:
: $x bshl $y
: $x bshr $y
: $x bxor $y
:
: Hrm ...
:
: sysopen(FOO,foo, O_WRONLY bor O_CREAT bor O_TEXT)
: sysopen(FOO,foo, bor O_WRONLY, O_CREAT, O_TEXT)
:
: :-(
:
: As long as we're in fantasy-land, how about these?
:
: $x . $y
: $x .| $y
I was thinking more along the lines of:
$x $y
$x ||| $y
But then there's ~ vs ~~~ too. The triple syntax at least has the
virtue of the visual metaphor of doing a bunch of ANDs or ORs in
parallel. But it's kind of odd to write ~~~$x for a one's complement.
Anyone else want to be UNSUBSCRIBED IMMEDIATELY? :-)
: Those look like bit operations to me :-)
:
: I'm not especially fond of the names bitand and bitor, but they're
: accurate, reasonably short, and have prior art in C and C++.
:
: Not all prior art is necessarily good art :-)
:
: Two things about this proposal:
:
:* This leaves and || available for other purposes, but I can't
: off the top of my head think of anything else I'd want them for.
:
: Then why muck with them? Just munge the bitwise operators.
:
:* Does this make it harder to write overloaded bitwise ops for your
: classes?
:
: No harder than it was before especially given that you can warp the
: syntax however you please.
No warpage necessary. All operators can be named as functions with
operator: on the front.
Larry
Re: Private contracts?
On Thu, 3 Oct 2002, Trey Harris wrote: : In a message dated Thu, 3 Oct 2002, Allison Randal writes: : So far, classes are uppercase and properties are lowercase, but that's : convention, not law. : : Do runtime (value) properties and compile-time (variable) properties share : the same namespace? In general, no. : That is, to go back to an earlier discussion, if there is a system-defined : value property Ctrue which marks a value as true in boolean contexts, : can I also define a compile-time property Ctrue that makes the variable : evaluate as true, whatever its value? No, I think the boolean test would probably ignore the variable at that point. Think of variable properties as more of a tie. The variable could contrive to always return a true value, but that's about it. There's unlikely to be any implicit relationship between variable properties and value properties. A major exception to that might be that the type declared on the variable is checked against the value's type at appropriate times. Larry
Re: Private contracts?
On Sat, 5 Oct 2002, Allison Randal wrote: : use Acme::N-1_0; # or whatever the format of the name is I don't see why it couldn't just be: use Acme::1.0; After all, we don't have package names starting with numbers right now... Larry
Re: Interfaces
On Fri, 11 Oct 2002, Michael Lazzaro wrote:
: On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
: has Nose $.snout;
: has Ear .ears is cut(long);
: has Leg .legs;
: has Tail $.tail is cut(short);
:
: method Wag () {...}
: }
:
: What's the rationale again for the dot in $.snout? Does it imply that
: it should be
:
: method .Wag () {...}
:
: to match?
Yes, that's part of it, presuming you actually meant:
method .snout () {...}
It also doesn't look like either a lexical or a global when you use
it within the method. I always hated that about C++.
I suppose it could be argued that the . is redundant within a has,
but I kinda like the consistency. It could also be argued that
the '$' should be dropped on scalar attributes, but that's another
consistency thing. You can certainly drop it within the methods,
since there's also the accessor methods.
Larry
RE: Private contracts?
On Fri, 4 Oct 2002, Garrett Goebel wrote:
: That wasn't the way I remembered it from Apoc 4... The following example is
: not in A4, but its what I inferred from it...
:
: Class Foo {
: method eat($food) is abstract {
: PRE { ... }
: POST { ... }
: }
: }
A4 was proposing those for a different purpose, and confusing the issue with DBC.
Those are now FIRST and LAST, and the pre/post syntax is still undecided.
Larry
Re: Private contracts?
On Fri, 4 Oct 2002, Peter Haworth wrote:
: This is the one nice thing about the Pascal-like syntax of Eiffel. It allows
: this situation to be unambiguous and sensibly ordered (as well as giving each
: condition labels, so that violations can be better reported):
:
: foo(this: ThisType, that: ThatType): FooType IS
: REQUIRE
: small: this = 42
: half: that = this / 2
: DO
: -- implementation goes here
: ENSURE
: fooed_ok: RESULT = baz(this) + that
: END
:
: If you're declaring an abstract feature, just replace the whole DO clause with
: DEFERRED.
That is exactly what a literal C {...} means in Perl 6, and why it's required on
forward declarations of
anything that takes a block, if you really mean it that way. You can't say
sub foo;
in Perl 6. You have to say
sub foo {...}
: Also notice how Eiffel's syntax also somehow makes statement
: terminators completely optional.
Yes, well, let's not go there... :-)
: Aren't sub declarations in Perl 6 all expressions? Why couldn't we put the
: post condition at the end, then?
:
: sub foo($this, $that) is memoized is something
: is pre{ $this = 42 }
: is pre{ $that == $this / 2 }
: {
: # implementation goes here
: } is post{
: # postcondition 1
: } is post{
: # postcondition 2
: }
:
: If you want an abstract method, just omit the implementation block.
The absence of something is hard to notice. Put {...} for an abstract method.
Larry
Re: Private contracts?
On Thu, 3 Oct 2002, John Williams wrote:
: On Thu, 3 Oct 2002, Trey Harris wrote:
:
: Incidentally, has there been any headway made on how you DO access
: multiple classes with the same name, since Larry has (indirectly) promised
: us that? I.e., I import two classes LinkedList and BTree, both of
: which define a Node class?
:
: Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines
: a BTree::Node class. Either by explicitly naming them that or by virtue
: of being defined as an inner class (which might also make it private).
A private inner class:
my class Node {...}
A public inner class:
our class Node {...}
That last one actually declares a subclass of the current class, just as
our $foo;
puts $foo into the current package.
Larry
Re: Private contracts?
On Thu, 3 Oct 2002, Michael G Schwern wrote:
: On Thu, Oct 03, 2002 at 05:23:08PM -0500, Jonathan Scott Duff wrote:
: I don't know, but I think it's supposed to be like this:
:
: # part of the signature
: method turn($dir,$ang) is pre { $ang = 20 } {
: ...
: }
:
: # part of the implementation
: method turn($dir,$ang) {
: PRE { $ang = 20 }
: ...
: }
:
: turn() methods of derived classes would inherit the precondition in the
: first case but not the second. I don't know why you'd want to do this
: exactly, but it seems to me that perl should allow it.
:
: I see us already smashing too many things into the method signature as it
: is. It will rapidly get messy if you have a method with a complex signature
: and a handful of attributes and preconditions.
:
: Also, where do the postconditions go? In the signature at the front? That
: doesn't make sense, it should go at the end so you can keep them in mind
: when you're writing the return code.
:
: Consider...
:
: method foo($this, $that) is memoized is something
: is pre { $this = 42 }
: is pre { $that == $this / 2 }
: is pre { a lot of code which is hard to
:shove into a block of code
:this close to the right margin }
: is post { what is a post condition
: doing at the front? }
: {
: ...
: }
:
: They can, of course, be pulled back from the margin:
:
: method foo($this, $that) is memoized is something
: is pre { $this = 42 }
: is pre { $that == $this / 2 }
: is pre { now we have a little bit more room to play with using
: a differnt indentation style }
: is post { but post conditions are still distanced from the
:code which return()s }
: {
: ...
: }
:
: I realize that conditions are technically part of the signature, but putting
: them in there paints us into a stylistic corner.
Hmm. It sounds like a cry for help. :-)
method foo($this, $that) is memoized is something
{
...
}
# Additionaly...
also foo
is pre { $this = 42 }
is pre { $that == $this / 2 }
is pre { now we have a little bit more room to play with using
a differnt indentation style }
is post { but post conditions are still distanced from the
code which return()s };
One is tempted to make it:
also note that foo is pre { ... }
It might be possible to allow is after the {...} block, much like an Celse block.
But an also would let us defer all the extras to the end of the class definition.
: I'm also not fond of the pre/PRE distinction. Few of the other special
: blocks (given, eval, try, invar, etc...) use all cap names. At least I hope
: not.
All caps indicates a BEGIN-like block that is not evaluated inline, but
sets a property in the surrounding scope. It's a useful distinction.
: Simply attaching an is private attribute to a pre condition block
: seems the simplest way to go about it.
Except that you'd have to parenthesize it:
is pre ({...} is private)
Otherwise it'd merely privatize whatever the first is is issing.
: Just like any other private thing,
: it's not inherited and not visible outside the current class. pre vs
: PRE doesn't convey that meaning.
Well, yes it does, because the pre is in the declaration, and the
PRE is embedded in the implementation, albeit known at compile time.
Not that we're necessarily going to have PRE/POST blocks anyway,
but that's how they'd parse.
I think it'd be kinda strange (but possible (but possibly useless))
to have a declaration like:
sub foo {
...
PRE { _ 0 }
}
That is, the precondition would go away as soon as you redefined the {...}.
Larry
Re: perl6 operator precedence table
On 11 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Larry Wall) writes: : I was thinking more along the lines of: : : $x $y : $x ||| $y : : This isn't Perl; this is merely some language that looks a bit like : it. I can understand the attraction for confusing anyone who comes : from a standard Unix language background, but I'm not sure it's a : great idea, all told. I'm not sure either, and that's why I'm thinking about it. :-) Larry
Re: Private contracts?
On 4 Oct 2002, Aaron Sherman wrote:
: There are a very large number of good things that I think we should put
: into properties for meta-programming purposes (e.g. constraints,
: assertions, optimization hints, documentation, etc).
:
: For example:
:
: sub f(int $a is constrained($a=1,must be positive),
: documented(an integer))
: is constrained(some_global_condition),
: documented(applies transformation f to an integer) {
: ...
: }
Another good reason to allow:
sub f(int $a is constrained($a=1,must be positive),
documented(an integer)) {
...
}
also f is constrained(some_global_condition),
documented(applies transformation f to an integer);
or possibly even
sub f(int $a) {
also $a is constrained($a=1,must be positive),
documented(an integer);
...
}
also f is constrained(some_global_condition),
documented(applies transformation f to an integer);
One could argue that, given that is is always compile-time, the also
is redundant.
sub f(int $a) {
$a is constrained($a=1,must be positive),
documented(an integer);
...
}
f is constrained(some_global_condition),
documented(applies transformation f to an integer);
But maybe that's too weird.
Larry
Re: perl6 operator precedence table
On Fri, 11 Oct 2002, Dan Sugalski wrote: : I think that, for me at least, it'll be close enough to C to be : really confusing. (I already have the problem of leaving parens off : of my function calls when I write XS code...) There's a certain : appeal to not having to swap in almost-but-not-quite-the-same sets of : punctuations when moving from language to language. And now for something completely not quite different... bits($x $y) bits($x | $y) That is, bits() could just be a function that takes a superposition and interprets it as bitops, which makes an odd kind of sense. Or we could fix the if this number was never used as a string problem by differentiating integer ops from string ops: intbits($x $y) intbits($x | $y) strbits($x $y) strbits($x | $y) One could maybe shrink that down to int($x $y) int($x | $y) str($x $y) str($x | $y) Except that's not really much different than: +($x $y) +($x | $y) _($x $y) _($x | $y) And that would conflict with Damian's current notions of how superpositions behave in numeric or string context. Still, you can see how bits(1|2|4|8) could be made to work even if it really meant bits(any(1,2,4,8)) Larry, still thinking about a language vaguely resembling Perl 5. :-)
Re: Draft Proposal: Declaring Classwide Attributes
On Fri, 4 Oct 2002, Michael Lazzaro wrote:
: Date: Fri, 4 Oct 2002 16:40:04 -0700
: From: Michael Lazzaro [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Subject: Draft Proposal: Declaring Classwide Attributes
:
: (Disclaimer: My purpose in proposing this is not to recommend it, but
: to document whether the idea should be endorsed, or shot down, and any
: proposed canonical syntax. Note that the later implications of these
: choices are quite substantial. Please discuss!)
:
: [Draft Proposal: Declaring Classwide Attributes]
:
: Within a class, classwide attributes are declared using the standard
: my and our.
:
: Example:
:
: class Zap {
: my %zap_cache; # a private classwide attribute
: our $zap_count = 0; # a public classwide attribute
:
: attr $foo;
: attr $bar;
: }
:
:
: [Discussion]
:
: Many OO-based languages have the concept of classwide attributes;
: that is, attributes that only exist once, for the class (and all
: subclasses?), as opposed to existing one for each instance of a class.
: You can use these attributes as counters, or caches, or any other
: common ground for use by all instances of the class.
:
: Within a class definition, Perl simply uses the my/our keywords for
: this purpose.
:
: If any value is to be assigned to a classwide attributes, that
: assignment is done once, upon initialization of the class.
If you want accessor methods, use the dot:
class Zap {
my %.zap_cache; # a private classwide attribute
our $.zap_count = 0;# a public classwide attribute
has $.foo;
has $.bar;
}
It may be that $.zap_count is public not so much because of the class definition
where it would default to private, but because $.zap_count's real global name is
$Zap::.zap_count. To get a public accessor method you might still need to declare
it public. And you could get a public accessor method to the my variable as well
the same way. (That means is that the {...} of the class definition is really just
a closure that executes once when the class is built.)
Larry
Re: Private contracts?
On Fri, 11 Oct 2002, Trey Harris wrote:
: When you say subclass, do you mean below the current class in the
: naming heirarchy, i.e.
:
: class BTree;
: our class Node {...}
:
: would create BTree::Node? Or do you really mean *subclass*, i.e., our
: class causes Node to inherit from BTree? I hope it's the former, but the
: word subclass does usually imply inheritance
Sorry, I meant a class named within the current package, not a derived class.
Larry
Re: Draft Proposal: Declaring Classwide Attributes
On Sat, 12 Oct 2002, Me wrote:
: We also need a signifier for class methods (assuming
: a distinction is made).
:
: Perhaps one could use an initial cap to indicate a class
: attribute/method:
:
: class foo {
: my $bar;# my is not used for attributes
: our $baz;# neither is our
: has qux; # instance attribute
: has Waldo; # class attribute
: method qwe; # instance method
: method Rty; # class method
: }
:
: or similar.
I prefer to keep caps distinctions conventional rather than mandatory.
Maybe class methods could be indicated as in Ruby:
method qwe; # instance method
method foo.rty; # class method
But that wouldn't work as well for an anonymous class...
And Perl 5 certainly gets away without making the distinction.
And confusing the two does help if you want to write constructors
that can clone objects as well as create new ones. Perhaps they
could be distinguished by the type of the invocant, if declared.
Larry
Re: Private contracts?
On Sat, 12 Oct 2002, Larry Wall wrote: : The precedence is screwed up though. It'd have to be : : use Acme[ (1;17..) | (2;0..) ]; Or maybe this: use Acme[1;17..] | Acme[2;0..]; That doesn't, of course, express any preference for one version over another, since | logically happens in parallel universes, in constant time. It also doesn't let you pass different arguments to different versions. It does, however, let you try using differently named modules that provide the same interface: use Acle[1;17..] | Acme[1;13..] | Acne[1;14..]; That syntax doesn't, however, let you alias the interface to a single name. Hmm. class MyAc is really(Acle[1;17..] | Acme[1;13..] | Acne[1;14..]); use MyAc 1,2,3; Seems a little odd to do the use on the alias, but it seems like it could work. I'm not quite sure when a class wave function collapses though... Larry
Re: Private contracts?
On Sat, 12 Oct 2002, Luke Palmer wrote:
: Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
: From: Larry Wall [EMAIL PROTECTED]
:
: If we use | and as sugar for any() and all(), then their precedence
: should probably be the same as || and .
:
: Should they? I had in mind something just above comparisons. That
: way:
:
: if $x == 3 || $y == 4 {...}
:
: and
:
: if $x == 1 | 2 { ... }
:
: both DWIM. Is there a case for not doing this?
Mmm, only a precedence simplification case. I'd forgotten about
the comparison ops. Right above them is probably a good place.
Larry
Re: Interfaces
On Thu, 10 Oct 2002, Larry Wall wrote:
: Anyway, I don't see offhand why composition can't simply be done with
: attributes as it is in C++, especially since attributes manifest as
: methods outside the class. I don't think $car.cd.eject() is all that
: horrible to contemplate.
By the way, ever since we came up with attr in Zurich, I've been
hating it more and more. I'm thinking that has reads a lot better:
class Dog is Mammal {
has Nose $.snout;
has Ear .ears is cut(long);
has Leg .legs;
has Tail $.tail is cut(short);
method Wag () {...}
}
Or, along the lines of my lists:
class Dog is Mammal {
has (
Nose $.snout,
Ear .ears is cut(long),
Leg .legs,
Tail $.tail is cut(short),
);
method Wag () {...}
}
Larry
Re: Draft Proposal: Declaring Classwide Attributes
On Sat, 12 Oct 2002, Me wrote:
: I've looked before for discussion of the rationale behind
: introducing attr/has and failed to find it. I noticed you
: mention Zurich, so perhaps this decision followed from
: discussion in living color (as against b+w).
:
: Anyhow, what was deemed wrong with using my/our?
Nothing the matter with our for class attributes since they're
already stored in the package if we follow Perl 5's lead. But using
my for instance attributes is problematic if we allow a class to
be reopened:
class Blurfl {
my $.foo;
}
...
class Blurfl is continued {
print $.foo;
}
This violates the Perl 6 rule that my is always limited to a block.
That's why we came up with attr, which has since mutated to has.
: And...
:
: class Zap {
: my %.zap_cache; # a private classwide attribute
: our $.zap_count = 0; # a public classwide attribute
:
: has $.foo;
: has $.bar;
: }
:
: It may be that $.zap_count is public not so much because of the class
: definition
: where it would default to private, but because $.zap_count's real
: global name is
: $Zap::.zap_count. To get a public accessor method you might still
: need to declare
: it public. And you could get a public accessor method to the my
: variable as well
: the same way.
:
: So:
:
: class Zap {
: my %zap_cache; # var, lexical
: my %.zap_cache;# class attr, lexical
: my %.zap_cache is public; # class attr, lexical/public
: our $zap_count = 0;# var, lexical/global
: our $.zap_count = 0; # class attr, lexical/global
: our $.zap_count = 0 is public; # class attr, lexical/public/global
: has $.foo; # instance attr, lexical
: has $.bar is public; # instance attr, lexical/public
: }
:
: Yes?
No yes till Apo 12. :-)
And probably not yes then. These are all provisional notions.
Note that attr only lasted a month...but then, I said when I made
it up in Zurich that it was a placeholder because I couldn't think of
anything better. And the whole public/private thing is a placeholder
for whatever we eventually come up with to deal with access control.
We're just as likely to end up with is rw or some such, especially
if we decide to allow you to declare attributes that are readable
but not writeable through the class interface.
: What about something like:
:
: my $.foo; # private instance attr
: our $.foo; # public instance attr
:
: my $foo;# as p5
: our $foo;# as p5
:
: MY $.foo; # private class attr
: OUR $.foo; # public class attr
:
: MY $foo;# invalid?
: OUR $foo;# invalid?
:
: method bar; # public instance method
: my method bar; # private instance method
: our method bar; # public instance method
: MY method bar; # private classmethod
: OUR method bar; # public classmethod
Doesn't do much for me. I think it's a mistake to overload my/our with
private/public distinctions because we might also want to distinguish
read/write. More subtly, it changes the me of my/our to mean the
current object or class rather than the current lexical scope, which
is going to be intrinsically confusing.
Plus it's not clear that class attributes are worth SHOUTING over.
It's my gut feeling that class variables are already pretty close to
our variables, so we only need a new word for instance variables,
which have a very different scope from any variables in Perl 5.
Plus I like emphasizing the has/is distinction to help keep people
from using inheritance when they should be using composition.
At least, that's what I like this week...
Larry
Re: perl6 operator precedence table
On Sat, 12 Oct 2002, Dan Kogai wrote:
: Objection, your honor.
:
: perl5 ($x $y) might be uncommon enough to justify this. But how
: about = vs. =, |= vs. ||= ? Those are both used very often so by
: saving one symbol we lose consistency.
Ouch. You're right. That's a bit of a problem for bits($x | $y) too.
Hmm.
a ^|||= 1;
a ^bor= 1;
a ^.|= 1;
Yow. Those are all pretty ugly. But the first one is the least ugly.
And I really do like | for any(). And I can see using it like this:
cases ^|= newcases;
to mean
for cases | newcases - $x is rw | $y {
$x = any($x, $y);
}
Another question is whether using a superposition to represent parallel
streams in for is doing the any concept too much violence. Really,
it's more of a hyper-any, at least on the left:
for cases ^| newcases - $x is rw | $y {...}
But note that ^ automatically gives us the shorter of the two lists.
Maybe...
Just thinking... :-)
Larry
Re: Interfaces
On Fri, 11 Oct 2002, Larry Wall wrote: : You can certainly drop it within the methods, : since there's also the accessor methods. But I should point out that there's a semantic difference between $.foo and .foo, in that $.foo is guaranteed to get my copy of the attribute, while .foo might just go haring off after a virtual method in a subclass, if the subclass puts a wrapper method around this class's .foo method. Larry
Re: Private contracts?
On Sat, 12 Oct 2002, Chris Dutton wrote:
: On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
:
: Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
: From: Larry Wall [EMAIL PROTECTED]
:
: If we use | and as sugar for any() and all(), then their precedence
: should probably be the same as || and .
:
: Should they? I had in mind something just above comparisons. That
: way:
:
: if $x == 3 || $y == 4 {...}
:
: and
:
: if $x == 1 | 2 { ... }
:
: both DWIM. Is there a case for not doing this?
:
: Just a thought, but don't we already have this with the smart match
: operator?
:
: if $x =~ (1, 2) { ... }
Yes, =~ implies an any() around a list. But | could leave out the parens,
presuming the precedence is higher than =~.
: Or would and | be a bit more strict in use, and thus easier for the
: compiler to optimize? For instance, would we be able to:
:
: if $x == 1 | hello { ... }
:
: or would both operands have to be of the same type?
I don't see why they'd have to be the same type. There could well be
good reasons for superposing objects of different types.
Larry
