Re: Hyper operator corner case?
Thomas Sandla wrote: John Williams wrote: Good point. Another one is: how does the meta_operator determine the identity value for user-defined operators? Does it have to? The definition of the identity value---BTW, I like the term neutral value better because identity also is a relation between two values---is that $x my_infix_op $neutral == $x. One set of cases that doesn't seem to have come up in discussion: (1, 3, 2) - (83, 84, 81, 80, 85) Should this give (-82, -81, -79, -80, -85) as it would by hallucinating 0 (neither a left-identity nor left-neutral element for subtraction strictly, but at least a natural left pivot element), or (-82, -81, -79, 80, 85) as by hallucinating $neutral - $x == $x? This latter $neutral in fact doesn't exist among ordinary numbers, and I would call it algebraically unnatural: for all (other) $n, $n - ($a + $b) == ($n - $a) - $b or, as you increase $a by $b, $n - $a decreases by $b (a sort of contravariance), but $neutral - ($a + $b) == $a + $b == ($neutral - $a) + $b ! This violates algebraic relations I would prefer to rely on, both in my own reasoning and that of the compiler and other program-handling programs. Best regards Roger
Re: Unify cwd() [was: $*CWD instead of chdir() and cwd()]
According to Dave Whipp: It'd also suggest that Copen et al should be methods on a directory object (default object for the global forms would be $*ENV.cwd) There is no system call fd_relative_open. You can only open relative to the current directory, not just any directory.[*] It'd be mean to mislead people into thinking it was always available, but if you put a big this may not work! on it, sure. How do you get the cwd? You call $*ENV.cwd. How to you get its name? You use it in string context. No, that just hides the fact that you're still arbitrarily preferring one method of getting the cwd. [*] Using the fchdir() system call, you can get close, but it takes three system calls instead of one; and if you have no fchdir(), you're out of luck. Oh, and it's not thread-safe. -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] Open Source is not an excuse to write fun code then leave the actual work to others.
S03 Precedence for junctions
Hi all, S03 gives infix + a higher precedence than junctive operators in the listed table, but that seems to contradict the examples under Junctive operators. The relevant parts of S03 are: Junctive operators 1|2|3 + 4; # 5|6|7 1|2 + 34; # (4|5) (5|6) Precedence multiplicative * / % x xx + + + ~ ~ ~ additive+ - ~ +| +^ ~| ~^ junctive and (all) junctive or (any) | ^ (1|2|3) + 4 = 5|6|7 but if + is higher precedence than | 1|2|(3 + 4) = 1|2|7 pugs produces 1|2|7 currently, in keeping with S03 In this case is seems like raising junctive ops higher would be correct, but there more to it? Brad -- After reading books and the like it is best to burn them or throw them away. -- Hagakure http://bereft.net/hagakure/
[PATCH] apo/A06.pod: spelling error(s)
A spelling mistake and a word, that supposedly has been forgotten. Steven --- apo/A06.pod Sun Apr 17 14:34:16 2005 +++ apo/A06.pod Sun Apr 17 14:42:37 2005 @@ -2021,7 +2021,7 @@ All blocks are considered closures in Perl 6, even the blocks that declare modules or classes (presuming you use the block form). -A closure is just an anonymous subroutine that has access its lexical +A closure is just an anonymous subroutine that has access to its lexical context. The fact that some closures are immediately associated with names or have other kinds of parameter declarations does not change the fact that an anonymous bare block without parameters is @@ -3509,7 +3509,7 @@ On the other hand, this means that any unrecognized word followed by a list may unambiguously be taken to be a multimethod being called -as a list operaotr. After all, we don't know when someone will be +as a list operator. After all, we don't know when someone will be adding more multimethods. I currently think this is a feature, but I could be sadly mistaken. It has happened once or twice in the past.
Re: S03 Precedence for junctions
On Sun, Apr 17, 2005 at 08:56:46PM +1000, Brad Bowman wrote: : : Hi all, : : S03 gives infix + a higher precedence than junctive : operators in the listed table, but that seems to contradict : the examples under Junctive operators. The table is correct, and the examples are wrong. : The relevant parts of S03 are: : : Junctive operators : 1|2|3 + 4; # 5|6|7 : 1|2 + 34; # (4|5) (5|6) : : Precedence :multiplicative * / % x xx + + + ~ ~ ~ :additive+ - ~ +| +^ ~| ~^ :junctive and (all) :junctive or (any) | ^ : : : (1|2|3) + 4 = 5|6|7 but if + is higher precedence than | : 1|2|(3 + 4) = 1|2|7 : : pugs produces 1|2|7 currently, in keeping with S03 : : In this case is seems like raising junctive ops higher would : be correct, but there more to it? We spent a goodly long time discussing this very topic in one of our design meetings. The intent of junctions is primarily to produce superposed data values, not to make it possible to write impenetrable code, so the question boils down to whether operators like + are used more often to build the sorts of data values you'd want to |, or whether | is used to build junctions that you'd want to +. We decided that the examples like 1|2|3 + 4; # 5|6|7 1|2 + 34; # (4|5) (5|6) were in fact highly artificial, and people would much more often be using simple operators to compose alternative values: $a + 1 | $a - 1 That was our gut-level feeling. A lot of this design stuff comes down to just that. So we could be completely and utterly wrong about it. Larry
Re: S03 Precedence for junctions
On Sun, Apr 17, 2005 at 07:29:33AM -0700, Larry Wall wrote: On Sun, Apr 17, 2005 at 08:56:46PM +1000, Brad Bowman wrote: : : Hi all, : : S03 gives infix + a higher precedence than junctive : operators in the listed table, but that seems to contradict : the examples under Junctive operators. The table is correct, and the examples are wrong. Examples are now fixed in S03.pod in the svn repository. Pm
Re: [PATCH] apo/A06.pod: spelling error(s)
On Sun, Apr 17, 2005 at 02:52:27PM +0200, Steven Philip Schubiger wrote: A spelling mistake and a word, that supposedly has been forgotten. Steven Applied, thanks! Pm --- apo/A06.pod Sun Apr 17 14:34:16 2005 +++ apo/A06.pod Sun Apr 17 14:42:37 2005 @@ -2021,7 +2021,7 @@ All blocks are considered closures in Perl 6, even the blocks that declare modules or classes (presuming you use the block form). -A closure is just an anonymous subroutine that has access its lexical +A closure is just an anonymous subroutine that has access to its lexical context. The fact that some closures are immediately associated with names or have other kinds of parameter declarations does not change the fact that an anonymous bare block without parameters is @@ -3509,7 +3509,7 @@ On the other hand, this means that any unrecognized word followed by a list may unambiguously be taken to be a multimethod being called -as a list operaotr. After all, we don't know when someone will be +as a list operator. After all, we don't know when someone will be adding more multimethods. I currently think this is a feature, but I could be sadly mistaken. It has happened once or twice in the past.
Hyper-slices?
Quick thought ---
Does the current design of Perl 6's hyper operators allow for
hyper-slices? I.e., if I want to model a matrix by using a list of
lists, is the following code valid/useful?
my @matrix=([1,2,3],[4,5,6],[7,8,9]);
my @row = @matrix[0]; # first row
my @col = @matrix[0]; #first column
my @transposed = @matrix[0..2];
I don't know if this case has been discussed earlier; is extracting an
element considered a unary operation? Is there some use for this
notation, other than what I just said?
I suppose the same could be said for Lists of Hashes:
my @records=({name=Tom,age=27},{name=Dick,age=33});
my @names= @records{'name'};
say @names;
# Tom Dick
Of course, for this to be useful, the lists would have to be
homogenous; @array is List of Hashes (excuse the syntax; I'm still
getting up to speed with a lot of the P6 specific issues).
Again, apologies if this is a closed domain/already has some other
method of retrieving the same information.
Thanks,
David Christensen
Re: identity tests and comparing two references [PATCH for S06 and A06]
On Tue, Apr 12, 2005 at 06:22:13PM +0200, Thomas Sandlaß wrote: I've edited the above syntax into S06 and A06. The two patches are attached but I don't know if you are the right one to sent them to. Whom should I sent such patches? I just saw you applying other patches as well. Applied, many thanks! Best is probably to send patches to perl6-language or perl6-compiler. Pm
Context of hash slices; quotation adverbs
Hi all,
I'm back with more quoting construct madness.
First, context of hash slices:
Hash slices with {} notation are trivially either scalars or lists:
$h{'foo'} = want(); # Scalar
$h{'foo','bar'} = want(); # List
With notation the same thing happens:
$hfoo = want(); # Scalar
$hfoo bar = want(); # List
But when you start interpolating, you get into a big mess:
h\qq[$interpolated] = want(); # ???
h$foo = want(); # ???
Secondly, quotation adverbs (S02) that take arguments could theoretically be
variables that only exist during runtime
q:c(rand) (Do we interpolate {this}?)
(It would be even worse if this had a closing paren in it)
That's complete madness, but with regexps it makes complete sense - sometimes
rx:nth($n)/something/;
The general problem is that some adverbs affect parsing, while others take
place only during runtime - and they all have the same syntax. I'll think a
bit more myself about how to solve this, but I thought I'd throw it out there
as well.
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: [pugs] Quoting constructs
On Saturday 16 April 2005 7:40 pm, Larry Wall wrote: : Basically I'm wondering if there's a detailed : specification of how should work. That's a really good question, and since I don't offhand know the right answer, I'll put this up onto the fence so it can topple over into p6l-land where there are many king's horses and many king's men, and the question is who's to be master, that's all. : 1. qq x$varx eq $var? (That's how it works in Perl5, anyway) I think I'd prefer that we disallow alphanumeric delims in P6. OK, I took the delimiter-finding part out so that it can be replaced by something that only allows certain types of punctuation later. By the way, Juerd, you convinced me. My example was contrieved and there are many other (better) ways to do it. (The fact that Larry Is Always Right helped, of course) : 2. If the delimiter is not a single character (I think this only applies : to ), does a backslash protect the first character or both? I would look at it from the other direction. When used as a quote rather than a meta-syntax starter, backslash only ever quotes a single character, never a token. Done (locally, it will probably be committed later) -- -Roie v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8 [ http://www.hackerkey.com ]
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
--- Larry Wall [EMAIL PROTECTED] wrote: On Fri, Apr 15, 2005 at 11:28:31AM -0500, Rod Adams wrote: : David Wheeler wrote: : : But the first person to write [a...] gets what's comin' to 'em. : : Is that nothing (since '.' lt 'a'), or everything after 'a'? Might as well make it everything after 'a' for consistency. One could also view the last dot as a special version of the ordinary any dot, and read it a to whatever. Larry I think that if we're looking for consistency, the default should be to read it as a and everything after it. If someone wants a to whatever, they should write it [a..\.] since it's a pretty odd fringe case. __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide
Re: should we change [^a-z] to -[a..z] instead of -[a-z]?
--- Larry Wall [EMAIL PROTECTED] wrote: . . . -[a..z] should be allowed/encouraged/required. It greatly improves the readability in my estimation. The only problem with requiring .. is that people *will* write [a-z] out of habit, and we would probably have to outlaw the - form for many years before everyone would get used to the .. form. So maybe we allow - but warn if not backslashed. In general, I think this is a great idea, but what exactly do you mean by warn if not backslashed? That I'd get a warning *any* time I use a dash in a character class? I guess I can live with that. __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide
RE: should we change [^a-z] to -[a..z] instead of -[a-z]?
-Original Message- From: Paul Hodges [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 1:30 PM To: Larry Wall; perl6-language@perl.org Subject: Re: should we change [^a-z] to -[a..z] instead of -[a-z]? --- Larry Wall [EMAIL PROTECTED] wrote: . . . -[a..z] should be allowed/encouraged/required. It greatly improves the readability in my estimation. The only problem with requiring .. is that people *will* write [a-z] out of habit, and we would probably have to outlaw the - form for many years before everyone would get used to the .. form. So maybe we allow - but warn if not backslashed. In general, I think this is a great idea, but what exactly do you mean by warn if not backslashed? That I'd get a warning *any* time I use a dash in a character class? I guess I can live with that. On the other hand, you can use the canonical perl 5 trick of having the dash be the first character in the class if you want to use a literal dash. Joe Gottman.
perl6 taint other traits
Hi, In Perl5 there can be a flag on a variable, that shows, if it's tainted or not. I would like you to ask, if it will be possible the same with Perl 6, or - and I'm most interested in this -, if it's possible to create something like this by me (defining meta information on variables, that not just stored, but has some effect)? And, maybe it's the same question, is it possible to declare traits/properties on a variable, or I just can use the ones that declared by the language (and I've misunderstood the conception)? Bye, Andras
Re: Truely temporary variables
On Fri, 2005-04-15 at 18:04 +0200, Juerd wrote:
Aaron Sherman skribis 2005-04-15 11:45 (-0400):
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
I like the idea and propose a, aliased an for this.
Too short. Having such a short identifier does two things:
* Robs that identifier from any future possible use
* Creates incentive to use this over my
You want there to be a general tendency to use my first. If I were to
choose a word, it would be temp (which I think already exists, though
I forget what it does vs my), or let (to correspond with its use in
rules).
It should probably be illegal to:
throwawaytmpvar $sql = q{...};
my $sql = q{...}; # Error: temporary became normal lexical
or for that matter even give it a new type:
throwawaytmpvar int $i = 0;
throwawaytmpvar str $i = oops; # Error: redefinition of type
Giving it a new type should be valid. That is, I think the variable is
more useful if the old one is thrown away and a new one is created. This
can perhaps be optimized by re-using the same thing if it has no
external references anymore.
The reason I didn't want a new type to be valid was as an extra
precaution against problematic boilerplating. It's a minor thing, and
probably not that big a deal.
Re: Truely temporary variables
Aaron Sherman skribis 2005-04-17 18:23 (-0400):
On Fri, 2005-04-15 at 18:04 +0200, Juerd wrote:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
I like the idea and propose a, aliased an for this.
Too short.
There is a rule of thumb, I don't know who came up with it, that says
that the length of a variable name should be proportional to its scope.
This works well, very well. The same principle can be applied to the
declaring operator, and holds for my/our already.
The usual idiom for these throwaway variables is to use blocks. The
reason to want a different way to write this, I thought was wanting to
type less, especially because it's repeated throughout code.
* Robs that identifier from any future possible use
That's with every identifier, and if the function it provides is good
enough, this cannot be considered a problem, or we can no longer invent
any new keyword that's both short and powerful.
* Creates incentive to use this over my
This is true, and the reason I now prefer a warningless my to a/an. For
this I like Larry's suggestion to use ok, so you get ok my $foo =
...;. Again, a short keyword, but its power warrants it, IMO.
Even if this does mean (and it does) we need something else for unit
tests.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Hyper-slices?
David Christensen writes:
Quick thought ---
Does the current design of Perl 6's hyper operators allow for
hyper-slices? I.e., if I want to model a matrix by using a list of
lists, is the following code valid/useful?
my @matrix=([1,2,3],[4,5,6],[7,8,9]);
my @row = @matrix[0]; # first row
my @col = @matrix[0]; #first column
Almost.
my @col = @matrix.[0]
my @transposed = @matrix[0..2];
The thing that makes me wonder about that is whether it builds anonymous
arrays inside for you, or whether it just flattens everything out.
Obviously in this case it *should* give you arrays.
On the other hand, if you did the standard map transform that hypers do:
my @transposed = map { $_[0..2] } @matrix
Then it's clearly flattening.
What I'm currently thinking is that Perl is terrible for matrix stuff.
Maybe we should keep it that way, and punt to PDL. But as it stands, we
have no hope of appeasing the mathematicians in this area without really
redoing hyper stuff. And I think that the hyper stuff is pretty close
to right for non-matrix purposes, so it would be hard to redo it without
perturbing what we have.
Luke
Re: perl6 taint other traits
BRTHZI Andrs writes:
Hi,
In Perl5 there can be a flag on a variable, that shows, if it's tainted
or not. I would like you to ask, if it will be possible the same with
Perl 6, or - and I'm most interested in this -, if it's possible to
create something like this by me (defining meta information on
variables, that not just stored, but has some effect)?
Indeed it is possible. A property is allowed to (re)define methods
of the object that it is being applied to, and you're allowed to
MMD dispatch on objects with a certain property.
enum tainted untainted;
multi sub infix:+(tainted $a, $b) {
(($a but untainted) + $b) but tainted;
}
# ...
my $x = =$*IN but tainted;
my $y = 10;
my $z = $x + $y; # z is now tainted
Luke
Re: Hyper-slices?
I definitely like the hyper stuff how it is; maybe the answer is to
just define an infix:[[]] operator which returns the crosswise slice
of a nested list of lists. In any case it could be shunted aside to
some package and certainly does not need to be in core.
David
my @transposed = @matrix[0..2];
The thing that makes me wonder about that is whether it builds
anonymous
arrays inside for you, or whether it just flattens everything out.
Obviously in this case it *should* give you arrays.
On the other hand, if you did the standard map transform that hypers
do:
my @transposed = map { $_[0..2] } @matrix
Then it's clearly flattening.
What I'm currently thinking is that Perl is terrible for matrix stuff.
Maybe we should keep it that way, and punt to PDL. But as it stands,
we
have no hope of appeasing the mathematicians in this area without
really
redoing hyper stuff. And I think that the hyper stuff is pretty close
to right for non-matrix purposes, so it would be hard to redo it
without
perturbing what we have.
Luke
Re: Truely temporary variables
At least for the usage described in this thread, I don't see any need
at all to add new syntax to Perl 6. The existing syntax provides for
a much simpler solution yet, which also is in Perl 5.
This is the format of what I do to solve the same problem right now
in my Locale::KeyedText test suite:
my ($sql, $foo, $bar);
$sql = q{...};
...do some db stuff, also using $foo and $bar...
$sql = q{...};
...do some db stuff, also using $foo and $bar...
$sql = q{...};
...do some db stuff, also using $foo and $bar...
In other words, the simple solution is to declare the variable and
use it on SEPARATE LINES! Then you can cut/copy/paste/reorder usage
lines with impunity as you wanted.
Not only does this not require a new dubious language feature, but it
also wins for brevity.
Keep it simple, as it is said.
Reserve any new syntax for when it is genuinely useful.
-- Darren Duncan
Re: Context of hash slices; quotation adverbs
On Sun, Apr 17, 2005 at 07:54:18PM +0300, Roie Marianer wrote:
: Hi all,
: I'm back with more quoting construct madness.
Kewl, d00d.
: First, context of hash slices:
: Hash slices with {} notation are trivially either scalars or lists:
: $h{'foo'} = want(); # Scalar
: $h{'foo','bar'} = want(); # List
Right.
: With notation the same thing happens:
: $hfoo = want(); # Scalar
: $hfoo bar = want(); # List
Right.
: But when you start interpolating, you get into a big mess:
: h\qq[$interpolated] = want(); # ???
: h$foo = want(); # ???
I think that, as with functions called in unknown context, we should
just force the RHS here to list context, and rely on the RHS to add
extra context as necessary if they really mean scalar. If something
really is always producing a scalar value, it doesn't matter if it's
called in list context.
: Secondly, quotation adverbs (S02) that take arguments could theoretically be
: variables that only exist during runtime
: q:c(rand) (Do we interpolate {this}?)
Nope, 'cuz rand never gets up to 1, and int() always truncates. On the
other hand, if you'd said this...
q:c(rand 2) (Do we interpolate {this}?)
then we'd have exactly the problem you're talking about--it'd compile
as an interpolator 50% of the time.
: (It would be even worse if this had a closing paren in it)
It's no worse than picking random source filters:
BEGIN {
if (int rand 2) {
require Cleverness;
}
else {
require Idiocy;
}
}
: That's complete madness, but with regexps it makes complete sense - sometimes
: rx:nth($n)/something/;
Yep.
: The general problem is that some adverbs affect parsing, while others take
: place only during runtime - and they all have the same syntax. I'll think a
: bit more myself about how to solve this, but I thought I'd throw it out there
: as well.
Any bit of expression by default evaluates at ordinary run time, but can
be forced to evaluate earlier by surrounding context. Basically it's
the same difference between the additions in:
push @foo: $a + $b;
use FOO: $a + $b;
Given that eval ... is equivalent to something like
Perl.parse(...).compile.run
and that the pair in question is already partially compiled to some
form, it seems like you just have to throw a .run or a .compile.run
in there somewhere. Or if you really, really want to force later
evaluation than normal evaluation time, a macro could wrap up the
thunk as an implicit closure and pass that to the call, much as ??::
does delayed evaluation of either its ?? or its :: clause. But that's
going to be an unusual case, and we want it to remain an unusual case,
so we're not going to go thunk-mad in a call-by-name fashion.
Then again, you can always change it: All is fair if you predeclare.
Standard Perl exists only between the #! and the first declaration.
Larry
Re: Truely temporary variables
On 4/15/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
Anything wrong with:
my $sql = q{...};
temp $sql = q{...};
temp $sql = q{...};
(Assuming Ctemp is made to work on lexicals, of course.)
How about 'the'? I don't want to Ipossess the variable, I just want to use it.
the $sql = q{...};
the $sth = $dbh.prepare($sql);
It could be the same as my(), but without the posessiveness (warning)
Ashley Winters
Re: Context of hash slices; quotation adverbs
Larry Wall [EMAIL PROTECTED] wrote:
: First, context of hash slices:
: Hash slices with {} notation are trivially either scalars or lists:
: $h{'foo'} = want(); # Scalar
: $h{'foo','bar'} = want(); # List
Right.
Tangentially, that makes me wonder: is there a difference between
scalar context and one-element array context?
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: Context of hash slices; quotation adverbs
On Sun, Apr 17, 2005 at 08:00:00PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: : First, context of hash slices:
: : Hash slices with {} notation are trivially either scalars or lists:
: : $h{'foo'} = want(); # Scalar
: : $h{'foo','bar'} = want(); # List
:
: Right.
:
: Tangentially, that makes me wonder: is there a difference between
: scalar context and one-element array context?
Certainly, same distinction as Perl 5 makes. The only difference
is that Perl 6 can evaluate a list lazily, so it might not actually
have to generate the entire list if you only want the first value.
Larry
