Pre-defined properties/traits/etc.
[EMAIL PROTECTED] (Simon Cozens) writes: Can someone please compile a list of all the is foo properties that have been suggested/accepted as being pre-defined by the language? I can't keep track of them all. Well, here's a start. Here are the ones I've found in the Exegeses and Apocalypses. Things like 'is copy' and 'is given' (and probably a great many others) have only been mentioned on the list, and I'm not grepping through all the list mail. :) A note: It is *impossible* to tell whether these are properties or methods, built-ins or user-defined. This has never been stated anywhere, with the exception of constant and dim, which Damian says (in E2) are built-in properties. Maybe those which are capitalized are user-defined. Maybe that's not a good enough rule. We Just Don't Know. Maybe an explicit rule would be nice. And this may all have changed anyway. But here they are, followed by which Apo/Exe they were mentioned in, and how many times, using the troll's numbering system. (1, 2, many, lots) bigint (A2: 1) constant (A2: many, E2: many, E4: 2) const (E3:2) rw (A2: 2, A4: 1, E2: many, E4:1) true (A2: 1, E4:1) false (A2: 2) dim (A2: many, E2: many) shared (A2:1) locked (A2:1) optimize (A2:2) same (A2:1) private (A2:1, E4:many) computed (A2:1) Purpose (A2:1) lazy (A2:1) Initialised (A2:2) weak (A2:1) Note (A2:1) dis (A2:1) Meaning (A2:1) interface (A2:1, E4:2) inherits (A2:1) Exception (A4:1,E4:many) post (A4: many) loud (A4: many) keymatch (A5:1) valuematch (A5:2) back (A5:2) chomped (E2: many, E4:1) Found (E2:many) Colour (E2:1) prompts (E2: many) Verified (E2:1) Allison, any more to add? -- #define struct union /* Great space saver */
Re: Arrays, lists, referencing
On Wed, Feb 19, 2003 at 12:00:33AM -0500, Stephen McCamant wrote: DP == Deborah Ariel Pickett [EMAIL PROTECTED] writes: DP One thing that the C comma operator promises is that its left DP operand (and all side effects) is completely evaluated before work DP starts on the right operand. (This may not be strictly true in DP the Perl interpretation of the operator; can a Perl5 developer DP comment?) It's a matter of some controversy exactly what promises with regards to order of operation Perl5 provides. Unlike C, there's no separate standard describing what Perl should do: just an implementation, and some documentation. As a matter of implementation, I believe both scalar and list comma operators have always evaluated their arguments from left to right. (This also applies to the comma separating sub arguments, if you count that separately from list comma). As for documentation, both the POD and the Camel book use language that strongly suggests left-to-right evaluation for the scalar comma (it evaluates its left argument, throws that value away, then evaluates its right argument and returns that value) as well as referring to it as just like the C comma. By contrast, they don't say anything directly about the evaluation order of the list comma. On the other hand, there is the following example from perldata (I can't find it in the Camel, but I can't grep the Camel): # A reverse comma operator. return (pop(@foo),pop(@foo))[0]; which only makes sense if list comma is guaranteed to evaluate left to right. Yes, I've never found anything explicitly defining the order of evaluation of the comma operator in list context, but as you suggest there are examples from the perl documentation, the core, its tests and, of course, CPAN which all make use of the left to right ordering. For example, select((select(OUTPUT_HANDLE), $| = 1)[0]); which is (was?) a fairly common idiom, is documented, used in core modules and tested. I suspect that a lot would break if the order of evaluation changed. And I think it would be sensible for Perl 6 to define such an order. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Arrays, lists, referencing
On Sat, Mar 01, 2003 at 06:09:15PM +0100, Paul Johnson wrote: : I suspect that a lot would break if the order of : evaluation changed. And I think it would be sensible for Perl 6 to : define such an order. Certainly. The fact that Perl 5 doesn't define it is merely an oversight, brought on no doubt by a lack of oversight. But as you point out it can deduced by observation of all the various implementations of Perl. :-) Larry
Re: Pre-defined properties/traits/etc.
Simon Cozens wrote: Well, here's a start. Here are the ones I've found in the Exegeses and Apocalypses. Things like 'is copy' and 'is given' (and probably a great many others) have only been mentioned on the list, and I'm not grepping through all the list mail. :) Cis given is gone now anyway. A note: It is *impossible* to tell whether these are properties or methods, built-ins or user-defined. This has never been stated anywhere, with the exception of constant and dim, which Damian says (in E2) are built-in properties. Maybe those which are capitalized are user-defined. Maybe that's not a good enough rule. We Just Don't Know. Maybe an explicit rule would be nice. One general rule is that properties and traits are lower case, while classnames are upper case. We're not making any visual distinction between built-in properties and user-defined properties, because it's certain that many user-defined properties will become built-in properties when they prove valuable. No one should have to rewrite their code just because we moved the property into the 'core'. And this may all have changed anyway. But here they are, followed by which Apo/Exe they were mentioned in, and how many times, using the troll's numbering system. (1, 2, many, lots) bigint (A2: 1) Not a property, a type. Now CInt. lazy (A2:1) A type, now CLazy. constant (A2: many, E2: many, E4: 2) const (E3:2) Now Cconstant. rw (A2: 2, A4: 1, E2: many, E4:1) true (A2: 1, E4:1) false (A2: 2) dim (A2: many, E2: many) post (A4: many) keymatch (A5:1) valuematch (A5:2) chomped (E2: many, E4:1) private (A2:1, E4:many) same (A2:1) These are important features of Perl 6, and will be implemented. inherits (A2:1) Replaced by Cis Classname. Exception (A4:1,E4:many) This isn't a property, it's inheritance. All exception classes inherit from the base Exception class, directly or indirectly. prompts (E2: many) interface (A2:1, E4:2) back (A5:2) Possible, not fully defined. Purpose (A2:1) Found (E2:many) Colour (E2:1) Verified (E2:1) Note (A2:1) loud (A4: many) Meaning (A2:1) dis (A2:1) shared (A2:1) locked (A2:1) computed (A2:1) optimize (A2:2) Initialised (A2:2) weak (A2:1) These were really just examples. That doesn't guarantee they won't have implementations, but they aren't particularly important. Allison, any more to add? Here's what I can think of off the top of my head and the meeting where it was added/decided/proposed: public (STL) [0] copy (ORA) really (ETH) may be superseded by C::= topic (STL) repeatedly (ETH) like (STL) tighter (STL) looser (STL) delegated (STL) named (ORA) There are certainly others, and more will be defined as we go. Allison [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept. 2002, ORA = O'Reilly offices in Sebastopol - Feb. 2003
Re: Pre-defined properties/traits/etc.
On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote: [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept. ETH is in Zurich. The Mini::Conference there was immediately followed by YAPC::Europe in Munich. All these old European cities speaking funny German just merge together. If it's Wednesday it must be Zurich. We enjoyed you being here even if you can't remember it ;-) Oh well, it was only two letters. There wasn't anything about approximate matching in A5, was there? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Pre-defined properties/traits/etc.
On Sun, Mar 02, 2003 at 12:02:42AM +0100, Paul Johnson wrote: On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote: [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept. ETH is in Zurich. The Mini::Conference there was immediately followed by YAPC::Europe in Munich. All these old European cities speaking funny German just merge together. If it's Wednesday it must be Zurich. We enjoyed you being here even if you can't remember it ;-) I apologize, I traveled far too much last year. %-) Oh well, it was only two letters. There wasn't anything about approximate matching in A5, was there? I'm not sure what you mean, could you give an example? Allison
Re: Pre-defined properties/traits/etc.
[EMAIL PROTECTED] (Allison Randal) writes: Oh well, it was only two letters. There wasn't anything about approximate matching in A5, was there? I'm not sure what you mean, could you give an example? This was a [MZ]u[nr]ich joke, I think. -- Term, holidays, term, holidays, till we leave school, and then work, work, work till we die. -- C.S. Lewis
Re: Pre-defined properties/traits/etc.
Simon wrote: Oh well, it was only two letters. There wasn't anything about approximate matching in A5, was there? This was a [MZ]u[nr]ich joke, I think. * Allison trundles off to caffeinate her brain.
Re: Pre-defined properties/traits/etc.
On Sat, Mar 01, 2003 at 11:58:39PM +, Simon Cozens wrote: [EMAIL PROTECTED] (Allison Randal) writes: Oh well, it was only two letters. There wasn't anything about approximate matching in A5, was there? I'm not sure what you mean, could you give an example? This was a [MZ]u[nr]ich joke, I think. Well, that might be attributing it a status it didn't deserve, but yes. perl -MString::Approx=amatch -wle \ 'print Close enough if amatch(Munich, [2], Zurich)' It's alright. It works just fine as a module. I think Parrot even has an appropriate opcode. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
