PDD: Conventions and Guidelines for Perl Source Code
Here's something I promised ages ago, but life got in the way:
first draft of the PDD on all things related to coding: comments,
code structure, naming conventions etc etc. Not as exciting as a Schwartzian
Transform perhaps, but still needs discussion.
I have included comments on bits I'm not sure about - these are marked
by a bar(|) in column 0. I went to town a bit on naming conventions - these
very much reflect my own preferences and biases - folks who are actually
perl src developers (as opposed to pontificators like myself) may wish
to reign me in a bit.
The sections on portability and extensibility need fleshing out, as
these are not my strong point.
I havent bothered prettifiyng the spelling, punctuation and grammar yet,
as I'm assuming revisions will have to be made first.
=head1 TITLE
Conventions and Guidelines for Perl Source Code
=head1 VERSION
=head2 CURRENT
Maintainer: Dave Mitchell <[EMAIL PROTECTED]>
Class: Internals
PDD Number: TBD
Version: 1
Status: Proposed
Last Modified: 7 May 2001
PDD Format: 1
Language: English
=head2 HISTORY
Based on an earlier draft which covered only code comments.
=head1 CHANGES
None. First version
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
wishing to contribute to the source code of Perl, in such areas as
code structure, naming conventions, comments etc.
=head1 DESCRIPTION
One of the criticisms of Perl 5 is that it's source code is impenetrable
to newcomers, due to such things as inconsistent or obscure variable
naming conventions, lack of comments in the source code, and so on.
Hence this document.
We define three classes of conventions. Those that say
I are mandatory, and code will not be accepted (apart from in
exceptional circumstances) unless it follows these rules. Those
that say I are strong guidelines that should normally be
be followed unless there is a sensible reason to do otherwise.
Finally, where it says I, this is tentative suggestion to be used
at your discretion.
Note this this particular PDD makes some recommendations that are specific
to the C programming language. This does not preclude Perl being
implemented in other languages, but in this case,
additional PDDs may need to be authored for the extra language-specific
features.
=head1 IMPLEMENTATION
=head2 Coding style
The following I apply:
| this section mostly stolen from Porting/patching.pod
=over 4
=item *
8-wide tabs
=item *
4-wide indents for code, 2-wide indents for nested CPP #directives
=item *
ANSI C function prototypes
=item *
| anyone know precisely what the following means?
"K&R" style for indenting control constructs
=item *
Uncuddled elses: ie avoid C<} else {>
=item *
No C++ style comments (C): some C compilers may choke on them
=item *
Mark places that need to be revisited with XXX and revisit often!
=item *
When a conditional spans multiple lines, the opening brace must line up
with the "if" or "while", or be at the end-of-line otherwise.
=item *
In function definitions, the name starts in column 0, with the
return type on the previous line
=item *
Single space after keywords that are followed by parens, eg
C, but no space between function name and following paren,
eg C
=back
The following I apply
=over 4
=item *
Do not exceed 79 columns
=item *
C rather than C
=item *
C rather than C etc.
=item *
Avoid assignments in conditionals, but if they're unavoidable, use
Extra paren, e.g. C
=item *
Avoid double negatives, eg C<#ifndef NO_FEATURE_FOO>
=back
=head2 Naming conventions
=over 4
=item Subsystems and APIs
Perl core will be split into a number of subsystems, each with an
associated API. For the purposes of naming files, data structures, etc,
each subsystem will be assigned a short nickname, eg pmc, gc, io.
All code within the core will belong to a subsystem; miscellaneous code
with no obvious home will be placed in the special subsystem called
misc.
=item Filenames
| I'm not familiar with what restictions other OSes (VMS etc) may place
| on filenames. I have written most of what follows based on what
| appears to to be convention in the current Perl 5 src tree.
| In particular, it might be tidier to put all files associated with
| a particular subsystem in their own subdirectory, (eg pmc/foo.h rather
| than pmc_foo.h) - but since perl5 has all its main code in
| a single directory, I'm vaguely assuming there are good portability
| reasons not to do so.
Filenames must be assumed to be case-insensitive, in the sense that that
you may not have two different files called Foo and foo. Normal source-code
filenames should be all lower-case; filenames with upper-case letters
in them are reserved for notice-me-first files such as README, and for
files which need some sort of pre-processing applied to them or which
do the preprocessing - eg a script F might read F
and output F.
The characters making up filenames must be chosen from the ASCII set
Re: Apoc2 - concerns
At 10:57 AM 5/8/2001 -0700, Peter Scott wrote:
>At 10:32 AM 5/8/01 -0700, Larry Wall wrote:
>>: One of the places I hope to gain some speed is in eliminating flattening
>>: and reconstitution of aggregate variables as much as possible. I'm hoping
>>: to exploit this really heavily to save both the memory for the flattened
>>: lists and the time it takes to flatten and reconstitute. (If we're really
>>: lucky we might even be able to rehome some of the underlying data
>>: structures, making returning a 10M entry hash cost about one pointer
>>: assignment)
>>
>>I suspect one way this saves us a lot of overhead is in knowing how
>>much memory to allocate for a given subroutine's stack frame. The way
>>it is done in Perl 5, we pay the variadic stack overhead even on
>>subroutines that are known not to be variadic. This is suboptimal,
>>since you have to be ready to extend the stack at any moment. (It also
>>tends to pessimize linkage into pseudo-variadic languages like C.)
>
>Um, how do you know for sure a subroutine isn't variadic? Even if it has
>a fixed-length prototype, is Perl smart enough to know that it can't be
>called as an object method, bypassing prototype checking?
Why assume that method calls will bypass prototype checking?
Larry and I were sort of talking about different things, too. I was
contemplating the case of return values that looks like:
sub bar {
my @foo;
$foo[time]=1;
return @foo;
}
while Larry seems to be talking about passing parameters into subs. Both
are certainly issues, and related ones. (I'd not given passing parameters
in much thought)
The optimizer's in a pretty good position to figure out exactly what you're
doing if it's given enough time to do it in. By the time it gets the
bytecode, there's not a whole lot of uncertainty left. (If I'm lucky, and
yes I know we'll have stuff like $foo->$bar to contend with, however the
syntax ultimately goes)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: PDD: Conventions and Guidelines for Perl Source Code
I see nothing about namespacing, e.g. Perl_ Alan Burlison
Re: apo 2
Me wrote: > And, despite perl5's use of no as the opposite > of use, and given that there may be no use in > perl6 (;>), and thus perhaps no no, (on and off?), > then maybe no could be used as not yes? Well clearly "on" is the opposite of "no". Yes? -- John Porter
Re: Apoc2 - concerns
Larry Wall wrote: > We're not so far off of a yield-like > method on continuations here... > ... ordinary blocks that can function as continuations > to the surrounding list context. Ah! Now we're talking! -- John Porter
Re: apo 2
> Well clearly "on" is the opposite of "no". Yes? maybe, as in: my cat maybe Dog; for some form of relaxed typing constraint.
Re: Apoc2 - concerns
At 12:58 PM 5/8/2001 -0700, Larry Wall wrote: >Simon Cozens writes: >: On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote: >: > Bit of a digression; but, the dynamicity of a language is in >: > no way implicated by the number of methods in one build-in >: > class. (Besides, this class will have at least three.) >: >: Ooh, at least three. Again, why special-case a class that's inextensible? > >It's not clear that it isn't. We're not so far off of a yield-like >method on continuations here, except that yield statements typically >assume the current sub as the continuation object. Perhaps Perl 6 >will have ordinary blocks that can function as continuations to the >surrounding list context. It's a long shot, but ya never know, ya know. Why, want them? I certainly do... (They smell like lazy subs and/or iterators to me, and I rather like those :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - concerns
* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]: > > Taking history into account is good, though I'd argue that now is the > proper time to change history, if we're going to change. Perl would > never have been accepted in the first place had it been too different > from what came before, but now that Perl has its own momentum, we can > now look at how our own history gets in our way, and maybe do something > about it. Very true. To this end I just would add that I think many JAPHs are used to and like <> as readline. I know I do. I'm not going to harp on this point endlessly, but this is one aspect that I do like about Perl. And keep in mind that unlike "->" vs "." , *everyone* knows about . It is as pervasive as $ and @. That being said, I'm open to the idea of simply replacing <> with < and tweaking the semantics a little. For one thing, it's a char shorter. For another, there's a > equivalent. So: $x = <$STDIN;# "read" from STDIN.more So < could mean "more" and > could mean "less". Or something like that. Whether or not > was implemented in 6.0 is unknown, but having that analogous functionality may be interesting. @a = <$STDIN[0..3]; # @a = ($STDIN.more)[0..3] @b = >$STDIN[0..3]; # @a = ($STDIN.less)[0..3] "more" and "less" could be inverses, "more" reading from the current position forward and "less" from the current position backwards. This notion could be generalized to files/networks/stacks/datastructs/etc/etc. > I think someone mentioned qh() for "hash". That's a possibility, but I'd > still love to have enough brackets to give all of these standard shortcuts. It is worth noting that qr// has no true shortcut. That is these: $x = /\w+/; $x = "\w+"; Are definitely not the same as this: $x = qr/\w+/; I also think that looking at qr// or qw// as being in the same class as qq// is not 100% accurate. Really, qw// is a special type of q// that also splits on whitespace. > : > We don't actually have a good > : > notation for forcing a scalar context yet, let alone a scalar context > : > wanting a certain number of arguments. > : > : Personally, I'd look at it differently. I don't think that getting a number > : of arguments out of a scalar context makes sense. Rather, I think you need > : to call a member function or do whatever to get a list, then lazily evaluate > : that. > : > :@a = $STDIN;# @a gets a single element - $STDIN > :@b = <$STDIN>; # @b gets the entire contents of $STDIN > :# iterations via calls to more() > > You don't actually get the entire contents of $STDIN. You get a value > of $STDIN marked as a placeholder in the list assigned to @b, and that > placeholder says the RHS requested expansion of this in a manner > appropriate to the context supplied by the LHS. > > Assuming Perl 5 semantics of = continue, a similar thing will happen > when you say: > > @a = @b; > > or > > push(@c, @b); > > Perl 6 might not put all the elements of @b on the stack as a temporary > list. Rather, it might just put \@b marked as expandable. (It might > also have to put some kind of copy-on-write lock on @b to keep it from > changing out from under, depending on how lazy the assignment (or > subroutine) actually gets about reading out the array.) Nice. > In this view, * and < could just be two different kinds of "expandable" flags. > But I'm uncomfortable with that, because I'd like to be able to say > > lazy_sub(<$STDIN, <$STDIN, <$STDIN, <$STDIN) > > to feed four lines to lazy_sub without defeating the prototype, er, > signature checking. Maybe you have to us *<$STDIN to do both. But that > would probably say to slurp the whole rest of the file. That would be my guess. Assuming < instead of <>, how about lazy_sub(<$STDIN[0..3]); # same as ($STDIN.more)[0..3] lazy_sub(*<$STDIN); # same as ($STDIN.more)[0..-1] I would define * and < as: * - greedy glob/list flattener < - more iterator > - less iterator All of those are unary, of course. > : Basically, <> is left as direct access to the iterator, but it's not > : magically called except where it clearly make sense (and I don't think > : normal variable manip like passing into subs and hashes should be in this > : category). > : > : > $<$STDIN # Return one element regardless of context. > : > <$STDIN # Return number of element wanted by context. > : > @<$STDIN # Return all element regardless of context. > : > > : > or some other casting mechanism yet to be devised. > : > : I'd do a variation on the above. Looking from a functional perspective: > : > : $STDIN.more # context-dependent > : ($STDIN.more)[0..3] # just selected elements (lazily) > : ($STDIN.more)[0..-1] # forced all > : > : Then we'd have the following shorcuts as a side-effect: > : > : <$STDIN> # context-dependent > :(<$STDIN>)[0..3] # just selected elements (l
Re: apo 2
> So bool would perhaps be a synthetic property that has opposite polarity > from bit? I can see that, sort of. It's something like electrons being > negative, thank you Mr. Franklin. s/bit/yes/ yes? And, despite perl5's use of no as the opposite of use, and given that there may be no use in perl6 (;>), and thus perhaps no no, (on and off?), then maybe no could be used as not yes? no?
Re: Apoc2 - concerns
At 01:19 PM 5/8/2001 -0700, Nathan Wiger wrote: >* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]: > > > > Taking history into account is good, though I'd argue that now is the > > proper time to change history, if we're going to change. Perl would > > never have been accepted in the first place had it been too different > > from what came before, but now that Perl has its own momentum, we can > > now look at how our own history gets in our way, and maybe do something > > about it. > >Very true. To this end I just would add that I think many JAPHs are used >to and like <> as readline. I know I do. I'm not going to harp on this >point endlessly, but this is one aspect that I do like about Perl. And >keep in mind that unlike "->" vs "." , *everyone* knows about . >It is as pervasive as $ and @. > >That being said, I'm open to the idea of simply replacing <> with < and >tweaking the semantics a little. For one thing, it's a char shorter. For >another, there's a > equivalent. The one thing I worry about with a single-character readrecord character is determining when someone's reading from the default filehandle. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - Context and variables
* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 10:11]: > > Nathan Wiger writes: > : First off, before I forget to mention it, nice job on Apoc2 Larry! You are > : the man. I know alot of us on p6l can seem like harsh critics at times, but > : it's only because we love Perl so much. ;-) > > We'll have to do something about that. :-) Yes, please, it's taking up my life writing so much of it! ;-) [stuff that sounds great deleted] > : Also, I like the *@b prototype slurping idea a lot, but I do worry about > : potential confusion with the @*b special class notation. I'm wondering if > : the latter can't be @::b? > > I wanted to keep true globals out of Main (presuming for the sake of > argument that the bare :: still indicates the user's main package). I guess that's what I was getting at: do we want :: to mean "main"? Is this more useful that meaning "CORE"? The vast majority of the time I've seen bare :: used I've seen stuff like this: @::ARGV = @something; unshift @::INC, '/my/lib'; If these are all going to be in CORE (personally, I'd much prefer a different namespace than main), then it seems like a better use of :: would be meaning CORE. It would actually reduce user confusion, since @::INC and @::ARGV would mean the same thing in P6 as P5 (the package will just have changed transparently). -Nate
Re: Apoc2 - concerns
Nathan Wiger wrote: > So < could mean "more" and > could mean "less". That would sure confuse the math subcommunity! ;-) > "more" and "less" could be inverses, "more" reading from the current > position forward and "less" from the current position backwards. This > notion could be generalized to files/networks/stacks/datastructs/etc/etc. Ugck. < means read, > means write. Do you want to be that different from shell? Or from Perl, for that matter? -- John Porter All men are subjects.
Re: Apoc2 - concerns
Larry Wall wrote: > Ordinary "next" methods don't do a goto. Well, of course, the "next" method of a syntactic loop control iterator object would not be ordinary. :-) -- John Porter
Re: Apoc2 - concerns
Dan Sugalski writes: : At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: : >Perl 6 might not put all the elements of @b on the stack as a temporary : >list. Rather, it might just put \@b marked as expandable. (It might : >also have to put some kind of copy-on-write lock on @b to keep it from : >changing out from under, depending on how lazy the assignment (or : >subroutine) actually gets about reading out the array.) : : s/might not/won't/; : : One of the places I hope to gain some speed is in eliminating flattening : and reconstitution of aggregate variables as much as possible. I'm hoping : to exploit this really heavily to save both the memory for the flattened : lists and the time it takes to flatten and reconstitute. (If we're really : lucky we might even be able to rehome some of the underlying data : structures, making returning a 10M entry hash cost about one pointer : assignment) I suspect one way this saves us a lot of overhead is in knowing how much memory to allocate for a given subroutine's stack frame. The way it is done in Perl 5, we pay the variadic stack overhead even on subroutines that are known not to be variadic. This is suboptimal, since you have to be ready to extend the stack at any moment. (It also tends to pessimize linkage into pseudo-variadic languages like C.) Larry
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote: > a syntactic loop control iterator object I surely hope you're joking. -- I respect faith, but doubt is what gives you an education. -- Wilson Mizner
Re: Apoc2 - concerns
At 10:32 AM 5/8/01 -0700, Larry Wall wrote: >: One of the places I hope to gain some speed is in eliminating flattening >: and reconstitution of aggregate variables as much as possible. I'm hoping >: to exploit this really heavily to save both the memory for the flattened >: lists and the time it takes to flatten and reconstitute. (If we're really >: lucky we might even be able to rehome some of the underlying data >: structures, making returning a 10M entry hash cost about one pointer >: assignment) > >I suspect one way this saves us a lot of overhead is in knowing how >much memory to allocate for a given subroutine's stack frame. The way >it is done in Perl 5, we pay the variadic stack overhead even on >subroutines that are known not to be variadic. This is suboptimal, >since you have to be ready to extend the stack at any moment. (It also >tends to pessimize linkage into pseudo-variadic languages like C.) Um, how do you know for sure a subroutine isn't variadic? Even if it has a fixed-length prototype, is Perl smart enough to know that it can't be called as an object method, bypassing prototype checking? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Apoc2 - concerns
Simon Cozens wrote: > John Porter wrote: > > a syntactic loop control iterator object > > I surely hope you're joking. Why? It sounds reasonable to me (if not necessarily desirable). Perl is a highly dynamic language, I think it could support this. -- John Porter
Re: Apoc2 - Context and variables
Nathan Wiger writes: : First off, before I forget to mention it, nice job on Apoc2 Larry! You are : the man. I know alot of us on p6l can seem like harsh critics at times, but : it's only because we love Perl so much. ;-) We'll have to do something about that. :-) : Anyways, in addition to the $file.next stuff, I'm curious about a few : clarifications on the new semantics of arrays and hashes. Overall it looks : outstanding. I'm interested in what happens with interactions: : :$a = @b; : : Does this: : :1. Get the length (doesn't seem to make sense now) :2. Pull a reference to @b (like Perl5's "$a = \@b") :3. Get the first element of @b Scalar context always gets the reference, even for &func in the absence of parens. : Similarly, how about: : :%c = @d; : : Does this: : :1. Create a hash w/ alternating keys/vals like Perl5 :2. Do the equivalent of "%c = \@d" in Perl5 :3. Or the mystery meat behind Door #3 I expect it's mystery meat. #1 is probably done by some equivalent to: %c = pairify @d; The bare assignment probably provides hashlist context to the right side, which treats => elements as pairs, and other elements as keys for which a default value should be assumed. That default value is likely a property of target hash object (or perhaps of the %c variable object, which is not quite the same thing). : Also, I like the *@b prototype slurping idea a lot, but I do worry about : potential confusion with the @*b special class notation. I'm wondering if : the latter can't be @::b? I wanted to keep true globals out of Main (presuming for the sake of argument that the bare :: still indicates the user's main package). Mostly @*FOO is just a shorter way to say @CORE::FOO. The actual character is negotiable. I've considered using $:FOO with one colon, but held off on that under the assumption that $: might be a unary typecast meaning scalar(). But there's something to be said for using $=, @=, %=, for unary typecasts, so that would free up : to use in $:STDIN and such. In any event, I'm not too worried about confusion between *@foo and @*foo, since people will usually use the @foo form anyway for the global. Leaving people confusion out of it, the computer won't get confused unless people start trying to call global subroutines without a leading &: @lines = *glob(...) But I think we'd have just about as much problem with almost any other character we pick. It's still possible we could preserve : sufficiently to allow its use as a unary, so that @lines = :glob(...) would unambiguously mean core glob(). But probably not, given how many things want a piece of : yet, even after giving properties the heave ho on that score. So my thinking was, let's leave it as $*STDIN for the moment, and consider it a placeholder for something that might or might not become obvious at a later time. Meanwhile, we know we can always write &*glob() in the rare cases we really need to. Larry
Re: Apoc2 - concerns
Peter Scott wrote: > Even if it has a > fixed-length prototype, is Perl smart enough to know that it can't be > called as an object method, bypassing prototype checking? Maybe p6 won't have that loophole. -- John Porter
Re: Apoc2 - concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote: : > a syntactic loop control iterator object : : I surely hope you're joking. It could certainly be argued that anything you can put a label on is an object by some definition or other. And certainly it turns into a kind of parse tree object to which the label can be pasted. And while the parse tree object is hopefully totally static, the use of it in a dynamic context may require keeping track of some amount of state, which we might deign to keep in an object of some sort or other. Whether there's any point in making these internal objects visible to the user is another matter indeed. It's possible to view Perl 5 as full of objects that the user has no direct access to. Just because Perl 6 might give more access to some of these internal objects does not mean that most people can't go blissfully on their way in ignorance of the underlying mechanisms. larry
Re: Apoc2 - concerns
John Porter writes: : Peter Scott wrote: : > Even if it has a : > fixed-length prototype, is Perl smart enough to know that it can't be : > called as an object method, bypassing prototype checking? : : Maybe p6 won't have that loophole. It won't, if the type of the object can be determined at compile time. If you declare C, it'll be assumed you're calling methods that are consistent with the declarations in the Dog interface, even if it happens to be a Poodle or a Chihauhau. I hope that named argument notation of some sort will prevent this from being a burden on subclasses that wish to extend methods of base classes that weren't defined to be sufficiently extensible in the first place. But I could be wrong... Larry
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: > > > a syntactic loop control iterator object > > Why? It sounds reasonable to me I'm sure a "pure virtual base template class" sounds reasonable to a C++ programmer, but that doesn't mean it's the clearest thing in the world. :) -- Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity.
Re: Apoc2 - concerns
At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: >Perl 6 might not put all the elements of @b on the stack as a temporary >list. Rather, it might just put \@b marked as expandable. (It might >also have to put some kind of copy-on-write lock on @b to keep it from >changing out from under, depending on how lazy the assignment (or >subroutine) actually gets about reading out the array.) s/might not/won't/; One of the places I hope to gain some speed is in eliminating flattening and reconstitution of aggregate variables as much as possible. I'm hoping to exploit this really heavily to save both the memory for the flattened lists and the time it takes to flatten and reconstitute. (If we're really lucky we might even be able to rehome some of the underlying data structures, making returning a 10M entry hash cost about one pointer assignment) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 09:44:57AM -0700, Larry Wall wrote:
> there seems to be a shortage of three-humped camels.
No wonder we're short, they're rather careless with them...
The Three-humped Camel:
An advertisement once appeared in a Welsh local paper which
read: 'Last - one three-humped camel. Owner desperat.
Reward.' A telephone number was given for people to ring. The
landlord of the local pub was not very pleased. It was his number
that had been given and over 70 people rang him, claiming to
have seen his non-existent camel.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
grep { ref and ref !~ /^[A-Z]+$/ } kill 9, @ARGV;
Re: apo 2
: > >is => typing, inheritance, etc.
: > >has => composition, aggregation, etc.
: >
: > True, but those are basic OO concepts, which don't neatly apply to
: > property-lists (a very old Lisp concept that Perl6 is adopting).
Well, you can think of it like that, but I'm actually trying for some
happy medium, where properties are a cheap form of inheritance, or
perhaps delegation, much like David suggests below.
David Whipp writes:
: "is" does seem to imply an OO is-a relationship. So lets run
: with it!
:
: If $foo is an object of type INTEGER, then $foo.bit calls a
: method that compares the numeric value against 0 and returns
: 1 if not zero.
:
: If $foo is true, then its method $foo.bit is expected to return
: 1.
:
: In OO terms, when you override the behaviour of your methods, you
: are usually subclassing. So perhaps the declaration "$foo is true"
: should literally mean: "create an anonymous subclass derived from
: $foo's class that overrides its .bit method to return 1; change
: $foo's class to this new subclass" Multiple "is" declarations
: would simply stack up the subclasses.
Yes, I'm thinking of it more in terms of delegation, since we probably
wouldn't dup the vtables, but that's the general idea.
: If "true" is a class with a single method "sub .bit { return 1 }",
: then the subclass of $foo is creating by copying "true"'s methods.
: So "$foo is myClass" simply means that we subclass $foo with a
: clone of myClass. "constant" would be a class that overrides the
: assignment operator.
I had thought about this some. It's actually possible to do anonymous
subclassing, but to do it efficiently, we'd probably need to coalesce
vtables that are structurally type equivalent. (Obviously you
can't have name equivalence when the subtypes are anonymous, so that's
not really a problem.)
: On a slightly different note, I read that "my Dog $foo" doesn't
: call a ctor. I do hope that "my URL $name; ...; $name="www.foo.bar"
: does DWIM.
Depends on what you mean. And just because C doesn't
call a constructor doesn't mean that C won't.
: p.s. I prefer to paint my bikeshed's true and false as .bool, not
: .bit. In the hardware world, the distinction is important because
: we often slip into negative logic.
So bool would perhaps be a synthetic property that has opposite polarity
from bit? I can see that, sort of. It's something like electrons being
negative, thank you Mr. Franklin.
Larry
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote: > Perhaps Perl 6 will have ordinary blocks that can function as continuations > to the surrounding list context. OK, now you've broken my brain. Can you give me an example that is i) useful and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it has little business being in the "blue-collar language" we call Perl. -- Feed me on TOASTIES! There's no HALL for PHILOSOPHERS on FRIDAYS. - Henry Braun is Oxford Zippy
Re: apo 2
Me writes: : > So bool would perhaps be a synthetic property that has opposite : polarity : > from bit? I can see that, sort of. It's something like electrons : being : > negative, thank you Mr. Franklin. : : s/bit/yes/ : : yes? : : And, despite perl5's use of no as the opposite : of use, and given that there may be no use in : perl6 (;>), and thus perhaps no no, (on and off?), : then maybe no could be used as not yes? : : no? If you're trying to confuse me, I can assure you it's unnecessary. ;-) Larry
Re: Apoc2 - concerns
At 09:42 PM 5/8/2001 +0100, Simon Cozens wrote:
>On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote:
> > Perhaps Perl 6 will have ordinary blocks that can function as continuations
> > to the surrounding list context.
>
>OK, now you've broken my brain. Can you give me an example that is i) useful
>and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it
>has little business being in the "blue-collar language" we call Perl.
@foo = ({scalar each %some_tied_hash});
with the function being called only when you access a particular element?
(Presumably calling it for elements 0-9 and caching them if the first
element you access is 10)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apoc2 - concerns
Simon Cozens wrote: > Can you give me an example that is i) useful > and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it > has little business being in the "blue-collar language" we call Perl. Rather than head off down this time-wasting tangent yet again, I refer readers to the archived discussions of RFC28. Suffice it to say that, contrary to some opinions, OO and FP are useful to more than just CS graduates. Part of Perl being Perl is being something greater than a lowest common denominator. -- John Porter
Re: Apoc2 - concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote: : > Bit of a digression; but, the dynamicity of a language is in : > no way implicated by the number of methods in one build-in : > class. (Besides, this class will have at least three.) : : Ooh, at least three. Again, why special-case a class that's inextensible? It's not clear that it isn't. We're not so far off of a yield-like method on continuations here, except that yield statements typically assume the current sub as the continuation object. Perhaps Perl 6 will have ordinary blocks that can function as continuations to the surrounding list context. It's a long shot, but ya never know, ya know. Larry
Re: apo 2
> If you're trying to confuse me, I can assure you it's unnecessary. ;-) Hey, I try. --me (Under cover Ruby/Python agent and promotor of RFCs 380 thru 1,000,000)
Re: Apoc2 - concerns ::::: new mascot?
Larry Wall wrote: > there seems to be a shortage of three-humped camels. At last! the unencumbered image for the mascot! Could O'Reilly really claim a three-humped camel was an image of a camel, with a straight face?
Re: Apoc2 - concerns
John Porter writes: : Pardon me if someone has already suggested this, but... : Couldn't labels really be (aliases to) iterator objects? : So that : next FOO : really *does* mean : FOO.next Ordinary "next" methods don't do a goto. Larry
Re: Apoc2 - concerns
Nathan Wiger writes:
: One thing I think we should avoid is as many "special cases" as possible.
: This is already why people hate <> currently - because it does both glob()
: and readline().
:
: I would say that <> having history is actually a good thing. It's a
: foundation, really, since readline() is an iterator of sorts. All we'd be
: doing is generalizing the notion. Not only does it apply to files, but it's
: a shortcut to more() wherever you feel like using it.
Taking history into account is good, though I'd argue that now is the
proper time to change history, if we're going to change. Perl would
never have been accepted in the first place had it been too different
from what came before, but now that Perl has its own momentum, we can
now look at how our own history gets in our way, and maybe do something
about it.
: As for <> as a qw() replacement, I think there are really two issues here.
: First, you're not really talking about a "replacement", since you're
: mentioning different semantics. So qw() will still be widely used. I suggest
: that we simply create another q-op to do the qw-ish things you're proposing.
: Perhaps qi() for "interpolate" or something else.
I think someone mentioned qh() for "hash". That's a possibility, but I'd
still love to have enough brackets to give all of these standard shortcuts.
: Plus <> has the terrible
: problem that the POD C<> stuff does w/ embedded > chars. The really nice
: thing about the q's is you can choose any bracket you want. I think fleshing
: out this series of constructs makes the most sense.
No problem with that, though we probably need to reserve qA .. qZ for
the user.
: I'd so this differently, as hinted at above:
:
:%foo{<$STDIN>};# return all values
:%foo{<$STDIN); # return one value
:%foo{$STDIN}; # pass the $STDIN variable
Syntactically speaking it's too ambiguous to have both a unary < and a
bracketing <>.
: This is assuming that we want < to exist and have a different semantics. But
: I'm not sure that's a good idea. For one thing, you'd have to mention it
: several times if you want a couple values. I think there's got to be a
: better way to request the number of lines based on context.
:
:%foo{<$STDIN>}; # the whole thing
:%foo{ (1..2) = <$STDIN> }; # anonymous list request?
:%foo{ <$STDIN>[1..2] }; # or notate it as a list?
:%foo{ ($STDIN.more)[1..2] }; # same thing
:
: The last one seems to make sense (it's got those (localtime)[2,3] roots),
: with the third one as a shortcut.
:
: > Looking at it from the iterator object end, there might really be three
: > methods:
: >
: > $STDIN.next # Return one element regardless of context.
: > $STDIN.more # Return number of element wanted by context.
: > $STDIN.all # Return all element regardless of context.
: >
: > Or maybe there's only a "more" method, and you simply have to force the
: > context if you don't want it to guess.
:
: I think one method is the way to go. Let the subs and other contexts request
: the number of elements to get back using lazy evaluation:
:
:@foo[1..10] = <$STDIN>; # get 10 iterations
:$bar = <$STDIN>;# next one
:&lazy_sub(<$STDIN>);# lazily
:
: Assuming:
:
:sub lazy_sub ($a, $b, $c, $d) { }
:
: Then the last line above would lazily grab the next four lines.
I'd say that interpretation makes it a non-greedy equivalent to the
unary *, in that it defeats the prototype, er, signature. That would
be an argument for unary <, I think.
: > We don't actually have a good
: > notation for forcing a scalar context yet, let alone a scalar context
: > wanting a certain number of arguments.
:
: Personally, I'd look at it differently. I don't think that getting a number
: of arguments out of a scalar context makes sense. Rather, I think you need
: to call a member function or do whatever to get a list, then lazily evaluate
: that.
:
:@a = $STDIN;# @a gets a single element - $STDIN
:@b = <$STDIN>; # @b gets the entire contents of $STDIN
:# iterations via calls to more()
You don't actually get the entire contents of $STDIN. You get a value
of $STDIN marked as a placeholder in the list assigned to @b, and that
placeholder says the RHS requested expansion of this in a manner
appropriate to the context supplied by the LHS.
Assuming Perl 5 semantics of = continue, a similar thing will happen
when you say:
@a = @b;
or
push(@c, @b);
Perl 6 might not put all the elements of @b on the stack as a temporary
list. Rather, it might just put \@b marked as expandable. (It might
also have to put some kind of copy-on-write lock on @b to keep it from
changing out from under, depending on how lazy the assignment (or
subroutine) actually gets about reading out the array.)
In this view, * and < could just be two different kinds of "expandable" flags.
But I'm uncomfortable with that, because I'd like to be able to sa
Re: what I meant about hungarian notation
> push chairs, map {woodworking} treestumps;
>
or even
push chairs, map BLOCK(woodworking) treestumps;
qX (was Re: Apoc2 - concerns)
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Please pardon my hyperbole. I don't loathe qw() so badly that I LW> want to get rid of it. I merely want to put it in the same status LW> as the other general quote operators that also have a non-general LW> pair of standard quote characters. I would feel the same about LW> qq// if there weren't a "". larry, we forgive you. but can you understand our concern? you did use very strong language describing your negative feelings about qw without the context you provided above. but now a question arises, why must there be a non-q version of qw to be symmetrical with "/qq? i (and i sense many others) feel that qw by itself is fine and stealing <> for it is not a great use of precious funny chars. and if there is an extension as i have proposed of other qX operators, then you won't be able to make them all have funny char counterparts. speaking of qX and qh in particular, i realized that supporting a way to have => as a key or value is not worth the effort. just as with qw and embedded white space, if you want complex data, use a normal list of quoted strings. qw and qh are meant as shortcuts for common and simple data sets. embedded white space and => as a string are not simple. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Apoc2 - concerns
Lipscomb, Al writes:
: --_=_NextPart_001_01C0D71B.8F67C8EA
: Content-Type: text/plain;
: charset="iso-8859-1"
:
:
: >
: > $$STDIN # Return one element regardless of context.
: > @$STDIN # Return number of element wanted by context.
: > *$STDIN # Return all element regardless of context.
: >
:
: How about
:
:
: $STDIN.$ # Return one element regardless of context.
: $STDIN.@ # Return number of element wanted by context.
: $STDIN.* # Return all element regardless of context.
Well, those would be the same thing according to the identity:
word $obj
$obj.word
if you consider '$', '@', and '*' as words. There's some destructive
interference with the Perl 5 dereferencing meaning, which probably
means that casts can't simply be funny characters when there's a $ on
the inside. That's why I was looking at $: and $< variants. But
there's also the $() and @() variants, which we've already said will do
interpolation of scalar and list expressions in strings. So $($foo)
probably means a cast rather than a dereference like ${$foo} (note
curlies). I suppose it's fair to ask whether $$foo ought to mean the
first rather than the second, but that's definitely going again history
to make it a cast.
Larry
Re: Apoc2 - concerns
At 16:17 May 7, Simon Cozens wrote: >On Mon, May 07, 2001 at 01:14:12PM -0700, Nathan Wiger wrote: >> I think Uri's qh() suggestion is the cleanest: > >Interesting train of thought, since one of the ideas was that qw() is >ugly and has to go. (Larry's been saying this for nearly two years now, >it's just that people sometimes don't listen. :) Let's keep it and add >something similarly ugly to keep it company! > >-- >And the fact is, I've always loathed qw(), despite the fact that I >invented it myself. :-) > -- Larry Wall in <[EMAIL PROTECTED]> Well, one person's ugly is another person's joy forever. Regardless of the aesthetics of q//, qq//, qw//, et al, (and here docs too), they get the job done in a remarkably flexible, efficient way that is simply not possible with just about any other language out there. 9 times out of 100, qw saves a large number of keystrokes. (The other 1% of the time, you have to work around qw's inability to quote things with spaces). qq, q, and here-docs may be "ugly", but that's a judgment call. What they are not is "broken". Personally, I don't understand how using two alphabetic characters and a pair of delimiters, in order to save typing a whole mess of quotes and backslashes, can be construed as "ugly". :-) And, while I'm on my soapbox here, I don't get how <...> is a vast improvement over qw<...>. :-) -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote: > Nothing changes at the syntactic level. Then I call Occam's Razor. Perl is supposed to be easy, no? -- And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones
Re: Apoc2 - concerns
Nathan Wiger wrote: > > I think Uri's qh() suggestion is the cleanest: me too > And it would make hash declarations cleaner: > >%hash = qh( > foo > bar > jim => 'bob' > var >); > > Plus maybe even a pragma to set the default value: > > use default hashval => 'closed'; > ... Looks like a job for a new LineNoiseVar. is $% anything yet? format_page_number HANDLE EXPR $FORMAT_PAGE_NUMBER $% The current page number of the currently selected output channel. (Mnemonic: % is page number in nroff.) how about $% is that if we are using, umm, the format module, or the $QH_DEFAULT_VALUE if we aren't. Or go to $%%. Additionally, the qh syntax could very easily become a packed-structure sytnax.
Re: Apoc2 - concerns
Simon Cozens writes: : On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote: : > Not that there are any such people. Yet. : : Indeed. And I suspect that the first Perl 6 programmers are Perl 5 : programmers, who know damned well what "next FOO" means. Well, it's certainly the case that "next" by itself has to infer a much different "object" than, say, "length" by itself. I don't think anybody is going to argue with you that "next" has to be treated specially. My original point was merely that the parser could be parsing it that way, not that it didn't have extraordinary semantics once parsed. The exception would be at the semantic binding level, not at the parsing level. That's all. Larry
Re: Apoc2 - concerns
Simon Cozens <[EMAIL PROTECTED]> writes: > On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: > > Perl is a highly dynamic language > > An object with exactly one and only one method doesn't sound that > dynamic to me. Three methods, surely: next, last, redo. -- Piers Cawley www.iterative-software.com
Re: Apoc2 - concerns
At 10:32 AM 5/8/2001 -0700, Larry Wall wrote: >Dan Sugalski writes: >: At 09:32 AM 5/8/2001 -0700, Larry Wall wrote: >: >Perl 6 might not put all the elements of @b on the stack as a temporary >: >list. Rather, it might just put \@b marked as expandable. (It might >: >also have to put some kind of copy-on-write lock on @b to keep it from >: >changing out from under, depending on how lazy the assignment (or >: >subroutine) actually gets about reading out the array.) >: >: s/might not/won't/; >: >: One of the places I hope to gain some speed is in eliminating flattening >: and reconstitution of aggregate variables as much as possible. I'm hoping >: to exploit this really heavily to save both the memory for the flattened >: lists and the time it takes to flatten and reconstitute. (If we're really >: lucky we might even be able to rehome some of the underlying data >: structures, making returning a 10M entry hash cost about one pointer >: assignment) > >I suspect one way this saves us a lot of overhead is in knowing how >much memory to allocate for a given subroutine's stack frame. The way >it is done in Perl 5, we pay the variadic stack overhead even on >subroutines that are known not to be variadic. This is suboptimal, >since you have to be ready to extend the stack at any moment. (It also >tends to pessimize linkage into pseudo-variadic languages like C.) Yup, I definitely want to get things in a position to optimize fixed-input subs, if possible. Might eevn be able to do something like: PMC *foo(); fetch_perl_sub_pointer(&foo, "bar"); my_pmc = foo(12); give or take bad C syntax on my part. I was contemplating the case where subs return huge arrays and lists, though, rather than the case where they're passed them. (I have a nasty habit of writing code that passes around monster arrays and hashes, so I tend to feel it more) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Property/method naming conventions
Simon Cozens writes:
: This also led me to think about what happens when we introduce new built-ins.
: Perl 5 has had a complete built-in freeze for a long long time now because
: you can't bring in a new built-in without risking smacking subroutines in
: old code.
Right, that's been an impediment to continuing evolution.
: We can get around that in Perl 6 by reversing the precedence: let user-defined
: subroutines and methods take priority over built-ins. This would allow for
: easy overloading ("sub open { ... }") and give us forward-compatibility. (If
: you want to be sure you're working with built-in open, just use CORE::open)
Yes, that's what we're doing. Make everything a core method that can
be a method, make everything else a core subroutine, still overridable.
(And try to blur the distinction so people don't much care whether
length() is a method or a subroutine.)
: Maybe something similar for properties.
That's what I thought I said. Real methods always override the fake
methods of run-time properties. (Subtext: don't use properties when
you should be using methods. I'm sure some people would claim that's
always.)
Larry
Re: Apoc2 - concerns
Simon Cozens wrote: > Indeed. And I suspect that the first Perl 6 programmers are Perl 5 > programmers, who know damned well what "next FOO" means. Would it really cause you that much consternation to find, after you've been programming in Perl6 for some months or years, that "next FOO" is actually a method call on a loop control object? -- John Porter
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: > Perl is a highly dynamic language An object with exactly one and only one method doesn't sound that dynamic to me. -- Can you sum up plan 9 in layman's terms? It does everything Unix does only less reliably - kt
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 05:11:52PM -0400, John Porter wrote: > > Can you give me an example ... > > Rather than head off down this time-wasting tangent yet again, That smacks of avoiding the question. Again, do you have a useful example? -- You will never find a more wretched hive of scum and villainy.
Re: Apoc2 - concerns
Simon Cozens wrote: > Then I call Occam's Razor. Perl is supposed to be easy, no? It's also supposed to have an implementation. And to have a consistency level somewhat greater than zero. Also, consider the implications for user-defined control constructs. -- John Porter
Re: Apoc2 - concerns
Simon Cozens wrote: > An object with exactly one and only one method doesn't sound that > dynamic to me. Bit of a digression; but, the dynamicity of a language is in no way implicated by the number of methods in one build-in class. (Besides, this class will have at least three.) -- John Porter
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 02:59:09PM -0400, John Porter wrote: > It's also supposed to have an implementation. I think those of us who are actually likely to write a single line of code or more should be concerned with that, thank you. -- [It is] best to confuse only one issue at a time. -- K&R
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote: > Bit of a digression; but, the dynamicity of a language is in > no way implicated by the number of methods in one build-in > class. (Besides, this class will have at least three.) Ooh, at least three. Again, why special-case a class that's inextensible? -- "Nuclear war can ruin your whole compile." -- Karl Lehenbauer
Re: Apoc2 - concerns
[Tom's away at the moment, I'm filling in until he gets back.] -- Asynchronous inputs are at the root of our race problems. -- D. Winker and F. Prosser
Re: Apoc2 - concerns
From: "Larry Wall" <[EMAIL PROTECTED]> To: "Eric Roode" <[EMAIL PROTECTED]> Sent: Tuesday, May 08, 2001 11:03 AM Subject: Re: Apoc2 - concerns > Eric Roode writes: > : And, while I'm on my soapbox here, I don't get how <...> is a vast > : improvement over qw<...>. :-) > Please pardon my hyperbole. I don't loathe qw() so badly that I want > to get rid of it. I merely want to put it in the same status as the > other general quote operators that also have a non-general pair of > standard quote characters. I would feel the same about qq// if there > weren't a "". Might I suggest, then, that instead of making a synonym for qw, we use it for iterators, and use <> (by which I mean the "<" character twice, not the « character -- though probably either should work). That lets us keep for somthing iteratorish, which saves special-caseing (I do occasionaly use a qw list with one element), and lets us keep continuity. Anyway, I'm fairly certian that I'll use iterators more then qw lists. -=- James Mastros
Re: Apoc2 - Context and variables
Jonathan Scott Duff wrote: > (*%a, %b) = (%c,%d);# %a slurps, %b gets nothing > (%a, *%b) = (%c,%d);# %a = %c, %b gets the rest > > I'm sure your imaginations can twiddle the cardinality knob > appropriate for generalization :-) > > -Scott so if you don't know exactly what the conext is going to be can you defer it with a continuation operator? @split_me_later = ?(%f,%g,%h); ... (%a,*%b) = @split_me_later
Re: Apoc2 - concerns
Simon Cozens wrote:
> I'm sure a "pure virtual base template class" sounds reasonable
> to a C++ programmer, but that doesn't mean it's the clearest thing
> in the world. :)
Nothing changes at the syntactic level.
FOO: while ( $cond ) {
# FOO is now (an alias to) a loop control object...
next FOO;
What's unclear?
In fact, no one needs to know this is going on, except
the guy who wants to know why C looks like
a method call. (And he only thinks that because "next"
looks like a method name.)
--
John Porter
All men are subjects.
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote: > the guy who wants to know why C looks like > a method call It doesn't, any more than "next FOO" looks like a method call in Perl 5 right now. -- > I'm a person, not a piece of property. Happily, I'm both! - Lionel and Stephen Harris.
Re: Apoc2 - Context and variables
I like the lisp-associative-array alternating keys,values nature of the perl5 %hash=@array semantics, and the way it can be used to set defaults in hashref argument lists. The replacement must provide an equivalent but less hacky replacement. -- David Nicol 816.235.1187 [EMAIL PROTECTED] and I shot billiards with a midget 'til the rain stopped
Re: Apoc2 - concerns
Larry Wall wrote:
> Syntactically speaking it's too ambiguous to have both a unary < and a
> bracketing <>.
Cool. Do we get a > operator to use as an l-value, instead of print?
>$log = join localtime, 'difficult cramigudgeo';
> It's possible we're thinking of iterators wrong here. Perhaps
> iterators should typically be stored in @iter, not $iter. Then it's
> pretty obvious that
>
> for (@cases) { }
>
> iterates, because it's in a list context.
but it is not obvious that @cases is an iterator. Unfortunately we don't
have an infinite supply of line-noise to arbitrarily extend this optimized
hungarian notation ($@%&)
for C to do anything interesting, there's something
special about $cases, making iterator-in-scalar more visible than
iterator-in-array,
where it could easily be mistaken for a container instead of a generator.
> I think iterator magic
> always works in list context, and never in scalar.
okay, that disambiguates copy and retrieve handily, guess I'll delete the
five unsent e-mails eulogizing now
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
>@foo = ({scalar each %some_tied_hash});
>
> with the function being called only when you access a particular element?
I'm still confused. Firstly, this doesn't involve first-order blocks, which
was kinda what the entire question was about. Secondly, it isn't clear what it
means. "scalar each" in Perl5-think means "return the first element". (Try:
perl -le '%a=(a=>"b", c=>"d"); print while $_ = scalar each %a') Is this not
merely @foo=(keys %some_tied_hash), which should call the tied functions in
the same way? Not a convincing example, I'm afraid.
--
The problem with big-fish-little-pond situations is that you
have to put up with all these fscking minnows everywhere.
-- Rich Lafferty
Re: Apoc2 - concerns
David L. Nicol writes:
: Larry Wall wrote:
:
: > Syntactically speaking it's too ambiguous to have both a unary < and a
: > bracketing <>.
:
: Cool. Do we get a > operator to use as an l-value, instead of print?
:
: >$log = join localtime, 'difficult cramigudgeo';
I don't think so.
: > It's possible we're thinking of iterators wrong here. Perhaps
: > iterators should typically be stored in @iter, not $iter. Then it's
: > pretty obvious that
: >
: > for (@cases) { }
: >
: > iterates, because it's in a list context.
:
: but it is not obvious that @cases is an iterator.
Except insofar as all arrays are iterators of some sort or other, and
can produce a list in a list context. All lists are created equal,
but some are more equal than others.
: Unfortunately we don't
: have an infinite supply of line-noise to arbitrarily extend this optimized
: hungarian notation ($@%&)
Don't see the need yet. English gets by with $singular and @plural,
and a bit of leftover %dual from Indo-European days. It's pretty
obvious in English from context when you say "miles to go before I
sleep" that the miles come one at a time. It's a kind of iterator. On
the other hand, with "a can of worms", you usually consider that you
get all the worms at once.
: for C to do anything interesting, there's something
: special about $cases, making iterator-in-scalar more visible than
: iterator-in-array,
: where it could easily be mistaken for a container instead of a generator.
:
:
: > I think iterator magic
: > always works in list context, and never in scalar.
:
: okay, that disambiguates copy and retrieve handily, guess I'll delete the
: five unsent e-mails eulogizing now
Well, I was speaking of iterators in @worms, not $worms. I still don't
think $worms should do anything special in list context. Maybe $STDIN
should really be spelled @STDIN. Perhaps iterators really want to
implement a form of highlander variable:
my @worms is alias($worms) tie(Iterator);
or
my $@worms; # highlander declaration
Just shooting my mouth off here, if not my foot...
A argument could also be made that iterators are neither scalars nor
arrays--they're functions.
Doubtless Damian could come up with a way to view them as hashes...
Well, hey, at least we'll all go mad together.
Larry
Re: Apoc2 - concerns
Larry Wall wrote: > > all arrays are iterators of some sort BZZT! HSSS! CLANG! DANGER, WILL ROBINSON! DANGER, WILL ROBINSON
Re: Apoc2 - concerns
John Porter wrote: > > Pardon me if someone has already suggested this, but... > Couldn't labels really be (aliases to) iterator objects? > So that > next FOO > really *does* mean > FOO.next > Marvelous! That also wraps up the "for should have an explicit iterator access method" thread handily! Just label your loop and there you are!
what I meant about hungarian notation
Hungarian notation is any of a variety of standards for organizing
a computer program by selecting a schema for naming your variables
so that their type is readily available to someone familiar with
the notation.
Just as Python is a language that enforces the common practice of
sane indentation by making it part of the language, Perl is a
language that enforces a dialect of hungarian notation by making
its variable decorations an intrinsic part of the language.
What if, instead of cramming everything into "scalar" to the point
where it loses its value as "a data type that magically converts
between numeric and string, as needed," we undo the Great Perl5
Dilution and undecorate references.
The Scalar and The Containers keep their decorations, and things that
are neither numeric nor string values (references to reserved memory
containing
interpretable code, continuations, charm quarks, etcetera) get to stop
dragging around a signifier which does not fit them.
We are at the point where there are so many variable types that the
dollar sign on their names has become a hollow formality.
my dog $spot; #spot is a dog that looks like a scalar
#spot holds neither numeric nor string data
#why is spot burdened with the BASIC
#string identifier?
my dog spot;#after this declaration, it is clear that
#spot is a dog. Should a programmer wish
#or need to be even more specific about
#these things, e could even say
my dog dog_spot;#but it would be entirely up to em and
#the language would not enforce it.
So what I am suggesting is, Scalar as catch-all for unclassifiables
that are neither strings nor numbers may have been a historic stopgap
measure in perl 5 which was seen to be unworkable given the profusion of
object types which became available in perl 6.
An object of type "abstracted reference to a chair" is _NOT_ an object of
type "numeric or string that magicly switches between as needed"
This notation,
my
makes @ short for array
my @chairs; # equivalent, define a container
my ARRAY chairs;# keyed with wholes
and so forth
the name of the variable is chairs, its type is array,
it is a container, it has the dozen methods described
in the C documentation, and you can get to them the
long way
chairs.PUSH(map {woodworking} ARRAY(treestumps));
or take the shortcut
push @chairs, map {woodworking} @treestumps;
or even, if everything is declared nearby, so we don't need
the decorations, which are now merely casts,
push chairs, map {woodworking} treestumps;
september's discussion, such as
http://www.mail-archive.com/perl6-all@perl.org/msg03542.html
never quite became a RFC (at least not one with "undecorated" in the title)
at this point we start reducing the funny char load.
The precious antipolymorphism of having @stuff and %stuff refer to
two completely different sets of stuff can be retained, in which case
the decorations must be used to disambiguate, or can be trashed, in
which case decorations can be used or not used as the programmer
sees fit, just as you can cast every occurance of every variable in
a C program if you want and it will compile just the same as if
you had merely declared them all exactly once.
Thanks for listening, I think I did well on the statistics final, got
two projects to do and then the semester is over.
Re: Apoc2 - concerns
On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote: > Not that there are any such people. Yet. Indeed. And I suspect that the first Perl 6 programmers are Perl 5 programmers, who know damned well what "next FOO" means. -- "Dogs believe they are human. Cats believe they are God."
Re: Apo2: \Q ambiguity
Johan Vromans wrote:
>
> [Quoting Michael G Schwern, on May 6 2001, 22:58, in "Re: Apo2: \Q ambigui"]
> > Hmmm, maybe you can point out the "compose" key on my keyboard, I
> > can't find it. ;)
>
> Pick whatever you find convenient. I use the right control key.
> From my .Xmodmap:
>
> ! Compose key
> keycode 109 = Multi_key
>
> > I know what Larry went through. I had to do quite a bit of work just
> > to be able to type a £ symbol. I wound up remapping my 'option' key
> > (that's 'alt' to you non-Mac people) to £.
since we appear to be sharing on this topic, I ran
perl -e 'for (32..255){print chr};print $/'
and then used mouse paste, when I wanted « and ».
¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐ
ÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
are all in there somewhere.
Re: Subroutine attributes, from a long time ago
John Porter wrote: > > > [EMAIL PROTECTED] writes: > > : > > : why should a reader expect that a declarative description > > : of &foo would be followed by the body of &foo? > > Isn't the functional definition of a sub > just another one of its attributes, anyway? I'm a little bit disappointed that p6 doesn't appear to be letting user-defined classes take up slots in the main symbol table along with scalar and array slots. If I can define a $duh (duh.scalar) and a @duh (duh.array) why cant I define a class called actor and then define duh.actor? I guess this is back to the allowing undecorated keywords to mean variables thing. In keeping with Nathan's suggestion that angles become the shortcut for the .more method, which is special only in that it has a shortcut, the other early-perl declarations $,%,@ could be considered as shortcuts for the scalar, hash and array attributes of the keyword, aka duh.scalar, duh.hash and duh.array then we _keep_ typeglobs instead of throwing them away, and michael schwern and dan sugalski's heads both implode.
Re: Apoc2 - concerns
I know it is an annoying and bad habit but I'm still young enough so
at first glance I think I know it all.
> [billions and billions of]
> SYN_A # Return one element regardless of context.
> SYN_B # Return number of element wanted by context.
> SYN_C # Return all element regardless of context.
Left out are the Defined? (SYN_D) and Copy (SYN_E)
operations.
For files in p5 we have A and C in scalar or array context of bracketed
file handles. Introduction of "counted busy" context gives us B in
bracketed file handles:
($first, second_holder(), third_holder()) = <$generator>
($first, second_holder(), third_holder(), @AllTheRest) = <$generator>
Which lets us keep unbracketed for D and E.
> The basic underlying question is, what is the context that should fire
> off an iterator? Everyone thinks @foo[1..10] should just do the right
> thing, whatever that is.
okay I'll bite. It's the second through eleventh values of @foo, a
10-element sized busy.
> Assuming the following makes an iterator,
> and doesn't set $iter to 1 the first time through:
>
> $iter = 1..10;
something we might be able to currently do with a source rewrite
to a tied scalar
>
> How many of these work?
>
> while ($x = @foo[$iter]) { ... }
$x becomes a true and defined reference to a continuable expression ,
and a compile-time warning is issued about suspicious use of an
iterator, suggesting angle brackets.
while ($x = @foo[<$iter>]) { ... }
still doesn't DWITYM, or does it? It does, due to the relaxation of
the @arrayname[index] syntax being an accessor rather than a slice,
so it is equivalent of
while (($x) = @foo[<$iter>]) { ... }
would be a lazy while-equivalent of
foreach $x (@foo[1..10]){ ... }
> while ($x = <$iter>) { ... }
unless the code has C in it somewhere this will advance
the iterator, breezing right past false and only stopping on undef
(semantic shift triggered by appearance of angles)
(although there are no falses in 1..10)
> while ($x = $iter) { ... }
endless loop unless $iter gets set to false or undef
> for ($iter) { ... }
C having some magic in it to iterate iterators seems reasonable
>
> I think that iterators must be dereferenced by something explicit, and
> we will have to be very clear as to what is explicit enough. Subscripts
> may be explicit enough:
>
> @foo[$iter] # okay?
> @foo[<$iter>] # kludgey
>
> Obviously, $iter.method doesn't want to iterate:
>
> $iter.more # can't iterate, or you call $iter.more.more.more...
> <$iter>.more# okay, iterates over some iterators.
>
> Well, that's enough brainwracking for the moment. Gloria is making me
> go eat something...
>
> Larry
fascinating
Re: Apoc2 - concerns
Nathan Wiger wrote:
>
> Truthfully, I've always liked the <>'s (and personally don't think we need a
> qw alternative), so I'd rather we stay with:
>
>$a = <$b>; # same as next $b or $b.next
we could generalize the other direction and have angles be a standard
shortcut for the "next" method:
while (($k,$v) = each %sack){
...
($k,$v) = <%sack> or last;
...
};
what else _has_ iterators?
Re: Apoc2 - concerns
Simon Cozens wrote: > > On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote: > > Perl is a highly dynamic language > > An object with exactly one and only one method doesn't sound that > dynamic to me. nonsense! It's got accessor methods too, for everyone who wanted to magicalize "$index" and so forth. Remeber those threads from last year?
Re: Apo2: \Q ambiguity is too a problem
Larry Wall wrote:
>
> The ~~ is a cute hack though.
Credit is due to Steve Lane <[EMAIL PROTECTED]> who posted it to funwithperl.
...
> I'm sorry, my eyes go crossed when I look at that, and the two \Q's
> merge into one, which confuses me, in a stereoscopic sort of way.
I was wrong about \Q\E anyway. Apparently it gets optimized out of
the doublequoting process _BEFORE_ the interpolation occurs, so it cannot
break up the expression. Which is very odd since it happens _after_
interpolation normally since it affects interpoincluded parts of the
string.
metaquoting must happen multiple times in the course of the p5 interplation
process.
And \E\Q fails to have the first \E knock the
metaquote count into the negatives. \q is free however so why not use
define
\q as the zero-length noninterpolable expression, instead of tossing out
the
nifty if rarely used snap-on socket that is the metaquoting sequence?
> We could leave \Q{} as metaquote and use \E for a expression stopper,
> though that would be confusing to people used to the old \E, which is
> dead, dead, dead, drive a stake through its heart, dead. (I hope...)
>
> Larry
\Q{} seems like an alien in a land populated with qw, qh, qr, etc. Why not
join the parade and use qm, if abandoning \Q...\E?
print SCRIPT "touch $(qm($filename))";
Re: Apoc2 - concerns
Nathan Wiger wrote:
> Perhaps qi() for "interpolate" or something else.
coming to Perl from Scheme I recall some distress that
I had to create
($j=$i) =~ s/(\$\S+)/$1/ge;
instead of what I wanted to do
$j=qqq/$i/;
so my nomination is for tokens matching /qq*/ to behave like
subsequent applications of evaluation within quotes, even though
it opens the door to a world of taint.
...
> Basically, <> is left as direct access to the iterator, but it's not
> magically called except where it clearly make sense (and I don't think
> normal variable manip like passing into subs and hashes should be in this
> category).
me too
> Hmmm, I'm not sure about the "iterator object" you're implicitly proposing
> above. Is it going to be standard fare to assume certain types of objects
> are created from certain constructs? What would this do?
I took the iterator object assumption to imply that dotdot in scalar
context was being defined to return tied scalars that return consecutive
numbers, so we can forget about storing all these eminently optimizable
sequential temporary arrays.
>$iter = (1..10);
>
> The same thing as above? What about:
>
>
> What would these do?
I'd parse them, in my hubris, like so:
>$iter = (1,2,3,4);
p5: $iter = \(1,2,3,4);
instead of this parsing into comma operator which is what p5 appears
to do with it.
>$iter = (5,7..10);
since the dotdot is within another array constructor here, we get
another reference to an array instead of a magic iterator. It can
become a rfc123-compliant magic iterator like so
$iter = ?(5,7..10);
For the rest, assignment is stronger than comma, unless that gets changed.
>$iter = 1, 2, 3;
>$iter = a, b, c;
>$iter = 1, 4 .. 10;
> Assuming, however, that we had an iterator object concept, I would say:
>
> > while ($x = @foo[$iter]) { ... }
>
> Works.
so undef always passes through an array-lookup?
defined(@arrayA[undef]) # always false?
> Phew! My brain hurst. ;-)
>
> -Nate
i agree w/ e-thing
Re: Apoc2 - concerns
David L. Nicol wrote: > That also wraps up the "for should have an explicit > iterator access method" thread handily! Just label your loop and > there you are! Well, right. Every loop would have a control object, whether it's nonymous or a-. -- John Porter
Re: Apoc2 - concerns
At 10:23 PM 5/8/2001 +0100, Simon Cozens wrote:
>On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
> >@foo = ({scalar each %some_tied_hash});
> >
> > with the function being called only when you access a particular element?
>
>I'm still confused. Firstly, this doesn't involve first-order blocks, which
>was kinda what the entire question was about.
Well, it's a block in list context, which is what I was shooting for.
>Secondly, it isn't clear what it
>means. "scalar each" in Perl5-think means "return the first element". (Try:
>perl -le '%a=(a=>"b", c=>"d"); print while $_ = scalar each %a')
Odd.
%foo = (a => 1, b=>2);
while ($_ = scalar each %foo) {
print $_, "\n";
}
does the expected thing. (printing a and b) Which is what I was shooting for.
>Is this not
>merely @foo=(keys %some_tied_hash), which should call the tied functions in
>the same way? Not a convincing example, I'm afraid.
Well, we currently don't call the tied function that way. But yes. (And the
example was supposed to be illustrative, not convinving)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apoc2 - concerns
Simon Cozens wrote: > John Porter wrote: > > C looks like a method call > > It doesn't, Oh, but it does, to the perl6 programmer who's used to thinking $source.next (or its "indirect object" alternative, next $source ) iterates the iterator in $source. Not that there are any such people. Yet. -- John Porter
Re: sandboxing
Dan Sugalski writes: : We'd want an alternative opcode running loop for all this, and it could : easily enough check times, as could special opcodes. Long-running codes : could also check at reasonable breakpoints. (Still in trouble with C : extensions, but that's pretty much a guarantee) It's not necessarily an alternative run loop--we need to do something like this anyway for safe signals. What's alternative is that the sandbox gets a periodic mandatory signal telling it to check resource limits. Larry
Re: what I meant about hungarian notation
> sane indentation by making it part of the language, Perl is a > language that enforces a dialect of hungarian notation by making > its variable decorations an intrinsic part of the language. But $, @, and % indicate data organization, not type... > What if, instead of cramming everything into "scalar" to the point > where it loses its value as "a data type that magically converts > between numeric and string, as needed," we undo the Great Perl5 > Dilution and undecorate references. Continuing this further, why keep *any* notation at all? Why are vars with string or numeric data more worthy of $? > We are at the point where there are so many variable types that the > dollar sign on their names has become a hollow formality. Again, I'm confused. All I expect from something with a $ is that it's a single value, not necessarily a string or a number. And what if I want to treat a string-ifiable object as an untyped value? Is my var then "$ worthy"? - Matt
Re: Apoc2 - concerns
> Doubtless Damian could come up with a way to view them as hashes...
Well, of course.
An iterator is neither pure state nor pure behaviour. It's an
inextricable commingling of the two. In other words: an object.
So they are *most naturally* viewed as hashes:
package Iterator;
sub new { my $class = shift; bless {@_}, $class }
sub next { croak 'Abstract next method called on ' . ref $_[0] }
sub reset { my $self = shift; $self->{next} = undef; }
package Iterator::Range;
use base 'Iterator';
sub next {
my $self = shift;
$self->{next} = $self->{from} unless defined $self->{next};
return $self->{next}++ if $self->{next} <= $self->{to};
$self->{next} = undef;
return;
}
package Iterator::Step;
use base 'Iterator::Range';
sub next {
my $self = shift;
$self->{next} = $self->{from} unless defined $self->{next};
return ($self->{next}+=$self->{step})-$self->{step}
if $self->{next} <= $self->{to};
$self->{next} = undef;
return;
}
package Iterator::Array;
use base 'Iterator';
sub next {
my $self = shift;
return ($self->{array}[$self->{next}++]
if ($self->{next}||=0) < @{$self->{array}};
$self->{next} = undef;
return;
}
# etc.
# etc.
# etc.
See? Nothing but hashes.
;-)
Damian
Re: Apoc2 - concerns
In a fit of insanity, at 10:14 EDT Tue May 8, I wrote: > >9 times out of 100, qw saves a large number of keystrokes. (The >other 1% of the time, ... I hope it's obvious that I meant "99 times out of 100" -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - concerns
Eric Roode writes: : >And the fact is, I've always loathed qw(), despite the fact that I : >invented it myself. :-) : > -- Larry Wall in <[EMAIL PROTECTED]> : : : Well, one person's ugly is another person's joy forever. : : Regardless of the aesthetics of q//, qq//, qw//, et al, (and here : docs too), they get the job done in a remarkably flexible, efficient : way that is simply not possible with just about any other language : out there. : : 9 times out of 100, qw saves a large number of keystrokes. (The : other 1% of the time, you have to work around qw's inability to : quote things with spaces). : : qq, q, and here-docs may be "ugly", but that's a judgment call. What : they are not is "broken". : : Personally, I don't understand how using two alphabetic characters : and a pair of delimiters, in order to save typing a whole mess of : quotes and backslashes, can be construed as "ugly". :-) : : And, while I'm on my soapbox here, I don't get how <...> is a vast : improvement over qw<...>. :-) Please pardon my hyperbole. I don't loathe qw() so badly that I want to get rid of it. I merely want to put it in the same status as the other general quote operators that also have a non-general pair of standard quote characters. I would feel the same about qq// if there weren't a "". Larry
Re: Apoc2 - concerns
Peter Scott writes: : At 01:51 AM 5/6/01 +0100, Simon Cozens wrote: : >The debate rages on: Is Perl Bactrian or Dromedary? : : It's a Dromedary, it says so in the Colophon. : : But maybe the symbol of Perl 6 should be a Bactrian, with the extra hump : symbolizing the increased power. : : You knew this was coming... That question already arose for the second edition of the Camel book. The answer is related to the fact that we already have a third edition, and there seems to be a shortage of three-humped camels. Larry
