Re: dimensionality in Perl 6
Jon Lang asked me if I intended to send this message to him privately. The answer is No... -- Forwarded message -- From: Buddha Buck blaisepas...@gmail.com Date: Thu, Nov 18, 2010 at 10:39 PM Subject: Re: dimensionality in Perl 6 To: Jon Lang datawea...@gmail.com On Thu, Nov 18, 2010 at 7:58 PM, Jon Lang datawea...@gmail.com wrote: Here's my proposal for how to handle dimensionality in Perl 6: Create a units trait that is designed to attach to any Numeric object. Dimensional information gets stored as a baggy object - that is, something that works just like a Bag, except that the count can go negative. (I don't know if the count should be a signed integer or a Num; what happens in dimensional analysis when you try to take the square root of two inches?) Overload the Numeric operators to properly track the units as well as performing their normal activities. Add one or two methods that allow you to easily extract the raw number and/or the units. An added complication is dimensionality. ergs, joules, btu and eV are all units of energy, and it isn't unreasonable to want to add or subtract energies of different units (my house used (100 therm + 8000kWh) of energy last month, for example). However, it is incorrect to add ergs and Newtons, since they are of different dimensionality. The more robust units/dimensional analysis packages I've seen might not allow one to add therms and kWh, but they do know that therms and kWh are both [ML^2/T^2], I believe at the time I was looking at JScience's work on JSR-275. In this setup, when units are registered, they are given a dimensionality (essentially, a baggy of dimensions), and values are given a baggy of units (and thus an implicit baggy of dimensions, the union of the dimensions of the units). I don't think a Num is necessary, but I could see a Rat. If this is implemented, Duration should be an alias for something to the effect of Num but unitssecond. Otherwise, Instant and Duration remain unchanged. Thoughts? -- Jonathan Dataweaver Lang
Re: dimensionality in Perl 6
On Thu, Nov 18, 2010 at 11:53 PM, Jon Lang datawea...@gmail.com wrote: Buddha Buck wrote: I don't think a Num is necessary, but I could see a Rat. As is, is Duration implemented by means of a Num, or a Rat? Whichever it is, that's the type that the difference of two Instances would return (properly tagged with seconds, of course). Clarification: I didn't mean to imply that a Rat would be sufficient for Duration, but rather that it would probably suffice for dimensioned values to have a RatBag of units, each with a RatBag of dimensions, rather than NumBags. SBags might be too restrictive. (sent both publicly and privately on the first try, this time) -- Jonathan Dataweaver Lang
Re: Tweaking junctions
On Mon, Nov 1, 2010 at 7:24 AM, Moritz Lenz mor...@faui2k3.org wrote: On 10/22/2010 06:16 AM, Damian Conway wrote: That is, a C$value is an eigenstate of a C$junction if-and-only-if: $value !~~ Junction $value ~~ $junction In general this definition makes it impossible to return a list of eigenstates from the junction. Just think of junctions containing Code objects. Or anything more complicated than the built-in value types. [Originally sent to Moritz alone because of Reply not sending to the list] Is it too late in this discussion to point out that, in non-perl usage, eigenstates are associated with the operator, not with the value fed into the operator? [Added at Moritz request] In linear algebra, eigenvectors and eigenvalues are non-trivial solutions to the equation Ax=λx, where x is a vector in a vector space, A is a operator (a function from a vector space to itself) and λ is a member of the field the vector space is defined over. For a given operator A, only certain values of λ allow that equation to be solved, and those values are called the eigenvalues for A. Also, for a given operator A, only certain vectors x will solve the equation, and those vectors are called eigenvectors. It should also be clear that different values of λ work with different sets of vectors x (the solutions to Ax = ax and Ax=bx are different if a != b), so it's typical to talk about the eigenvectors of A associated with a given eigenvalue λ. Since A is linear, if Ax=λx and Ay=λy, then A(ax) = a(Ax) = a(λx) = λ(ax) and A(x+y)=Ax+Ay=λx+λy=λ(x+y), so fir a given eigenvalue λ, there are typically multitudes of eigenvectors which form a vector space of their own. Eigenvectors for different eigenvalues are orthogonal, and any eigenvector can be scaled to be a unit eigenvector. If an operator has a full set of eigenvalues, one can pick a set of unit eigenvectors to act as a natural orthonormal basis for the operator. If operator A has three eigenvalues a, b, c, and three unit eigenvectors x, y, z, such that Ax=ax, Ay=by, and Az=cz, then if w = dx+ey+fz, Aw = a(dx)+b(ey)+c(fz), which is really easy to compute. In quantum mechanics, especially the Heisenberg matrix formulation (but by analogy, also every other formulation, including wave mechanics), quantum states are represented by vectors in a complex vector space, and vectors which differ by a real-valued scaling factor are generally considered equivalent. Transformations (i.e., anything which modifies the quantum state of the system, including but not limited to the passage of time) are represented by (unitary) operators on the state space. (Unitary in this case means that the norm of Ax is the same as the norm of x, for all x.) The standard notation is a bit odd, where the 'ket' |x represents a system in state x (and therefore |x+y a state in a superposition of x and y), The 'bra' x| is the complement of the ket |x, and can be multiplied by a ket to get a braket x|y which represents the probability that a system in state y is also in state x. |x is, naturally, usually normalized such that x|x = 1. Operators act on kets and return kets, so A|x is the braket notation way of writing the linear algebra Ax. Naturally, that means that y|A|x is the probability that a system that starts in state x will be in state y after the transform A. Since A is a linear operator, it has eigenvalues and eigenvectors. In the quantum mechanical world, where vectors represent states, the eigenvectors are called eigenstates. Eigenstates |i, |j of an operator A have the property that i|A|i = j|A|j = 1, but i|A|j = 0 (informally, if you start in an eigenstate of A, then the transform leaves you unchanged). However, A|i+j = |ai+bj, so A can change the nature of a superposition of states. i|i+j = 1/2, j|i+j = 1/2, but i|A|i+j = a/(a+b), j|A|i+j = b/(a+b). Schrodinger's Wave Equation, in matrix notation, is of the form Hx=Ex, where H is the Hamiltonian operator of the system, and E is the energy of the system, so the only allowed solutions of the wave equations are for energy levels E which are eigenvalues of H,and for quantum states which are eigenstates of H. Similar equations exist for virtually every observable, so the only allowable momenta are the eigenvalues or eigenstates of the momentum operator, the only allowable positions are the eigenvalues or eigenstates of the position operator, etc. So asking for the eigenstates of a quantum superposition is asking the wrong object for the property.
Re: Temporal seems a bit wibbly-wobbly
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso dan...@ruoso.com wrote: The biggest difference proposed by the use of TAI is that when you ask for the number of seconds between 2008-12-31T23:59:59+ and 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But you don't need to know how many seconds there were in the TAI scale since the 1958 epoch to find that out, you just need to know when we had leap seconds. What do you mean? The number of seconds between 2008-12-31T23:59:59+ TAI and 2009-01-01T00:00:00+ TAI was 1 because TAI doesn't have leap seconds. UTC does, but TAI doesn't.
Re: time complexity of searching elements in hash tables in Perl
On Sat, Aug 22, 2009 at 5:07 PM, Forrest Sheng Baoforrest@gmail.com wrote: Oh, I mean both Perl 5 and Perl 6. I couldn't find proper list to ask this question. So I asked in this list. I'm not sure perl6-language is the proper place to be asking about the time-complexity of hashes in Perl6, or at least, not the way that you asked. Here's another way to ask, which might yield a more useful reply.. In C++, the STL guarantees that lookup operations in a map data structure are guaranteed to have a time complexity that is at most logarithmic in the number of key-value pairs in the map. Does the Perl-6 specification make any similar guarantees regarding hash lookups? If not, does anyone know, offhand, what the time complexity is for current implementations if hash lookup? Cheers, Forrest Forrest Sheng Bao, BSEE, Graduate Student Dept. of Computer Science/Electrical Engineering, Texas Tech University http://narnia.cs.ttu.edu Sent from Lubbock, TX, United States On Sat, Aug 22, 2009 at 4:04 PM, Nicholas Clark n...@ccl4.org wrote: On Sat, Aug 22, 2009 at 04:01:13PM -0500, Forrest Sheng Bao wrote: Does anyone know the time complexity of searching elements in hash tables in Perl? Suppose the number of elements is n. I have no idea on how Perl automatically builds the hash function and the table. If you can tell me how it works, that is also helpful. I can analyze the algorithm myself. You're asking the question on the Perl 6 language list, but it's unclear whether you're asking about hashes in Perl 6, or in Perl 5. It's not possible to answer until you clarify that. Nicholas Clark
Re-thinking file test operations
Resent to list as I intended to in the first place On Thu, Jul 9, 2009 at 9:32 PM, Darren Duncandar...@darrenduncan.net wrote: Mark J. Reed wrote: A few months ago (or maybe more) I proposed making pathnames their own type, distinct from (or perhas a subclass of) strings, but easily constructed from strings, maybe with an operator. Having those 29 single-letter methods on such a class would not bug me as much as having them on Str. On 7/9/09, Aristotle Pagaltzis pagalt...@gmx.de wrote: * Moritz Lenz mor...@faui2k3.org [2009-07-10 00:25]: stat($str, :e) # let multi dispatch handle it for us This gets my vote. I agree. The built-ins of basic types like Str or Int etc need to stay pure and just be about dealing with local data. Having methods on basic types for going out into the wider environment like the file system is just plain wrong. There should be separate IO classes for things like stat, which *use* basic types like Str for their interface definitions, and the full definition of Str/etc should not include any file-system operations. It's unclear which you are agreeing with. By reference, it sounds like you agree with the idea of a separate pathname type, but by context, it sounds like you are agreeing with stat($str, :e) Both the separate pathname type and the stat($str, :e) proposal salvage the purity of Str, so either would be acceptable to your argument. I have seen other language APIs have a pathname class, usually called FilePath or Path or similar. Generally, I like the idea because it allows one to abstract away from the specific form of a filename (be it the /home/blaisepascal/.emacs/emacsrc of Unix, the C:\Documents and Settings\Users\Blaisepascal\Local Settings\GNUEmacs\emacs.rc of Windows, the BootDisk:Users:BlaisePascal:Settings:GNUEmacs:emacsrc of MacOS 9, or the DKA0:[USERS.BLAISEPASCAL.SETTINGS.GNUEMACS]EMACS.RC;1 of VMS) to the basic components (devices, directories, and files). Most of the FilePath APIs I've seen allow virtual traversal of the path (e.g., given a FIlePath corresponding to /home/blaisepascal/.emacs, you can ask it for the directory portion to get /home/blaisepascal, or ask it to specify another layer, to get /home/blaisepascal/.emacs/22.18), conversion of relative paths to absolute paths, and perhaps even conversion of one path representation (like Unix-style paths) to another (like HFS-style paths). The annoying bit I've found with some APIs is that some of them force you to use a FilePath as an argument to File.Open(), and don't always provide an easy way to get from a string to a FilePath, forcing you to do things like File.Open(FilePath.CurrentWorkingDirectory.AddFileName(myFile)) to open ./myFile. I support the idea of a separate pathname type, and I trust the Perl6 developers to make it robust but easy to use. If you go ahead and put stat ops in Str anyway, then you might as well put things like a delete_from(Hash $arg) method on Object, which is a less objectionable version of such backwardness. -- Darren Duncan
Re: Amazing Perl 6
On Fri, May 29, 2009 at 10:23 AM, Jon Lang datawea...@gmail.com wrote: On Fri, May 29, 2009 at 6:52 AM, John Macdonald j...@perlwolf.com wrote: Yep, I've done that. But comparing the difference in effort between: - press a key - Google for a web page that has the right character set, cut, refocus, paste means that I don't bother for the one or two weird characters every few months that is my current Unicode usage. If I were working with Unicode frequently, it would be worth setting up links and mechanisms, or learning the keyboard compose sequences for frequently used characters. I'm sure that there are many people in a similar situation. Agreed. Given the frequency with which « and » come up in Perl 6, I'd love to be able to have a simple keyboard shortcut that produces these two characters. Unfortunately, I am often stuck using a Windows system when coding; and the easiest method that I have available to me there (that I know of) is to pull up Character Map. In response to this thread, I activated the US International keyboard layout, and once that's done theoretically one can get Spanish style quote mark with RightAlt+[ and RightAlt+] like so: « and ». The questions which remain (for me, at least) is if (a) the symbols survive in email, and (b) if they really are the proper marks for Perl6. -- Jonathan Dataweaver Lang
renaming or adding some operators
Resending to list On Fri, May 29, 2009 at 9:53 PM, Darren Duncan dar...@darrenduncan.net wrote: I had some thoughts lately about the Perl 6 operators, and wanted to bounce some ideas. Secondly, regarding the Bool type, I think it would be useful for Perl 6 to define the full complement of dyadic logical operators, of which I count a few that you don't appear to already have. Probably the best place is in Synopsis 32. There are 16 dyadic logical operators, not all of which make sense to have. You name 10. Note that all the dyadic ops I am discussing are meant to be read as infix ops only. These are the boolean/logical ops you already have: Niladic ops aka value literals / constants: * Bool::False * Bool::True Monadic: * not aka !, but ¬ alias could be added Dyadic: * and aka , but ∧ alias could be added * or aka ||, but ∨ alias could be added * xor aka ^^ aka !===, but ⊻, ↮ aliases could be added * ===, but xnor, ↔ aliases could be added I'm certain I know the semantics of these (and chooses the minimum of the two, or the maximum, xor checks for difference, xnor checks for sameness), but I'm uncertain of some of the rest... But here are a few more dyadic: * nand aka ⊼ aka ↑ true unless both operands are true * nor aka ⊽ aka ↓ true if both operands are false * implies aka imp aka → true unless left operand true and right operand false. * nimp aka ↛ true if left operand true and right operand false? * if aka ← true unless left operand false and right operand true * nif aka ↚ true if left operand false and right operand true? The other six, which don't depend on the value of both operands, would (if they existed) have the names false, left, right, nright, nleft, and true. For that matter, as you know, every single boolean/logical operator could also have a bitwise analogue, if people were so inclined. Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test operator, so maybe best to avoid ≠ then. Perhaps ≡ and ≢ as aliases?
Re: MMD thoughts 2008
Sorry to reply to the wrong comment, but I lost the original thread in my mail archives and didn't notice this until now. On Tue, May 6, 2008 at 1:54 PM, John M. Dlugosz [EMAIL PROTECTED] wrote: TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: The fundamental flaw of metric mmd is that it trades degrees of specificity. Consider the subtype chain E : D : C : B : A where the rule is that having an E it is better handled by a method dealing with a D than one dealing with an A. The same is the case for having a D being better handled by a C than an A method. Now consider a multi with the two signatures :(A,C,C) and :(D,A,A) and a call with (E,D,D) that goes to :(D,A,A) since 7 8. But note that it handles the two Ds as As instead of Cs as in single dispatch. Is this right? (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6. (E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7. Are you sure (E,D,D) would bind to (D,A,A)?
Re: Closures, compile time, pad protos
On 11/22/06, Anatoly Vorobey [EMAIL PROTECTED] wrote:
First of all, thanks a lot for your comments.
On Wed, Nov 22, 2006 at 06:43:12PM -0500, Buddha Buck wrote:
{
my $x = something();
if $x==1 {
...code...
}
}
My experience with other statically typed by extremely flexable
languages is that the pads tend to be arranged in (possibly
interconnected) linked lists. In this example, I see potentially
three pads linked by the time ...code... is called: One containing
the local variables defined in ...code..., one containing the visibly
defined $x, and one visible outside that scope. A reference to $x in
...code... will traverse the linked list until it finds an $x,
presumably finding the one defined in the sample code.
Agreed. By the way, can you offer a perspective on how the pads get
linked up, at runtime? I see each block as having a compile-time pad,
or proto-pad, filled with values known at compile-time; and every time
the block is entered, a new pad is cloned from the proto-pad. At that
point its OUTER reference leads to the proto-pad of the outer block,
and we want to link it up to the real pad of the outer block.
The way I see it, everything which defines a separate lexical scope (a
block, a function, a closure. I forget if in my $a; ... ; my $b $b
is visible in the ellipsis. If not, then a my statement also
defines a separate lexical scope) effectively creates a separate pad,
at run-time, when it is entered. The pad contains all the variables
defined in that lexical scope, and a link to the pad for the
surrounding lexical scope. The search for a variable is done by
looking up the variable in the current pad, and if not found,
recursively searching all linked pads until it is found or you run out
of pads.
There are reasonable optimizations that can be made. If a lexical
scope doesn't create any variables, it can reuse the same pad as its
enclosing lexical scope. If a lexical scope uses only part of an
enclosing pad, the enclosing pad could be broken into two pieces,
linked together, such that only part of it has to be searched or
survives with the enclosed scope, etc.
I haven't read any implementation details as to how Perl6 handles it,
so I'm going to use the following notation: if $p is a pad, then
$p.lookup('$var') returns the value of the variable $var in p,
$p.myvars is a hash containing the local variables defined in $p, and
$p.enclosing is the pad of the lexically enclosing scope.
I think in p6 notation, that would be...
class Pad {
has %!myvars;
has Pad $.outer;
method lookup(String $var) {
return %!myvars{$var} if exists %!myvars{$var};
return $.outer.lookup($var);
}
method set(String $var, $val) {
%!myvars{$var} = $val if exists %!myvars{$val};
return $.outer.lookup($var, $val);
}
...
}
One way to do it is to simply say: when we enter the inner block from
the outer block, at that point we can re-link the inner block from the
outer proto-pad to the outer pad we entered from. That by itself works,
but I'm having trouble understanding what happens during a sub call
rather than entering the block normally. For example:
{
my $x = 1;
sub foo { $x; }
bar();
}
sub bar() { foo(); }
Here we definitely want foo() to see $x==1 (I think), but we get to
foo() via criss-crossing through bar(), and so how would foo() know
where to find the right pad as its outer reference?
I did some experiments with pugs based on explicitly separating what
is visible at compile time from what is visible at run time.
Specifically, I used the following code:
my $x = 25;
sub bar {
my $x = 1;
sub foo {
print ++$x;
}
print $x;
}
print $x; // 25
foo(); // 1
foo(); // 2
bar(); // 1
foo (); // 2
foo (); // 3
bar(); // 1
foo(); // 4
Let me call the protopads of foo and bar foo0 and bar0, respectively.
From what I see, foo is visible before bar is run (which was sort of
unexpected to me, but reasonable). Let's see what happens...
The statement sub bar{...} appears to set up a protopad $bar0 which
contains an $x, but doesn't put in any values until bar is run.
Everything is undef.
The statement sub foo{...} also sets up a proto-pad $foo0 which is
empty. It is linked, however, to the protopad for bar. ($foo0.outer
= $bar0)
Running foo(); before the bar() instantiates a pad $foo1 (=
copy($foo0) for this invocation of foo, a copy of its proto-pad.
Since this links to bar0, when ++$x is done, it modifies the $x in
bar0 to 1. At the end of the call, $foo1 is garbage, waiting on
collection.
The next call of foo(); does something similar... $foo2 =
copy($foo0), $x in bar0 gets accessed and incremented to 2, and $foo2
goes poof.
Running bar(); instantiates a pad $bar1=copy($bar0) for this
invocation of bar. In theory, the $x in this instantiation is 2, but
the my statement sets it to 1. More importantly, finally the sub
foo{...} is encountered at run-time, and there is a current lexical
scope available for it. Since the code is already
Re: Programming languages and copyright?
On 10/23/06, Markus Laire [EMAIL PROTECTED] wrote: On 10/23/06, Smylers [EMAIL PROTECTED] wrote: Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. Yes, but the syntax of the programming language is more than just an idea. Copyright-article[1] at Wikipedia says that Copyright is a set of exclusive rights regulating the use of a particular expression of an idea or information. So, for example, the idea of look-behind assertions can't be copyrighted as it's an idea. But what about a particular form chosen to express that idea (e.g. to use before pattern to denote look-behind)? Can this be copyrighted as it's more than just an idea? Here's another example (which I can work through to completion, unlike the look-behind example: It is an idea (and an old one) to place a symbol between two parts of a mathematical expression to indicate the two parts should be added together. That idea is uncopyrightable. Going further, it is also an idea that should multiple parts be present separated by the addition symbol without anything to group them into pairs, they should be added from left to right. It is an idea that that symbol should be +, and is likewise uncopyrightable. It is an idea that, when parsing such an expression, the rule to handle the first idea should be that an expression can be a term, or a combination of an expression, a '+' symbol, and a term. This is also uncopyrightable. The parsing rule (in BNF): expression :== term | expression '+' term; is a particular expression of the idea we've been talking about, and as such, is theoretically copyrightable. However, it is also about the only way to express that particular idea in BNF, so it may fail copyrightability (in the US) on those lines anyway. I wouldn't worry about stealing syntax from other languages, as long as you don't steal their source code without permission. Disclaimer: I am not a lawyer, IP or otherwise, and the above should not be construed as legal advice. Look-behind assertions are an idea. The use of before pattern as syntax to denote look-behind assertions is also an idea. The abstract grammar that [1] http://en.wikipedia.org/wiki/Copyright ps. I'm asking this because I'm thinking of creating a (simple) programming language by myself, but I'm unsure about how much syntax I could copy from any existing programming languages. -- Markus Laire
Re: This week's summary
On Wed, 22 Sep 2004 21:11:02 +0100, The Perl 6 Summarizer [EMAIL PROTECTED] wrote: The Perl 6 Summary for the week ending 2004-09-17 Another week, another summary, and I'm running late. So: This week in perl6-compiler Bootstrapping the grammar Uri Guttman had some thoughts on bootstrapping Perl 6's grammar. He hoped that his suggested approach would enable lots of people to work on the thing at once without necessarily getting in each other's way. Adam Turoff pointed everyone at a detailed description of how Squeak (a free Smalltalk) got bootstrapped. http://xrl.us/c6kp This link doesn't seem to be working, and www.perl6.org doesn't have the archives of perl6-compiler online yet. Does anyone have a link to the archives that works?
Re: A12: Conflicting Attributes in Roles
Originally sent to Austin alone by accident
Austin Hastings wrote:
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
A12
If, however, two roles try to introduce a method of the same name (for some
definition of name), then the composition of the class fails, and the
compilation of the program blows sky high--we sincerely hope. It's much
better to catch this kind of error at compile time if you can. And in this
case, you can.
/A12
Since classes are autogenerating accessors based in data members, it's
doubly reasonable to assume that the same solution will apply: conflict -
death.
From one C6PAN module:
role Dog {
has $.collar;
...
}
From another C6PAN module:
role LawEnforcementOfficer {
method arrest { ... }
...
}
From a third C6PAN module:
class PoliceDog does Dog does LawEnforcementOfficer { ... }
I use PoliceDog in my production code, without a problem. I don't use
the collar attribute (it's unimportant in my application).
The author of the LawEnforcementOfficer role does an upgrade that fixes
an important bug but also.
role LawEnforcementOfficer {
method arrest { ... }
has $.collar;# for holding most recently arrested
...
}
So when my program fails to compile, who do I blame? How do I fix it
quickly, preferrably without creating local branches of the C6PAN modules?
=Austin
Re: Language Discussion Summaries
Miko O'Sullivan wrote: The idea of discussion summaries has been well received, so I'm going to push forward with a few. I invite everyone here to join in. The idea is *not* that Miko writes summaries of every thread. The idea is that the proponent of an idea, or someone very interested in an idea, writes a summary as a clean final presentation of the idea and its reception. Hmmm... I'm looking at this and I'm wondering You suggest doing it in HTML. Wouldn't it make more sense to do it in POD, the standard documentation language for Perl? And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process?
Re: Language Discussion Summaries
Miko O'Sullivan wrote: And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed.
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Smylers wrote: Michael Lazzaro wrote: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in - lex - parse - codify - optimize - $out; # L2R $out - optimize - codify - parse - lex - $in; # R2L It's clear, from looking at either of those, that they represent data pipes. Yes; that is nice. I'm just not convinced that it's sufficiently nice to require adding yet another way of passing data around to the language. I'm happy enough with the asymmetry that occurs just having the arrows to indicate 'reverse flow' data. The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal... Perl 5 has two different code calling conventions: object oriented method calls, and procedural subroutine calls. OO method calls are L2R already: $object.method1().method2().method3().method4(); Procedural subroutine calls are R2L already: sub4 sub3 sub2 sub1 $variable; But there is no way to do OO method calls R2L, and there is no way to do procedural subroutine calls L2R. Damian's ~ and ~ proposal fills in this gap: method4 ~ method3 ~ method2 ~ method1 ~ $Xbject; $variable ~ sub1 ~ sub2 ~ sub3 ~ sub4; To the best of my knowledge, the following two WILL NOT WORK: sub4 ~ sub3 ~ sub2 ~ sub1 ~ $variable; $Xbject ~ method1 ~ method2 ~ method3 ~ method4 The first one tries to invoke the sub1 method of $variable, while the second tries to call the method1 function with $object as an argument. If either of these works, it's either coincidence or careful planning. So the apparant symmetry between ~ and ~ isn't really there. I like ~ and ~, but I think that it will be a common mistake to think that $a ~ b~c~d can be reversed to give d~c~b~$a, when it can't. That, to me, is an argument against ~ and ~, at least as currently formulated.
Re: L2R/R2L syntax
Michael Lazzaro wrote:
On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
From: Sean O'Rourke [EMAIL PROTECTED]
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
So 'if' and friends are just (native) subroutines with prototypes like:
IIRC it's not that pretty, unfortunately, if you want to support this:
That is not a problem:
snipped
Yeah, a three-argument form would easily allow chaining. But of course
it still doesn't do the appropriate syntax checking (Celse outside of
Cif, etc.). (It's only speculation on our part, of course, but
Damian's response was quite intriguing -- he seemed to imply they had a
solution that would work.)
Would this work?
class True is Bool is singleton {
method isTrue(block) { block.apply(); };
method isFalse(block) { };
}
class False is Bool is singleton {
method isTrue(block) { };
method isFalse(block) { block.apply(); };
}
class ElseCode is Code {};
our True true is builtin;
our False false is builtin;
sub if (Bool $test, Code $block) { $test.isTrue($block); };
sub if (Bool $test, Code $ifblock, ElseCode $elseblock)
{ $test.ifTrue($ifblock); $test.ifFalse($elseblock); };
sub unless (Bool $test, Code $block) {$test.isFalse($block);};
sub unless (Bool $test, Code $ifblock, ElseCode $elseblock)
{ $test.ifFalse($ifblock); $test.ifTrue($elseblock); };
sub else (Code $block) returns ElseBlock { $block };
sub elseif (Bool $test is lazy, Code $block)
{ if $test, $block; };
sub elseif (Bool $test is lazy, Code $block, ElseCode $elseblock)
{if $test, $block, $elseblock;};
etc...
Re: L2R/R2L syntax
Michael Lazzaro wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
My impression was that ~ and ~ were more general than that, and mainly
did syntax-rewriting.
So (4) above was translated in the parsing stage to be exactly identical
to (1), by the following conversions:
# original (4)
@in ~ map { ... } ~ grep { ... } - @out;
# Fully Parenthesized
(((@in ~ map { ... } ) ~ grep { ... } ) - @out
# @a ~ function becomes function @a
((map { ... } @in) ~ grep { ... } ) ~ @out
# @a ~ function === function @a
(grep { ... } (map { ... } @in)) ~ @out
# @a ~ @b === @b = @a
@out = (grep { ... } (map { ... } @in))
# removal of duplicate parenthesis
@out = grep { ... } map { ... } @in
So the syntax in (1) is still valid.
With (2) and (3), the situation is different, because they get
syntax-converted into a different form:
# Original (3)
@out ~ grep { ... } ~ map { ... } ~ @in;
# fully parenthesized
@out - ( grep { ... } ~ ( map { ... } ~ @in));
# function ~ @a function :@a
@out - { grep { ... } - { map { ... } :@in ));
# function ~ @a = function :@a
@out ~ grep { ... } :(map { ... } :@in)
# @a ~ @b = @a = @b
@out = grep { ... } :(map { ... } :@in)
which is horrible, and no one would want to use that directly as opposed
to syntax (1). But I can see beauty in (2) or (3).
Of course, since indirect-object syntax is syntactic sugar itself, this
goes on to be:
# function :@a === @a.function, applied repeatedly
@out = @in.map({...}).grep({...});
which is yet another L2R syntax.
But it also implies that map(block) and grep(block) are methods on
arrays (or Arrays).
The issue, as I see it, is that some people like to follow data flow
from right to left through a chain of actions. Perl 5 supported this
fine when it came to chained function calls:
sub byChar { $a cp $b }
for @words {
my $anagram = sort byChar split //, $_; # R2L flow of data.
push @$anagrams{$anagram}, $_;
}
Other people like to follow data flow from left to right through a chain
of actions. Perl 5 supported this fine when it came to method invocations:
$emplyeeTable-select('unionized')-raiseSalary(0.05);
But if you needed to have a chain of function calls, you couldn't easily
do left to right, and if you needed to have a chain of method
invocations, you couldn't easily to right to left.
The one saving grace for method invocation was the use of indirect
object syntax, which says that if the first argument of a
multi-argument function is an object and is not followed by a comma,
then the function should be interpreted as a method on that object:
print $filehandle $text;
is equivalent (in Perl 5) to
$filehandle-print($text);
But that doesn't scale. You can do the block that evaluates to an
object trick to do some chaining, which gets you:
raiseSalary {select $employeeTable 'unionized'} 0.05;
But that is ugly as sin and not truely Right to Left; it's more Middle
to Out.
To summarize (and, Piers, you can quote me on this)
Perl 5 allows you to do:
$object-meth1-meth2-meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~ sub1 ~ sub2 ~ sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 ~ meth2 ~ meth1 ~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '-'
is now spelled '.'
The additional functionality that when the last sub or method in the ~
and ~ is a variable an assigment is done is a convenience issue.
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
(As an aside
I almost wish that calling a method with an incomplete argument list
would return a curried function, because that means that
$data ~ print ~ $filehandle;
would work!)
Re: L2R/R2L syntax
Brent Dax wrote:
Incorrect. The translation sequence is:
@in ~ map { ... } ~ grep { ... } ~ @out
((@in ~ map { ... }) ~ grep { ... }) ~ @out
((@in.map({ ... })).grep({ ... })) ~ @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only difference between '~' and '.' is that '~' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
I didn't read that as stating a semi-equivalence between '~' and '.'.
I guess I live and learn.
Re: L2R/R2L syntax (was Re: Everything is an object.)
[Note: I originally sent this to Mr. Nobody alone, but that wasn't my intent. I'm re-sending it here, where I wanted it to go in the first place. -- bmb] Mr. Nobody wrote: trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. I can also type or relatively easily as well. (I have no idea how well those will be transmitted on this list. I typed hiragana using the hiragana script, and katakana in katakana, two of the standard character sets of Japan. I'm not sure why I have my computer at work set up to allow me to input Japanese, since I'm not ? ?? nor do I speak ???) But the techniques for typing in funky characters is well known, and easy. Most likely, in the future when I have to work in Perl 6, my editor will be set up so that typing the Unicode squiggly-arrow character will be as simple as typing the two characters '~' and '', just like typing a Spanish N is as easy as typing '~' and 'N' right now. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: This week's Perl Summary
Mr. Nobody wrote: If you and Damian think you'll get me to leave p6l this easily, forget it. I've seen far worse flames than that. While you were the person that Damian lost his sense of humor at, Piers didn't identify you in this part of the summary. So I don't think Piers was trying to get you to leave.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote:
I would, from the descriptions, imagine that:
@keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;
Would parse as:
@keep ~ grep /good/ ~ @list;
@list ~ grep /bad!/ ~ @throw;
Nope. ~ and ~ only *rearrange* arguments, so if you only type @list
once, you can only do things that you could before when you typed
@list only once.
So what we have is (using a scalar for an arbitrary variable) is:
$a ~ subroutine $arg1;
is equivalent to:
subroutine $arg1, $a;
and
subroutine $arg1 ~ $a;
is equivalent to:
subroutine $arg1 $a:; # or , equivalently, subroutine $a: $arg1;
and
.. ~ $a;
is equivalent to
$a = ...;
and similarly,
$a ~ ...;
is equivalent to
$a = ...;
~ is left associative, ~ right associative, have the same precedence,
and can't be mixed in one expression because of conflicting associativity
That means that a standard chain like:
@list ~ grep /good/ ~ map - { s/good/bad/ } ~ @badlist;
would parse as
((@list ~ grep /good/) ~ map - { s/good/bad/ } ) ~ @badlist;
to
((grep /good/ @list) ~ map - {s/good/bad/ } ) ~ @badlist;
to
(map - {s/good/bad/}, (grep /good/ @list)) ~= @badlist;
to
@badlist = (map - {s/good/bad/}, (grep /good/ @list));
to
@badlist = map - {s/good/bad/}, grep /good/ @list;
(modulo possible regex sytax).
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote:
Something else springs to mind. Consider the Cfor syntax:
for 1,2,3 ~ foo - $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
I think I see what you're saying...
$a ~ foo;
calls foo on $a, while
$a - $x { ... }
um, does nothing... OK, I didn't see what I thought I said.
Actually, I do see something like:
$a ~ - $x { ... }
as having meaning, namely call the anon sub with $a as an argument.
Does syntax already exist for doing that? Can one do:
- $x { ... } ($a);
already?
If not, then the ~ - construct has a use, perhaps a semi-common use,
and perhaps it should be simplified. Not to suggest another operator
here, but $a ~- $x { ... } anyone?
But you were looking for a way to play off their similar meanings to
avoid having to use a tilde
The BNF for anonymous subs is something like (I haven't read the
existing grammars, so if I'm not using the standard terms...sorry):
anon_sub :== sub block
| sub ( paramlist ) block
| - block
| - paramlist block
The BNF for left-to-right pipelines would be something like:
lr_pipe :== lr_pipe ~ variable
| lr_pipe ~ function_call
If we were to combine - and ~, would it lead to any ambiguity? I'm
not sure. Certainly we'd be talking about more than a one-token lookahead.
Actually, I'm not sure the lr_pipe is unambiguous in its own right. I
don't have it complete, obviously, but I see problems with the two calls
as is...
What is the result of:
$input ~ %functionTable{$state} ~ $state;
Is it equivalent to:
%functionTable($state) = $input;
$state = %functionTable($state);
or
$state = %functionTable($state).($input);
How does the grammar differentiate between the two?
Or would I have to type
$input ~ %functionTable{$state}.() ~ $state;
instead?
Dave.
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(resent as requested)
James Mastros wrote:
Here's my basic defintion of ID: Two things should have the same ID
if-and-only-if they will behave exactly the same, now and forevermore.
Thus, there should be one ID for all constants of the same value, which
is different from all constants of different value. (This is probably
unimplementable if we gaurntee IDs are of some constant length.)
Two objects should only have the same ID if they are aliases of
each-other: they always have the same instance values, and the same
value (but) properties.
Promotable, but unpromoted, Ints should have different IDs, because they
may at some point, have different values.
Any unconsidered cases?
What about value objects (objects with no methods to change state after
creation?
class Complex {
# Hmmm, what's the attribute syntax this week?
attr .real is ro is public;
attr .imaginary is ro is public;
sub new($r, $i) {
my Complex $obj;
$obj.real = $r;
$obj.imaginary = $i;
return $obj;
}
method .magnitude { return sqrt($.real * $.real
+ $.imaginary * $.imaginary);
}
method .conjugate ( return Complex::new($.real, -$.imaginary); }
sub operator::* (Complex $a, Complex $b) is exported {
return Complex::new($a.real*$b.real-$a.imaginary*$b.imaginary,
$a.real*$b.imaginary+$a.imaginary*$b.real);
}
}
If I wrote the Perl6 code correctly (and no guarantees that I hit this
moving target), then once created, a Complex object cannot be modified
and is indistinguishable by behavior from any other Complex object with
the same value:
my Complex $a = Complex::new(5,4);
my Complex $b = Complex::new(5,4);
Is it reasonable to have $a.id == $b.id?
Re: Superpositions and laziness
Jonathan Scott Duff wrote:
On Fri, Nov 08, 2002 at 05:30:00PM +0100, Paul Johnson wrote:
On Fri, Nov 08, 2002 at 03:04:16PM +, Nicholas Clark wrote:
On Fri, Nov 08, 2002 at 08:22:17PM +1100, Damian Conway wrote:
The name of the property is still under debate. Larry favours:
sub square ( Num $n ) is same {...}
whereas others feel that:
sub square ( Num $n ) is memoized {...}
is more appropriate.
We're looking for a word that tersely expresses has_no_side_effects_and_can_safely_have_its_results_cached_based_on_parameter_types_and_values_and_calling_context ?
The functional programmers will tell you that word would be pure.
I like memoize only because perl has made me used to the term.
But pure works too.
To me, pure described the function, but it doesn't imply any
optimization. cached or memoized implies optimization.
sub fib1(int $x) is pure {
return 1 if $x 2;
return fib1($x-1) + fib($x-2);
}
print time { fib1(1000); };
print time { fib1(1000); };
could print the same time for both operations.
sub fib2(int $x) is memoize { fib1($x); }
print time { fib2(1000); };
print time { fib2(1000); };
should return a long time for the first call, and a very short time for
the second call.
Actually, I can think of another use for 'pure', as an optimization hint.
sub foo {
for 1..1_000_000 - {
an_impure_fibonacci($_);
}
return 10;
}
versus
sub bar {
for 1..1_000_000 - {
a_pure_fibonacci($_);
}
return 10;
}
Both foo() and bar() return 10, and both do a similar amount of work
computing 100 fibonacci numbers. But I can see that the optimizer,
seeing that bar uses a pure version of fibonacci knows that it is
side-effect free, so optimizes sub bar {...} to the much faster
sub bar {10};
(I still don't understand the rules for when and where the semi is
expected).
I'm not sure that memoize works for that. Imagine:
sub opendb($dsn, $user, $password) is memoize { ... };
-Scott
Re: Superpositions and laziness
Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
From: Luke Palmer [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Thu, 7 Nov 2002 13:49:14 -0700 (MST)
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Date: Thu, 07 Nov 2002 20:48:50 +1100
From: Damian Conway [EMAIL PROTECTED]
we could make it lazy thus:
sub a_pure_func(Num $n) is lazy returns Num {
return $n ** $n
}
which would cause any invocation of Ca_pure_func to cache
its arguments (probably in a closure) and return a proxy
Num that carries out the computation only when the proxy is
evaluated.
sub a_pure_func(Num $n) returns Num {
class is Num {
method FETCH { $n * $n } }.new
}
Whoops, I mean...
sub a_pure_func(Num $n) returns Num {
class is Num {
has Num $cache;
method FETCH { $cache //= $n * $n } } }
Wow, I've never seen such a compact implementation of such a thing. I
love you, Perl 6 3]
This is better, but it doesn't deal with STORE or does it? Nope, it
doesn't. You need to delegate to $cache.
Hmmm...
sub a_pure_func(Num a) returns Num {
class is Num {
has Num $cache is delegate;
method FETCH {$cache //= $n * $n } }.new }
Or...
sub a_pure_func(Num $a) returns Num {
class is Num (
has Num $cache;
method FETCH { .cache //= $n * $n }
method STORE(Num $x) { .cache = $x } }.new }
I think
Luke
Re: list comprehensions
Jonathan Scott Duff wrote:
On Wed, Nov 06, 2002 at 12:54:12PM -0500, Mark J. Reed wrote:
On 2002-11-06 at 11:43:20, Jonathan Scott Duff wrote:
Will there be some shorter-hand way to say these?
a = grades[grep $_ = 90, grades];
b = grades[grep 80 = $_ 90, grades];
c = grades[grep 70 = $_ 80, grades];
I think what you mean here is just
a = grep $_ = 90, grades;
etc. grep returns the actual elements, not their indices, so it doesn't
make sense to use them as a slice.
Er, yeah. I must be subcaffienated right now. :-(
What I was trying to get at was the ability to slice based on the values
instead of the indices. But maybe it's just the python programming that
I've been doing that makes me think it's useful.
-Scott
I think that if there were a slice-based form of grep, it would most
likely look like you are indexing by a subroutine (or method) reference
that takes no arguments other than an element of the array. Something like:
a = grades[{$^x 90}];
or
a = grades[- x { $x 90}];
or
my StudentGrade grades;
a = grades[.isPassing];
I could see that as being useful.
Of potentially more use would be:
%grades = { Tom = 85, Mary = 95 };
%a_students = %grades{- $name, $grade { $grade 90 } };
print keys %a_students; # 'Mary'
Re: list comprehensions
Piers Cawley wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Will there be some shorter-hand way to say these?
@a = @grades[grep $_ = 90, @grades];
@b = @grades[grep 80 = $_ 90, @grades];
@c = @grades[grep 70 = $_ 80, @grades];
Granted, it's fairly compact as it is but I'm wondering if there's
some way to not have to mention @grades twice per statement.
What's wrong with
@a = grep { $_ = 90 } @grades;
@b = grep { 80 = $_ 90 } @grades;
@c = grep { 70 = $_ 80 } @grades;
Or am I missing something? The examples you give seem to imply that
you should use the value of the things contained in @grades as indices
into @grades, and return the values thus indexed. There may be a good
reason for doing this, but one escapes me for now.
I don't see why I'd want to do it with arrays, but...
%a_students = %grades{grep /^a/i, keys %grades};
'for' clarification, summary...
Here's my current understanding of what's under discussion for for-loops:
Larry wants to eliminate the ; from the RHS of the -, so the only thing
for needs to know about the RHS is the number and types of the
arguments. This puts the specification about how to generate those
arguments on the LHS of the -, and only there.
Examples:
# process array, one element at a time
for array - $x { ... };
# process array, in pairs
for array - $x, $y { ... };
# process all of a, then all of b, one element at a time
for a, b - $x { ... };
# process a, then b, in pairs (a[0] and a[1] first, etc)
for a, b - $x, $y { ... };
# process a and b in interleaved pairs (a[n] and b[n])
for zip(a, b) - $x, $y { ... };
# process in a[0], b[0], a[1], b[1], ... order
for zip(a, b) - $x { ... };
# triples from a, b and c, alternately
for zip(a, b, c, 3) - $x, $y, $z { ... };
# triples from a, pairs from b, together
for weave( a = 3, b = 2) - $v, $w, $x, $y, $z { ... };
What is undecided is the exact name and syntax of zip() and weave().
(Note: in my sample syntax, zip(a, b, c, ...) is the same as
weave(a=1, b=1, c=1,...) and zip(a, b, c, ..., n) is the same
as weave (a=n, b=n, c=n, ...).
My feeling:
It seems the real definition for 'for' is something like:
sub for(a is rw, s) {
my $numargs = s.signature().length;
s(a[0..$numargs-1]);
for(a[$numargs...], s);
}
and zip(), weave(), or equivalents would be array generators.
This would mean that things like:
sub printproducts($x, $y) { print $x*$y, \n; }
for zip(multiplicands, multipliers), printproducts;
and it would print one product for each pair of factors.
Hmm, what (if anything) would this do, modulo minor syntax errors:
my $twoByTwo = - ($x, $y) {
print Noah led a $x and a $y onto the ark\n; }
my $threeByThree = - ( $x, $y, $z) {
print Shem led a $x, a $y, and a little baby $z off of the ark\n; }
my $arksubs = $twoByTwo | $threeByThree;
for a, pick($arksubs);
Re: [RFC] Perl6 HyperOperator List
Larry Wall wrote:
Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats. The basic
rule is that for any op, [op] is also expected in the same place. So
if the user defines a postfix:! for factorial, they automatically get
_[!] for that as well.
I think we could also allow
a [??] b [::] c
But it's not clear whether we can parse
a = [undef][...]
How would you parse:
a = b[[5]];
(My intent: for a; b - $x is rw; $y { $x = $y[5] }; # I think... )
Larry
Re: Private contracts?
Peter Haworth wrote:
That *is* a logical weakening. Just because the inherited precondition is
C x 10 , doesn't mean that the weakened condition has to be of the form
C x 9 or any other value lower than 10. C a || b is weaker than
C a
So what we are looking at is something like
class Animal {
method eat($food) is abstract {
PRE { $food.isa(Edible); }
POST { !$stomach.empty; }
}
...
}
class Goat is Animal {
method eat($food) {
PRE { $food.isa(Can); }
my $chewedfood = $teeth.chew($food);
$stomach.add($chewefood);
$teeth.brush()
POST { $teeth.clean; }
}
...
}
class Teeth {
method brush {...};
method chew {
...
POST { .clean == false; }
}
}
my Animal $billy = new Goat;
$billy.eat(Banana.new()); # succeeds because PRE for Animal.eat is met
$billy.eat(Can.new()); # succeeds because PRE for Goat.eat is met
$billy.eat(Rock.new()); # Fails because neither PRE is met
class DirtyTeeth is Teeth {
method brush {};
...
}
$billy.teeth = DirtyTeeth.new();
$billy.eat(Banana.new()); # Fails because POST for Goat.eat is not met
etc.
Are there
other ways to do it, just to mull them over?
Re: auto deserialization
[EMAIL PROTECTED] wrote:
From: Trey Harris [EMAIL PROTECTED]
no strict 'refs';
my Date $date;
$date .= 'Sep 21, 1963';
There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or the
class
because the compiler would understand what to call. It would see that
$date is in the Date class, and 'Sep 21, 1963' is in the String class, so
it would pretend the statement really reads
$date = Date::new_from_String('Sep 21, 1963');
my Date $date;
$date .= getText(/Transaction/TransactionDTM);
does this call the locally visible function/method getText, take the
string that results from that, and then does $date =
Date::new_from_String() on the result, or does it try to do
$date = $date.getText(/Transaction/TransactionDTM);
My feeling is the latter.
$date += 4; # $date = $date + 4;
$date -= 4; # $date = $date - 4;
$date *= 4; # $date = $date * 4;
$date .= foo; # $date = #date.foo;
I suspect that, if it makes sense to say
$foo = $date.method;
then it would also make sense to say
$date .= $foo;
as well.
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: sub/method refs (was Re: auto deserialization)
Trey Harris wrote: In a message dated Tue, 3 Sep 2002, Buddha Buck writes: I suspect that, if it makes sense to say $foo = $date.method; then it would also make sense to say $date .= $foo; as well. Interesting, that first line $foo = $date.method; I need a bit of a refresher here, as my searches of the archives have turned up blank. Ampersand replaces P5 C\ in taking a reference to a subroutine or method? And ampersand is no longer used to call a subroutine, in any context? Actually, I think I got confused... Most of my work recently has been in C++, which uses for references. Perhaps that should have been: $foo = \$date.method; So: $foo = $date.method(); Would call $date.method, and return a reference to (a reference to) the subroutine returned by Date::method()? I have a feeling that, as much nicer as Perl 6 references will be compared to the Perl 5 punctuation-salad, it will take a long time to do it automatically. It'll feel like grabbing for the stick-shift and clutch that aren't there when you're driving an automatic Trey
Re: A5: Is this right?
At 11:31 AM 06-06-2002 -0700, Brent Dax wrote:
#Preliminary Perl6::Regex
# This does not have any actions, but otherwise I think is correct.
# Let me know if it's right or not.
I'm not a regex guru, but...
use 6;
grammar Perl6::Regex {
rule metachar { [{(\[\])}:*+?\\|]}
rule ws { [[\h\v]|\#\N*]*}
rule atom { ws (!metachar | \\ . | group) ws }
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+
rule modifier { ws ([*+?] \?? \:?) ws }
rule molecule {
( atom modifier
atom ends with ws, modifier begins with ws. Does that mean that
there must be two ws between an atom and a modifier? (Possibly not,
since ws can match null, so 'a*' would match ws with four nulls). Just
clarifying for myself.
| ws \:1,4 ws
| compound ws \| ws compound
)
}
rule compound { [(molecule)]* }
rule group{ws
( \( compound \)
| \[ compound \]
| \{ Perl6::Code \}
| \ !? [ \w+ | \d+ , \d+ ] compound \
)
ws
}
}
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
Nonsense, Patrick declared. All you have to do is say, 'Engage.'
--Star Trek: The Next Generation Technical Manual
Re: Backslashes
At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
Here's an easier one: backslash followed by the delimiter is that thing.
Everything else is literal.
print 'c:\it\'s\easier\to\write\win32\paths\this\way';
print q{this is ok { and so is \} } C:\this };
I desire you print your statement above. Would it be:
print 'print \'c:\it\\'s\easier\to\write...\';';
The quesiton here is that C\\', which means something different in
your recommendation than it means in Perl5, but still does the same
thing
And the other question is how to get a string that ends in a \?
$hiddendirectory = q{C:\$ecret$tuff\mp3\don't tell the mpaa\};
Is there any gotcha, here? I'm not sure, but it's tickling my brain in
an odd way, and I keep wanting to say that it breaks down somewhere
Is the above the gotcha you've been looking for?
Re: Please rename 'but' to 'has'.
At 09:45 AM 04-26-2002 -0700, Larry Wall wrote:
Tim Bunce writes:
: For perl at least I thought Larry has said that you'll be able to
: create new ops but only give them the same precedence as any one
: of the existing ops.
Close, but not quite. What I think I said was that you can't specify
a raw precedence--you can only specify a precedence relative to an
existing operator. That way it doesn't matter what the initial
precedence assignments are. We can always change them internally.
: Why not use a 16 bit int and specify that languages should use
: default precedence levels spread through the range but keeping the
: bottom 8 bits all zero. That gives 255 levels between '3' and '4'.
: Seems like enough to me!
:
: Floating point seems like over-egging the omelette.
It's also under-egging the omelette, and not just because you
eventually run out of bits. I don't think either integer or floating
point is the best solution, because in either case you have to remember
separately how many levels of derivation from the standard precedence
levels you are, so you know which bit to flip, or which increment to
add or subtract from the floater.
snip
So you'd have something like:
sub operator:mult($a, $b) is looser('*') is inline {...}
sub operator:add($a, $b) is tighter(+) is inline {...}
sub operator:div($a,$b) is looser(/) is inline {...}
assuming default Perl5 precedences for *, *, and / you would have the
precedence strings for *, +, /, mult, add, and div to be S, R, S,
S2, S1, S2 respectively? So mult and div would have the same
precedences?
Hmmm What problems would be caused by:
sub operator:radd($a,$b) is tighter(+) is inline is rightassociative {...}
sub operator:ladd($a,$b) is tighter(+) is inline is leftassociative {...}
Right now, all the operator precedence levels in Perl5 have either right,
left, or no associativity, but they do not mix right and left associative
operators. Will that be allowed in Perl6?
Larry
Re: Please rename 'but' to 'has'.
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
Precedence is set with the like' property:
my sub operator:now ($a,$b) is like(but) is inline { $a but $b }
sub operator:also ($a,$b) is like(and) is inline { $a and $b }
OK, but that limits you to the, um, 24 standard levels of precedence. What
do you do if you don't think that that's enough. Let's say you want to
define a nand operator:
my sub operator:nand ($a, $b) is inline { not ($a and $b) }
but you want nand to have a precedence lower than the existing 'and' but
higher than the existing 'or' (for some reason I can't imagine
offhand). It isn't like() anything, since there isn't anything currently
between 'and' and 'or'. Would that be something like:
my sub operator:nand ($a, $b) is below(and) is inline {not ($a and $b) }
Re: Please rename 'but' to 'has'.
At 01:12 PM 04-23-2002 -0400, [EMAIL PROTECTED] wrote: 24 levels of precedence should be enough, else you can always resort to parens. I would have agreed, except that I would have also said that the 14 precedence levels of C should be enough as well -- yet we seem to have discovered uses for 10 more. Guillaume
Re: Perl6 Macros
Michel J Lambert [EMAIL PROTECTED] writes:
Macros could add something to Perl, but I don't see why having a macro
return a string instead of looking and acting like a subroutine would be
a bad thing. In fact, as I pointed out before, you can do almost all of
the scoping stuff that you would want out of a macro in Perl with the
existing subroutine/code ref syntax and a special property.
I disagree here. How would I define foreach as a macro (assuming the
following, simplified syntax).
foreach $each, @array, {
print $each;
};
Since $each is being passed to the foreach macro, the macro needs to
create a lexical scoping for $each, and place the third argument as a loop
body, within the context of the scoping it just defined.
That suggested a similar example to me...
In Lisp (or, more likely, Scheme), you get constructs like:
(let ((a 'b) (c 'd) ... ) (...))
being defined as equivalent to:
((lambda (a c ...) (...)) 'b 'd ...)
and the macro system can convert the let into the evaluated lambda.
Suppose we wanted to have a Perl construct that was similar:
my $a = let ($b - 5, $c - $x) { $b + $c };
The most similar replacement for the let to the lisp case is:
my $a = (sub { my ($b, $c) = @_; return $b, $c; })(5, $x);
With the macro system (using qs() for things to be evaluated at
compile time), I could see something like:
macro let (%)
{ (sub { my qs(keys @_[0]) = @_; return qs(@_[1]); })(qs(values @_[1]))};
I'm not sure that that would work perfectly offhand (I suspect some
syntax tweaking would be necessary) but it's the basic idea I think
you are going for.
--
Buddha Buck [EMAIL PROTECTED]
I will not die an ironic death -- Scott Ian, lead singer for
the metal band Anthrax, after bioterrorist attacks using anthrax.
Re: Apoc4: The loop keyword
At 11:40 AM 01-25-2002 -0600, Jonathan Scott Duff you wrote:
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
What we're cleaning up is the ickiness of having things declared outside
the braces be lexical to the braces. *That's* hard to explain to
beginners.
But it's handy. And that was, until now, what mattered with Perl.
No, handiness still matters with Perl. It's just that the balance has
tipped a wee bit towards the consistency/regularity/simplicity/whatever
side of the scale.
Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes mnemonic sense.
But then I'm sure that someone will come out of the woodwork and say
What about if ((my $a = foo()) ($b 4)) ? or something. To
which I'd say Fooey! I personally don't think that an extra set of
curlies are too high a price for getting rid of weird scoping rules.
But that's just me.
We have
while (foo()) - $a {...}
doing the right thing.
Why can't
if foo() - $a { ... }
take the place of the perl5
if (my $a = foo()) {...}
Too bad we can't do
while (foo() - $a) ($b 4) { ... }
and have it do the right thing.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
Dan Sugalski [EMAIL PROTECTED] writes: Okay, I'm whipping together the fancy math section of the interpreter assembly language. I've got: snip Can anyone think of things I've forgotten? It's been a while since I've done numeric work. Uri mentioned exp(x) = e^x, but I think if you are going to include log2, log10, log, etc, you should also include ln.
Re: Circular references
At 01:01 PM 08-01-2001 -0600, Sterin, Ilya wrote: I was just wondering if there will be any solution for the circular refernece memory leak (I guess you can call it a problem). Can't we keep information on the number of circular references in the SV structure and then decrement the references count by one + the circular reference count at the end of scope? Dan has already answered (dead-object detection sweeps by the GC will take care of it), but I'm curious? How do you detect a circular reference so you can update the circular reference count? Ilya
Re: Circular references
As a necrohipposadist (beater of dead horses), I'll add...
Sterin, Ilya [EMAIL PROTECTED] writes:
Well guess not, since something like this...
{
my ($a, $b, $c);
$a = \$b;
$b = \$c;
$c = \$a;
}
would definitelly be hard, resource consuming to implement a circular
reference count.
Even that's not that difficult. There's just one loop. How about:
sub newgraph {
my $noderef = shift;
my @nodes = @$noderef;
my $edgesref = shift;
my @edges = @$edgesref;
my %graph;
foreach (@nodes) { $graph{$_} = [] }
while (@edges) {
my $source = shift @edges;
my $dest = shift @edges;
push @$graph{$source},$graph{$dest};
}
}
In this horrid little data structure, every reference of interest is a
reference to arrays of references, all of which are parts of circular
references. This is not necessarily a good way to store a directed
graph, but it works (and some would think it has some benefits in some
cases). But each push could introduce lots and lots of new loops that
would have to be accounted for.
However, more realistically, I could imagine someone coding a tree
where each node had pointers to its parent, its children, its
siblings, its next and previous nodes, etc. All of which would
lead to numerous circuits. Again, each addition to the tree would
introduce numerous, potentially hundreds or thousands, of circuits.
The same would happen on every delete, too.
Ilya
Re: http://www.ora.com/news/vhll_1299.html
At 03:07 PM 07-09-2001 -0400, Adam Turoff wrote:
On Mon, Jul 09, 2001 at 02:36:17PM -0400, Sam Tregar wrote:
On Mon, 9 Jul 2001, Adam Turoff wrote:
Don't laugh. It's here now. It's called XSLT. :-)
Um, that's not what the article was talking about The proposal is to use
an XML syntax to program in existing VHLL languages, including Perl.
...and we have a working example of what a bad idea that is with XSLT.
XSLT has, as a major failing, it's XML-based, lisp-like syntax which takes
the Lots of Insideous Silly Parenthesis problem and makes it even
worse. The scheme code:
(define (addone x)
(+ x 1))
...
(addone 3)
becomes in XSLT
xsl:template name=addone
xsl:param name='x'/
xsl:value-of select=$x+1/
/xsl:template
...
xsl:call-template name=addone
xsl:with-param name=x select=3/
xsl:call-template
That is obviously horrid syntax, but it fits XSLT's goals of being embedded
in XML and able to co-exist with other XML schemata.
But that doesn't have to be how a programming language and XML can interact:
section
Procedure iprime_the_change_buffer/i sets ichange_buffer/i in
preparation for the next matching operation.
code
void
prime_the_change_buffer()
{
change_limit = change_buffer; /* this value is used if the change file
ends */
insert section=Skip over comment lines in the change file; |return| if
end of file/
insert section=Skip to the next nonblank line; |return| if end of file/
insert section=Move |buffer| and |limit| to |change_buffer| and
|change_limit|/
}
/code
/section
(code gotten from CWEB 3.0 by Donald Knuth and Silvio Levy)
Running that though the proper processor (probably written in XSLT) could
generate the same results as cweb (although rewriting cweb in XSLT seems a
not-so-good proposition.
XSLT is a good idea in *it's* domain, but very bad for a general purpose
programming language.
True, agreed, and admitted. So why can't a general purpose programming
language be designed with XML-based syntax? Why can't a general-purpose
programming language be augmented with XML for internal documentation purposes?
What's your question? XML Editors are not the limiting factor
preventing XML-based programming languages; that argument doesn't
stand up in the face of XSLT adoption. The dubious value of those
beneifits (and the re-engineering cost) are the true limiting factors.
As has been admitted, XSLT sucks. On the otherhand, take a look at a
decent Smalltalk environment sometime.
The browsers which are use to examine and modify code completely isolate
the programmer from the underlying representation. Although the technology
used in Smalltalk is older than XML, I could easily see it being done
-today- using XML, and the programmer never being the wiser.
Z.
Re: http://www.ora.com/news/vhll_1299.html
At 03:55 PM 07-09-2001 -0400, Adam Turoff wrote: On Mon, Jul 09, 2001 at 03:48:27PM -0400, Buddha Buck wrote: Why can't a general-purpose programming language be augmented with XML for internal documentation purposes? You mean like C#? :-) I wasn't specifically referring to that; I was thinking more along the lines of literate programming, or Javadoc, or POD. I wasn't aware that C# used XML for doc purposes. Z.
Re: 1 until defined(getvalue()); return it;
At 06:54 PM 05-30-2001 +0100, Michael G Schwern wrote: On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote: while pseudocoding something I realized that it would be really cool if there was another magical default shelf, like $_ or _ but subtly different, that stores, if lexically used, the object of the most recent defined or exists -- or maybe even the most recently referred to scalar, just the way it works in English. it would change much more often than $_ does. *quiver* Please god no. Its difficult enough to follow the twists and abuses of $_ when reading code. That aside, could you put together a code example of what this wins? I'd be interested in seeing how it would be better than what works now. Why is: 1 until defined(getvalue()); return it; better than 1 until defined($foo=getvalue()); return foo; ? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: Separate as keyword? (Re: 'is' and action at a distance)
At 01:34 PM 05-18-2001 -0700, Nathan Wiger wrote: Dammit, I got the example exactly backwards. Try this: $Foo is true; $Foo = 0; print Stuff if $Foo; # *WOULD* print - is assigns a # permanent true property $Foo as true = ; $Foo = 0; print Stuff if $Foo; # *WOULD NOT* print - as is reset by # value assignment since is temporary I tend to think of the temporary/permanant distinction being a rvalue/lvalue distinction. Perhaps the rvalue/lvalue context of the property assignment could be used to determine whether it's temporary or permanant? $Foo = 0 is true; # $Foo has a true value print $Foo is true if $Foo; # prints 0 is true $Foo = 0; # $Foo has a false value print $Foo is true if $Foo; # does not print. $Foo is true = 0; #$Foo is true regardless of value print $Foo is true if $Foo; # prints 0 is true $Foo = 0; #$Foo is still true, despite false value print $Foo is true if $Foo; # prints 0 is true $Foo = 0 is false; # Hmm, lvalue $Foo is true, but assigned -declared- false value... who wins? print $Foo is true if $Foo; # ?? We'd also need to come up with better syntax for: $Foo is true = $Foo; for changing the lvalue properties of $Foo without changing the rvalue contexts... Later, Buddha
Re: Exegesis2 and the is keyword
Austin Hastings [EMAIL PROTECTED] writes:
Let it be.
Not a flame, but a suggestion:
let $pi be constant;
Personally, I'd rather save let for:
(let ($x,$y,$z,...) = (1,2,3,...) in { ... })
which would be equivilant to:
((sub {my ($x,$y,$z,...) = @_; ... })(1,2,3,...))
Many functional languages use let to mean something similar.
On that note... will there be any provision for formal arguments to
anonymous subs?
If I understand the brief mentions of subroutine signatures, we will
be able to use syntax like:
sub foo (@array, $scalar, %hash) { ... } ;
Will we also be able to do:
$foo = sub (@array, $scalar, %hash) { ... } ;
to get a reference to an anonymous sub with the same signature?
If so, then
$foo = (let (...) = (...) in {...});
could be equivalent to:
$foo = ((sub (...) {...})(...));
That any better?
=Austin
--- Dan Schmidt [EMAIL PROTECTED] wrote:
Peter Scott [EMAIL PROTECTED] writes:
| I've been reading is as a declarative imperative, something which
| declares a property of something you are creating. Here it's being
| used to modify the properties of something that already exists, and
| it reads funny to me. Many properties that one can set at
| declaration time are compile time only, yet this usage might
suggest
| to many people that they can be changed at run time. If you see
| what I mean.
Clearly we need 'becomes' and 'gets' for mutable properties, in
addition to 'is' and 'has' for constant ones.
--
http://www.dfan.org
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Re: apo 2
At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote: On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: And btw . . . Wouldn't $thing has property make more sense than $thing is property $foo has true doesn't flow as well as $foo is true. Dunno quite what the other expected uses are. Maybe has and is, used in this context, could be synonyms? my NetFile $page has url(http://www.perl.com/;); $page is constant; or maybe my Netfile $page has url(http://www.perl.com/;) is constant; (can properties stack like that?) I think it depends on the property whether has or is is grammatically correct. Or we could have a policy that all example-properties have the has-nature. Instead of: $foo is true; $foo is true(1); $foo is true(0); we would have: $foo has truth; $foo has truth(1); $foo has truth(0); Or some such...
RE: apo 2
At 10:49 AM 05-04-2001 -0500, Garrett Goebel wrote: From: Buddha Buck [mailto:[EMAIL PROTECTED]] At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote: On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: And btw . . . Wouldn't $thing has property make more sense than $thing is property $foo has true doesn't flow as well as $foo is true. Dunno quite what the other expected uses are. [...] my Netfile $page has url(http://www.perl.com/;) is constant; Maybe it is just my interpretation of Damian's OO-Perl book... but: 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).
Re: Curious: - vs .
Bart Lateur [EMAIL PROTECTED] writes: On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. Yes, well, some people want to get rid of the indirect object syntax, not require it. I don't use it myself, but my understanding is that $bar = method $obj() is legal right now, and that your second example isn't a special-case but just one example of the general case. -- Bart.
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Oops, meant anonymous array. To be overly pedantic I thought [$one, 2, 3] was a ref to an anonymous array... Other than severe dependence on the comma, is there any reason why we couldn't have the following? [snip] Apart from the fact that we're adding one more meaning to [], one which has no mnemonic relationship with arrays, no reason at all. Since it looks like we are going to be getting $object.method() anyway, it doesn't matter much. It was more of a facetious suggestion to begin with -- although that doesn't mean that it wouldn't work, it's just not going to happen, and I know it. Piers Cawley www.iterative-software.com
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error -- Piers Cawley www.iterative-software.com
Re: Dot can DWIM without whitespace
Edward Peschko [EMAIL PROTECTED] writes:
beautiful. Then extending this is simple, consistent, easy to read,
compatible with perl5..
I'm not sure that that was the point I was trying to make.
If nothing else, the '.' would then be responsible for *three*
different actions.
Right, but what *I* am saying is that any given user is already conditioned to
the fact that it can mean different things in different circumstances.
And like I said earlier, if we make $a . $b the only proper form for
concatenation, I don't think that there is going to be much of a learning curve.
In any case, I like it better than yet another punctuation mark.
I see, and you would be willing to break the cases where I may want to
put spaces around the . used for method invocations for clarity?
{
$foo . foobar (Test1);
$foobar . baz(Test2);
$tmtowdi . quux (Test3);
}
That specific use of whitespace I don't do often, but I could see
doing it. I often do something like that when working with other
variable length identifiers.
Ed
Re: Tying Overloading
At 07:44 PM 04-23-2001 +0100, Graham Barr wrote: Hm, I would expect @() in a scalar context to give the same result as @tmp = @(...); $x = @tmp; That is, yeild the number of elements in the list. I can see this. But unless there is a good reason, that seems like a less-than-optimal side-effect. What would be the benefit of it being the same as [...] ? It would be one more character. I suspect that Larry is seeing that if @() in scalar context yielded the length of the resulting operation would result in vastly more uses of: $sums = [@(@a+@b)]; than $num_of_sums = @(@a+@b); If that's the case, then it makes sense to use the shorter notation for the more common case, especially when there is an easy, shorter way to get the uncommon case: $sums = @(@a+@b); $sumcount = \@(@a+@b); # assuming that $sumcount = @a isn't sufficient.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 08:36 AM 10/4/00 -0700, Nathan Wiger wrote: =head1 TITLE Perl should use XML for documentation instead of POD =head1 VERSION Status: Frozen I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's like this when the following is true: A lot of good, heated discussion was generated on the mailing lists. The majority seems against using XML-DTD documentation, but granted there are deficiencies in POD. Is absolutely, 100% against the entire idea of the RFC process. They're "Requests for Comments". The comments received were overwhelmingly "This is a Bad Idea". I gotta disagree. You'll note that he requested comments, got comments, and reported the tone and results of those comments in v2. Also, he made no other changes, and got v2 in place 4 days after v1, 2 days after the 1 October deadline. Would you have been able to make the sort of revisions you are suggesting below under that sort of time pressure? I know I wouldn't, based on my experience with my RFCs. Retracting would have been easier, but could very well be seen as giving up on pointing out PODs deficiencies. This RFC should either be retracted, or revised into: POD to XML translation should be easier or POD should be made more flexible or Here are some deficiencies in POD that need to be fixed But freezing something that everyone's against is a waste of everyone's time. Sorry, but it is. And yes, I've retracted 7 of my own RFC's because the community was against them. The whole point of this Perl 6 process is to develop a language that the community thinks is the right direction, right? Sometimes that means accepting that no matter how much you like your idea, other Perl'ers don't. The RFCs are not the end-all of Perl development. As you stated, they are "Requests For Comments", and not every frozen RFC will get accepted by the community. Not every RFC -can- be accepted by the community; I think there are some pairs that are mutually exclusive, and intentionally so. Compare RFC 126 (Ensuring Perl's Object Oriented Future) and RFC 137 (Perl II should not be fundamentally changed). At most one of those two will "win", since they have different philosophies for Perl6 OO development. Hopefully Perl6 will be the real winner. Do you expect that your 7 retracted RFCs to be looked at by future developers? Even if they had good, but unpopular, points to make? Or do you expect that once retracted, they will be ignored? I think retracted RFCs -will- be ignored. Better to have a frozen RFC that says "no one liked my solution, but most agreed the problems existed", that gets those problems documented and -looked at- than to have the problems detailed in something most will summarily ignore. -Nate
Re: perl6storm #0050
At 03:35 PM 9/27/00 -0400, John Porter wrote: Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. While Perl -lets- every function be well prototyped, it doesn't -require- every function to be well prototyped. Because of this, it might be well nigh impossible to eliminate all ambiguity to the compiler. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote: Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; I can see that allowing expressions on @x would require considerable changes to perl core. Is there a nice way to resolve this problem? What do you think of: $x[|i] = 3 * $y[|i]; or @x = 3 * $y[|i]; It's not as clean as @x = 3 * @y, but it is cleaner context-wise. (Working on RFC207(v2) even as I write) Karl
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
At 03:35 PM 9/21/00 -0400, Buddha Buck wrote: At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote: Finally as an overload expert what do you think about the proposals to make arrays overloadable objects so one can say things like: @x = 3 * @y; What do you think of: $x[|i] = 3 * $y[|i]; or @x = 3 * $y[|i]; It's not as clean as @x = 3 * @y, but it is cleaner context-wise. And one could argue that: @x = map 3*^_, @y; is cleaner yet... Karl
Re: RFC 263 (v1) Add null() keyword and fundamental data type
At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote:
Thanks, Paris, for your intervention, although I fear it was too late.
Well, since Tom claims to have put me in his kill file, he may never see
this. But for the record...
Tom Christiansen wrote:
Can't we all just play nice?
Apparently not. Several of us attempted to explain why this didn't
make sense, for many reasons. GL wouldn't hear any of it, stubbornly
adhering to this notion despite what was said, often completely
ignoring or apparently purposefully misunderstanding the points.
It's true that I think that NULL would be an extremely useful concept,
and until there is a cogent argument to the contrary, I will continue to
believe it. I've been working with databases for 21 years, and with Perl
for 5, and I truly believe NULL would be a useful addition to using Perl
to work with databases.
Ok, let's see if I can make some sense of this...
You want a singleton scalar datatype in addition to the exising scalar
datatypes of strings, numbers, references, filehandles, and undef that
represents an unknown value, similar in semantics to the SQL notion of "NULL".
I'm going to call this prototypical datatype/value "unknown", in order to
represent its meaning in a more perlish way, as well as to avoid the
overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown
NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string,
the null list, etc). Calling anything NULL these days is likely to be
confusing, so I'll avoid it.
This doesn't matter as far as database work goes because DBI can convert
between SQL NULL and perl unknown just as easily as it can convert between
SQL NULL and perl undef.
I just reread RFC 263, and I do have some unanswered questions. How
pervasive is this "unknown" value? If $a is unknown, what about $a
Given:
$a = unknown;
print "\$a is ", ($a ? "true" : "false"), "\n";
What should print?
I think the example of:
die "Fatal, \$name is unset!" if ($name == null);
is flawed. It will never die, because as you said, two unknown values
won't compare as equal. Besides, the test would try to convert both $name
and null to numbers before doing the numerical comparison, so it would
depend on what the numerical value of unknown is. You really need a
"known()" built-in to go with this, such that known($a) is true if $a is
NOT unknown.
What gets me is that the implementation of this would require virtually
every operator, function, etc in core perl to be special-cased to deal with
the unknown value, yet the RFC makes no mention of this.
With undef, it's simply a matter of having the internal representation of
undef return 0 or "" when asked for a numerical or string value. This
makes most things deal with undef nicely -- even booleans. With unknown,
since it is specifically designed to propagate, everything would have to
deal with unknown values, not just integers, or strings, or booleans.
Importantly, unless you decide something arbitrary like "unknown is false"
like the way that it was decided that "undef is false", then you throw out
the law of excluded middle (every expression is either true or false), and
make things like the ?:, ||, or operators go all wiggly (not to mention
if, while, unless, and so forth). And if you do arbitrarily say "unknown
is false", how do you deal with the cases where you want to say "I don't
know if it's true or false"?
SQL gets away with this by saying that boolean contexts require a boolean
value, which you get by using a relational operator. People don't go "IF
variable THEN..." unless they know that variable will be boolean -- and
can't be NULL. And they then decided that using a relational operator on
NULL will always yield FALSE. That works for them.
But that's not Perl. Perl programmers like functions that return a useful
but true value on success, or undef on failure, and are quite comfortable
going:
$var = f();
if ($var) { g($var) }; # f was a success
That won't work if $var can end up being unknown. Worse, fixing it by saying
if (defined($var)) { g($var) };
doesn't help, because the RFC says that defined(unknown) is unknown!
Your unknown seems to be very special-case for doing SQL-based DB work. In
all my time programming it, I can't remember wanting it. It doesn't seem
to integrate with the rest of Perl all that well, requiring massive changes
under the hood to integrate it and the potential for messing up lots of
long-standing Perl idioms, for a relatively small benefit.
Damian mentioned that his Q::S package and RFC would/could provide
something with similar semantics, and his RFC would also likely result in
massive changes under the hood, but it also provides a large generally
useful functionality (and in CONSTANT TIME, too ;-). It is unclear as of
yet if the benefit of Q::S will outweigh the probably cost of Q::S. Can
you make as strong a case for unknown?
Notice of intent to freeze RFCs 204, 206, and revise 207
Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this
evening (17:30 New York time), and issue a revised version of 207. The
frozen versions will be substantially identical to the versions ow
released.
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya that list references will have problems when objects that used
blessed references to lists as their internal representation are used
as indices. This does indeed seem to be a problem, but I'm uncertain
how big of a problem.
Would it help if the RFC stated that the index had to be either a
scalar integer or an ARRAY ref of integers? Since objects would be
blessed as something other than ARRAY, they would need to be converted
first. If it was an object, it would try to call standard methods to
convert to a scalar integer, a list of integers, or an ARRAY ref of
integers. Just an idea.
I will include Ilya's objections (and a more formal version of the
above suggestion) in a "Summary of Discussion" section.
On RFC 206 (@#arr as bounds-fetcher), I have not really heard any
substantive comments, but most of what I've heard is positive. Please
point out to me anything I may have missed.
I will freeze 206 as-is, unless someone has something to add.
On RFC 207 (efficient array loops), based on discusion and additional
thought on my part, I want to clarify and change the syntax used in the
RFC. I also want to go into more detail about how the scope of the
efficient array loops is derived.
Here is a summary of changes:
1) Replace use of |i as a "list-like" expression to use of |i as a
"scalar-like" expression. This would prefer syntax like:
@newarray = $a[|i]*$b[|j];
over
@newarray = @a[|i]*@b[|j];
I originally viewed |i as being syntactically a replacement for a range
(0..$max), but I think that view is potentially confusing.
2) In v1, iterators converted the minimal expression containing all
iterators in a statement into a loop (or nested loops). This
unfortunately led to such clumsiness as:
{my @temp; $temp[|i] = dotproduct += $a[|i]*$b[|i];} # Not DWIMish
where it isn't clear why the @temp needs to be created and destroyed.
The RFC also required the creation of a potentially huge
multidimensional array even if such an array would then simply be
thrown away. Worse, in the "dotproduct" example above, both the
implicit array and the @temp array would be created and destroyed for
no good reason.
v2 will have iterator scope and implicit array creation dependant on
context:
Starting with the minimal expression containing all iterators in a
statement:
a) If the expression is in list context, generate an implicit temporary
array.
b) If the expression is in void context, do not generate an implicit
temporary array
c) If the expression is in any other context (scalar, lvalue, etc)
expand the expression to the minimal proper superexpression (i.e., go
up one level on the parse tree) until you have list or void context.
That would make
dotproduct += $a[|i]*$b[|i];
Do The Right Thing.
I would also state that although some of the examples used can be
better done under RFC 82, this RFC is not intended to compete with RFC
82. RFC207 and RFC82 provide two different sets of functionality that
partially overlap.
Comments? Criticism? Complaints?
Later,
Buddha
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: pack/unpack is damn unperlish. Explain them as Perl.
At 07:29 AM 9/19/00 -0700, Dave Storrs wrote: I guess, if I had to write an explanation of pack/unpack based on my limited understanding, it would be something like: "Unpack takes binary data in some particular format and disassembles it, assigning various pieces of it to variables according to formatting that you supply. Pack does the opposite, using your supplied formatting to crunch Perl scalar variables into binary data that is represented in some specific way. The binary data used by (un)pack will belong to exactly one type of C numeric variable, meaning that it will be limited in what kinds of numbers it can store and how it will represent them." Is this definition completely off-base? I think you are on track, but I would probably have defined it the other way around: "The perl function pack() takes Perl values and converts them to a compact binary representation based on a user-specified template. This is useful for communicating with external data formats that expect data to be in a particular binary format that is not native to perl. The perl function unpack() takes a compact binary representation of data and converts it to Perl values based on a user-specified template. Pack() and unpack() are inverse-functions of each other: if used with the same template, unpack can be used to recover data that has been packed. Example: $Tudpheader = ""; # source, destination, length, checksum $Tudppseudoheader = "NNxcn"; # source IP, dest IP, protocol (must be 17), length $udplength = length($data)+8; $udpcheck = (pack $Tpseudoheader, $sip,$dip,17, $udplength) . $(pack $Tudbheader,$sport,$dport,$udplength, 0) . $data; $checksum = udpchecksum($udpcheck); $udppacket = (pack $Tudbheader,$sport,$dport,$udplength,$checksum) . $data " Dave
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
Piers wrote:
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like Cuse base 'Interface' but with
'Interface' consisting of nothing but:
package Interface;
sub virtual_method;
sub virtual_method2 (#prototype);
...
1;
You and I must have been separated at birth, Piers.
Here's what I wrote to Nat just yesterday:
snip
Interfaces might also act like pure abstract base classes when
inherited, so that:
package Dog;
use base 'Fetcher';
would cause a compile-time error if Dog failed to actually provide
a Cfetch method.
I don't like that at all...
Currently, Object implementations can be changed at will at runtime. In
particular, it is possible to create new methods and change the class
hierarchy at run time.
package TextFilter;
use CryptInterface;
@ISA = qw(CryptInterface);
sub AUTOLOAD {
my $self = shift;
($name = $AUTOLOAD) =~ s/.*://;
# Cryptography is very hairy and we don't want to load it if we don't
# have to.
if ($name = any(qw(setkey setcrypt encode decode)) {
require Crypt;
import Crypt;
push @ISA,"Crypt";
$self-$name(@_); # I've not tried this, it may be wrong.
}
}
I'd hate to have that break because TextFilter isn't derived from Crypt
unless it needs to be.
I think calling a method declared in an inherited interface but not
implemented would be a good reason to have a descriptive run-time error, like:
Method getkey in interface Crypt not implemented in TextFilter object at
line
Well, perhaps written better...
If you'd like to run with it, be my guest (but check with Nat first, in
case he wants it).
Damian
Re: RFC 207 (v1) Array: Efficient Array Loops
At 12:00 AM 9/12/00 +1100, Jeremy Howard wrote: [EMAIL PROTECTED] wrote: Reading through the examples left me wondering about some technicalities: @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a Written like this it would require that @a is exact 2-dim, i.e. it would not just swap the first two dims of any n-dim array? I suppose if I'd want that I'd write @t[|i;|j;] = @a[|j;|i;]; # trailing ';' implies there might be trailing dims Not necessary. Since arrays support all the syntax of a plain old list of lists, and the |i syntax just creates an implicit loop, the example quoted from the RFC will work with other sized arrays. In fact, if it was only 2d, it would more properly be: $t[|i;|j] = $a[|j;|i]; # transpose 2-d @a I think it's fair to say that I goofed, and was probably inconsistent with my use of @ and $ in RFC207. It was the hardest (conceptually) of the RFCs I wrote, and it was written late at night -- my thinking probably wasn't as clear as it could have been. I know I delayed in writing it because it posed interesting challenges to syntax and semantics. I think what I was thinking was that |i would act as a list, therefore @t[|i] is syntactically an array slice, and therefore uses @, not $. I'm not so certain that that makes a tremendous amount of sense. The problem is that the isolated expression ~a[|i;|j] (using ~ as a placeholder for $ or @) evaluates to a 2D array, so should use @, but the |i;|j syntax is used to refer to a single element, so it's sort of a scaler, and should use $. While something like "$t[|i;|j] = $a[|j;|i] With three dimensions, each implicit loop in @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a is assigning the _list_ (or 1d array) at @a[|j;|i] to the appropriate index in @t. Ditto for 3 dimensions, except that it is a 1d array (or LOL) that is being assigned at each index through the implicit loop.
Re: RFC 145 (alternate approach)
At 09:05 AM 9/6/00 -0400, David Corbin wrote:
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :
(?['('=')','{'='}','['=']',''='')
Note also the subtle syntax change. We are either dealing with strings
or with patterns. The consensus seems to be against patterns (I can
understand that). Given that, we need to quote the right hand side of
the = operator I think. The quotes on the left side would be optional,
I think.
It would be useful (and increasingly more common) to be able to match
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those
can nest as well. Something like
listmatch this with
list
/list not this but
/list this.
Richard Proctor wrote:
On Tue 05 Sep, Nathan Wiger wrote:
Eric Roode wrote:
Now *that* sounds cool, I like it!
What if the RFC only suggested the addition of two new constructs, (?[)
and (?]), which did nested matches. The rest would be bound by standard
regex constructs and your imagination!
That is, the ?] simply takes whatever the closest ?[ matched and
reverses it, verbatim, including ordering, case, and number of
characters. The only trick would be a way to get what "reverses it"
means correct.
No ?] should match the closest ?[ it should nest the ?[s bound by any
brackets in the regex and act accordingly.
Also this does not work as a definition of simple bracket matching as you
need ( to match ) not ( to match (. A ?[ list should specify for each
element what the matching element is perhaps
(?[( = ),{ = }, 01 = 10)
sort of hashish in style.
Perhaps the brackets could be defined as a hash allowing (?[%Hash)
Richard
--
[EMAIL PROTECTED]
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
I see barewords as being whatever the programmer wants them to be,
as long as he makes it clear what he expects the word to be before using
it.
So, Copen becomes a legacy constructor and the perl6 version of it would
be something like
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
or (using indirect object notation)
my filehandle fh;
open fh ("/tmp/appendablelog");
or even
open my filehandle fh ("/tmp/appendablelog");
with or without fh being syntactically singular, fh will from here to the
end of the enclosing block be seen as a filehandle if that makes sense in
context.
What advantage does this give over:
open my filehandle $fh ("/tmp/appendablelog");
besides the saving on one key stroke?
If it doesn't make sense, meanings from other contexts will be attempted
before
autovivification or error.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
Arrays are ordered.
Hashes are not.
Neither are sets.
Arrays can have repetitions.
Hashes can not.
Neither can sets.
etc.
--tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to write :
%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );
You are right, that is not natural. I don't know why I would ever want to
use a hash keyed using integers instead of arrays. But that's not how I
would use a hash for a set.
but it is natural to write :
@my_fruit_set = ( 'orange', 'lemon' );
I don't want to have to deal with keys of hashes because my set elements
don't care about them !
In a hash implementation, your hash keys -are- your set elements!
my %set;
# add elements to %set
$set{'elem1','elem2'} = 1;
# test for set memebership
print "elem1 in %set\n" if exists $set{'elem1};
# Compute union
$union{keys %set1, keys %set2} = 1;
# Compute intersection
for $elem (keys %set1) { $intersect{$elem} = 1 if exists($set2{$elem});}
# set difference
delete @set1{keys %set2};
How do you currently do these things with arrays?
so, I want new functions to manipulate arrays.
then, when manipulating arrays, without speaking about sets, you often
need in/union/intersection functions, even if arrays have duplicated
elements or if they are ordered.
Well, in fact I don't understand why you don't think that
union/intersection/difference are not usefull functions for arrays ?
Because I don't know what they will do with an array. They are
(reasonably) well defined for sets, but not for arrays.
Gael,
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
Even if they aren't implemented as lol, they may appear as lol to the
programmer
The language-data group is working on multi-dimensional array syntax.
I would like to have (in multidimensional arrays) the various dimensions be
equally easy to access. Using lol syntax imposes a hierarchy on the
dimensions, which makes equal access hard.
For instance, using the syntax I proposed in RFC169, you can take the $ith
row and $jth column of a 2-dimensional array with:
@row = @matrix[$i;..];
@col = @matrix[..;$j];
This can be naturally extended to greater dimensions, if need be.
How does one do this in LOL syntax?
@row = @{$matrix[$i]}; # this is easy!
for my $r (@matrix) {
push @col,$$row[$j];
} # this is easy?
I suppose one could do:
for (my $k = 0;$k @matrix; $k++) {
push @row, $matrix[$i][$k];
push @col, $matrix[$k][$j];
}
but even that obscures what you really want to do.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"My baby done left me,
she done went to the drive-in movies with somebody else."
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
Even if they aren't implemented as lol, they may appear as lol to the
programmer
The language-data group is working on multi-dimensional array syntax.
I would like to have (in multidimensional arrays) the various dimensions be
equally easy to access. Using lol syntax imposes a hierarchy on the
dimensions, which makes equal access hard.
For instance, using the syntax I proposed in RFC169, you can take the $ith
row and $jth column of a 2-dimensional array with:
@row = @matrix[$i;..];
@col = @matrix[..;$j];
This can be naturally extended to greater dimensions, if need be.
How does one do this in LOL syntax?
@row = @{$matrix[$i]}; # this is easy!
for my $r (@matrix) {
push @col,$$row[$j];
} # this is easy?
I suppose one could do:
for (my $k = 0;$k @matrix; $k++) {
push @row, $matrix[$i][$k];
push @col, $matrix[$k][$j];
}
but even that obscures what you really want to do.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"My baby done left me,
she done went to the drive-in movies with somebody else."
Re: Proposed RFC for matrix indexing and slicing
At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:
You should have a look at the PDL RFC 117 before submitting this.
It would be bad to have multiple RFCs suggesting the same thing.
I just read PDL RFC 117, and your current argument with Dan aside...
I don't see a problem.
Here is the core of what I see in my RFC:
1. Use ';' as an index separator for matrices.
2. Use lists as methods of getting slices of matrices
3. Use ^var (or some other syntax) as a way of expressing
relationships/constraints among different indices when writing
matrix slices.
Here is what I see as the core of RFC 117:
1. Use start:stop:step as syntax for complex ranges.
I see them as orthogonal. You could just as easily use RFC 117 syntax to
specify the lists I use to get slices as you could standard perl lists.
Much better to come to some agreement HERE on what the syntax
should be first, then submit consensus RFCs.
My view: I am pretty flexible I like most suggestions as long as
they are concise.
Don't forget we also need to support the equivalent of
$pdl-slice('10:20:2')
@matrix[10:20:2];
that is, assuming my RFC and RFC117 are both accepted. What's the problem?
i.e. use a non-unit stride
Karl
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
$r-{{qw(a b c d e f g h)}}
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
$r-{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
Except in the case where you don't have the list until run-time.
snip
So the syntax would be useful; I'm not sure how useful, such deeply nested
hashes requiring run-time key lookup like that are a rarity. The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
On language-data a counter-proposal to my RFC169 has been made,
suggesting the use of array/list references for multidimensional
indices. In the simplest case, assuming list-of-list implementation,
$a[[1,2,3]] would be the same under both proposals (unless this
proposal would require $a[[(1,2,3)]], which is too much syntax for my
taste). But the list-ref idea would also allow @a[$point1,$point2] as
a slice of two elements of the matrix @a, each point being a reference
to a 4-element list of integers.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: New variable type: matrix
Not being a PDL'er myself, but interested in learning more about it and making sure Perl 6 doesn't suck, I'd love to see a bulleted list of what doesn't work right, even assuming that @arrays were made more flexible. For example, if you could do this: @c = @a * @b; @c = @a + @b; @c = (@a - @b) * (@d / @e); What other specific problems remain? TIA. I'm not a PDL'er myself, either. But I haven't noticed a syntax suggested for multidimensional arrays that looks good to me yet. How are they indexed? $matrix[$x][$y][$z] is (too me) too C'ish, and implies that @matrix is implemented as an array of arrays of arrays, instead of some more efficient, compact structure. $matrix[$x,$y,$z] already has a reasonable meaning. If we appropriate that syntax, how do you take slices of a matrix? I'm thinking I like using ; as an index separator, as in $matrix[$x;$y;$z]. This -shouldn't- be a massive problem for parsing; we are already using ; in "for(;;)" as something other than a statement separator. This would also allow us to do slices like: @matrix[1,3,5;2,4,6;3] to get a 3x3x1 resulting matrix consisting of $matrix[1;2;3],$matrix[1;4;3] , etc. How are literal multidimensional arrays written? For this, I'm not sure... My first thought was to separate the rows with ;, as in @matrix = ( 1,2;3,4). But that doesn't scale well to more than 2d. Then I thought just using the standard list of list syntax: @matrix = ( [1,2],[3,4] ). But is that a list of array references, or a 2-d array? Next, I thought of combining the two: @matrix3x3x3 = ( [[ 1, 2, 3]; [ 4, 5, 6]; [ 7, 8, 9]]; # row 0; [[10,11,12]; [13,14,15]; [16,17,18]]; # row 1; [[19,20,21]; [22,23,24]; [25,26,27]] ); # row 2; I think parenthesis might be better, using [] for reference constructors, but any way you look at it. Should explicit bounds and declarations take place before use? Is "my @matrix:bounds(3,3,3);" necessary? I don't know about you, but autovivication of array elements and boundlessness is a feature I like about perl. Why should "$array[1000] = $x" work without predeclaration but "$matrix[1000;1000;1000] = $x" shouldn't? Just my thoughts? -Nate -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: ME
Buddha Buck wrote:
Perhaps someone should RFC the new special variable ME, which is
predefined to be the whole program. Who knows? Perhaps it would then make
sense to use @_ at the top level, as if the program was invoked as
"ME(@ARGV);"...
on -objects it has been proposed that ME is a call to the current subroutine
or method; that would generalize out to this meaning at the top level only
Hmmm... Could one then go main::ME() then? No, that's not
generalizable...
How about a @CALLER array, with each element being a reference to the
invoking function in the call-back stack. $CALLER[0] would be
equivilant to \ME, $CALLER[1] would be the sub that called ME, etc,
and then $CALLER[-1] would logically be the main program.
Hmm... I don't like @CALLER... Is @ taken? I know $ is...
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
At 07:04 PM 8/17/00 +0200, Johan Vromans wrote:
Nathan Wiger [EMAIL PROTECTED] writes:
Most of the places I've seen them used really well is if
they walk and talk like other forms:
$cgi-param($var, @val); # traditional
$cgi-param($var) = @val; # lvalue, but same thing
I do not think this is critical. When lvalue subs catch on, the
traditional way will soon be extinct.
However, if an lvalue sub is an lvalue, it must be an lvalue in _all_
respects.
$cgi-param($var) = ...
This is a pure lvalue...
$cgi-param($var) += ...
This is not a pure lvalue, but rather both an lvalue and an rvalue,
equivalent to:
$cgi-param($var) = $cgi-param($var) + ...
It should evaluate $cgi-param($var) twice, once as an rvalue, and once as
an lvalue.
$cgi-param($var) =~ s///
This is a tricky one... What should the proper result of:
$cgi-param($var) = "Value constrained to less than 80 characters";
$cgi-param($var) =~ s/./FOO/g;
be? Should it be allowed to change the value of $cgi-param($var) to more
than 80 characters? My though is that it should act like:
{ my $string = $cgi-param($var);
$string =~ s/./FOO/g;
$cgi-param($var) = $string;
}
and $cgi-param() can catch any constraint violations like normal.
for ( $cgi-param($var) ) {
$_ = ...
}
sysread($fh,$cgi-param($var),...)
These I'm uncertain how to deal with...
and so on.
And, what would the lvalue routine return?
I would say, by -convention-, it should return the new rvalue of the lvalue:
{ my $inval = 0;
sub foo : lvalue($val) {
$inval = $val if defined($val) $val 10;
return $inval;
}
}
Currently, $a = $b = $c
implies that both $b and $a get the value $c. But with lvalue subs I
can write something like
yech($foo) = $bar
that assigns $bar to $foo, and returns something else (e.g., the
previous value of $foo).
$a = yech($foo) = $bar
now $a will no longer get $bar assigned.
Do we want that?
Sometimes it would be nice. Why forbid it?
-- Johan
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
At 05:49 AM 8/18/00 +1000, Damian Conway wrote: And I keep pointing out that this is only one aspect of lvalue subroutines. The point of an lvalue subroutine is not to make assignment to the return value work, it is to make the return value an *lvalue*. That's a much more general thing, because it allows every other type of modification to work too. The lvalue accessor *shouldn't* be doing the assignment (what if an assignment isn't what I want?). The (overloaded) operator = should do the assignment. To whatever lvalue the lvalue subroutine returns. Or the "assignment" should be done by operator += or operator++ or whatever mutator I'm actually applying to the returned lvalue. SO what you are saying is that the proper execution of "$p-foo(@args) += $val;" should be (equivalent to): 1. Evaluate $val and get an rvalue $rval. 2. Evaluate $p-foo(@args) and get an lvalue $lfoo. 3. Add $rval to the rvalue associated with $lfoo, to get $rbar. 4. call $lfoo-operator=($rbar) to do the actual assignment. Is that about right? When is your RFC about lvalue subs coming, Damian? Damian
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
At 10:37 AM 8/16/00 -0400, Chaim Frenkel wrote: "BB" == Buddha Buck [EMAIL PROTECTED] writes: BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: Would you be happy with the following edits? BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. time() assumes that the system clock is set to TAI, and does not correct for accumulated leap-seconds. Arithmetic differences between time stamps made using time() may be off by the number of accumulated leap seconds between the two time stamps. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. Exactly. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? Unless you want to have to update perl (or a configuration option) every year, it's probably best to not bother correcting for leap seconds. This is essentially what we do now. The major change here would be a change of epoch (to the TAI epoch) and a documentation of the issues involved. What do we do with stat(), utime(), sleep(), select(), events, etc. stat() returns time stamps (made in the past). utime() sets time stamps. They should be compatible with time(). e.g., "utime time,time,@files" should still set the modify and access times of @files to "now". sleep(), select() both take intervals. The time scale is irrelevant. Will events need time stamps, intervals, or other (please specify)? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. Unfortunately, the valid range of time supported is easily determined, and disturbingly short: Into the future: to next December 31st or June 30th, whichever is closer. Into the past : to past January 1st or July 1st, whichever is closer. Leap-seconds are a PITA for generic time routines. chaim -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
I assume you meant that :lvalue() takes a parameter list. Either a
singleton named variable $, @, or %.
I'm proposing that an lvalue subroutine have access to the rvalue
assigned through a channel other than the standard argument list @_. I
used, as an example, an explicit named parameter to lvalue, but I could
also see a "line-noise" variable used ($= would be perfect, but it's
taken).
I'm proposing that that rvalue be passed by perl as a reference instead
of as a straight $, @, or %.
I'm proposing that subs in lvalue slots that aren't lvalue subs
generate errors.
I think that that is all I'm proposing now...
By having the rvalue passed through a separate channel, the function
does not have to worry about wondering which of @_ (if any) is the
rvalue. This prevents the confusion some are worried about with the
idea that the assigned rvalue is simply tacked onto the end.
Specifically:
$p-name = 'Mithrandir';
would not be directly equivilant to
$p-name('Mithrandir');
as $p-name() would be able to tell in the first case that it is called
in lvalue-context, with 'Mithrandir' as an rvalue to assign. It may be
that $p-name() uses its first argument as a value to assign, but not
necessarily.
Consider, for example, $mytensor-index(2,3,4,5,6). Should that return
the value of cell[2][3][4][5][6], or should it set cell[2][3][4][5] to
6?
Or If it makes sense even a more complex parameter list could be
demanded.
I don't think that's necessary. I like the idea of passing the rvalue
in as a reference because a) references can maintain their own type
information (as per ref()), and b) the rvalue being passed in as
"undef" would unambiguously indicate that it was not lvalue context (a
reference to undef is defined). Besides, I can't imagine the rvalue
being multiple things -- an object, yes. A reference, yes. An array,
yes, a hash even. But not multiple objects, multiple references,
multiple arrays, or multiple hashes.
sub foo :lvalue(Dog $fido, int @array, %hash) {}
foo() = ($name, 0..10, %bar);
chaim
"BB" == Buddha Buck [EMAIL PROTECTED] writes:
BB sub foo : lvalue($newval) {
BB # $newval is a lexical scaler in this block, initialised with a
BB reference
BB # to the value to be assigned to $self{foo}
BB my $self = shift;
BB return $self{foo} unless defined $newval; # rvalue context
BB # lvalue context
BB # verify new foo is in correct range
BB return $self{foo} if $$newval $MINFOO;
BB return $self{foo} if $$newval $MAXFOO;
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 91 (v1) Builtin: partition
Buddha Buck wrote: Or... Let's say you had a 3x3 array implemented as follows: @array = ( a1, a2, a3, b1, b2, b3, c1, c2, c3 ); unzip(3,@array) would return the columns. partition(3,@array) would return the rows. Nice example! I think this better go in the RFC :-) Feel free... I'd recommend using a 2x3 matrix (or a 3x4) for the RFC. I couldn't decide if an NxM matrix would be properly split by unzip(3,@array) or unzip(4,@array), so I cheated and used a square matrix. -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC: Rename local() operator
What about Chide ?
Here's yet another one - how about "here"?
{
here $/ = "\n"; # what it is in here
}
Not really any confusion on this - $/ is "\n" 'in here', but maybe
something else outside.
Unlike "hide" or others, this doesn't connote it's necessarily any
different from somewhere else - just that it's this value inside the
current block (which is what we're after, I think).
But it isn't "here" that's the problem. If we just wanted to change
the value "here", we could use my(). The problem is that local()
changes the value for somewhere else as well as here. Other names
suggested (like "shadow", or "mask") convey that idea better than
"here".
?
-Nate
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: Recording what we decided *not* to do, and why
At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote: BTW, I propose that RFCs have a Status: field as part of the VERSION. Here are some possible values that I can see: Status: accepted # we all agree that it should go in Status: rejected # we all agree that it shouldn't go in Status: tabled # shelved, put away for now Since I have been lead to believe that in standard US practice, "to table" means to stop talking about something for now, and in standard UK practice "to table" means to bring up for discussion, I suggest that the last be "Status: postponed" instead of "Status: tabled". But then, I'm so far behind on my perl6 mail that someone else may have suggested that. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
