Re: available operator characters
On Sat, 07 May 2005 01:12:02 -0400, Mark A. Biggar <[EMAIL PROTECTED]> wrote:
Actually if we define |...| at all, I'd prefer it mean abs(), its usual
mathmatical meaning.
I agree. I think || is just confusing.
I thought about $blockname <= { ... }, but <= is obviously taken, as is <==
So here's some random ideas that probably make no sense ($ can be
optional.. don't know)
$blockname <=: for 1..5 {
...
}
$blockname :=> for 1..5 {
...
}
for 1..5 {
...
} $blockname;
for 1..5 {
...
} <=: $blockname;
$blockname for 1..5 {
...
} $blockname;
$blockname -- for 1..5 {
...
}
for 1..5 {
...
} -- $blockname;
$blockname @ for 1..5 { # Yeah I know @ is probably impossible
...
} $blockname;
for 1..5 {
...
} @ $blockname;
$blockname â for 1..5 {
...
}
Re: available operator characters
Juerd wrote:
Juerd skribis 2005-05-06 18:24 (+0200):
|AVAILABLE any()
We can use this for labels:
|foo| for ... {
while ... {
...;
next foo if ...;
}
}
It'll confuse the heck out of Ruby coders, but I do like this syntax. It
makes labels stand out, as was one of the requirements, and it puts a
little less strain on the colon.
(Now, if we really want to bug Rubyfolk, we could make labels per block
instead of per statement, and put them inside the curlies:
for ... { |foo|
while ... {
...;
next foo if ...;
}
}
*evil grin*)
Actually if we define |...| at all, I'd prefer it mean abs(), its usual
mathmatical meaning.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Circular dereference?
On May 4, 2005, at 2:38 PM, Thomas Sandlaß wrote: Aaron Sherman wrote: If we agree that the first say should print 7, then we must conclude that either we've changed the value of undef to 7, or we've created a circular reference. In my view of refs 7 is printed, indeed. But I've difficulty to understand what you mean with "the value of undef". Undefinedness to me is the absence of value. In Perl (5 and 6) there is actually a value, 'undef'. That value can be stored in variables, just like any other value. There is no real fundamental difference between '7', 'foo', and 'undef'...they are all values (although each has a slightly different set of meaningful operations). As a community, we have decided that 'undef' means something like "I don't know what this value is" and the perl engine enforces that, but there is nothing implicit about undef that requires it to mean that. I think we agree that references are a level of indirection. We also agree that variables are names that allow us to get at---and here I think our views diverge---a box, cell or container for values. So after resolving a name, we always have one level of indirection from the cell to the value. To me a referencial value is just such a thing without an entry in a namespace or symbol table. Not quite. *values* never have entries in a namespace or symbol table...e.g., there is no symbol table that stores 1,2,3...100, etc. You don't say "$x + number::integer::7" in order to add 7 to $x. A reference is a value, just like an integer or a string. It does not have a symbol table entry. It is, instead, stored in a container. Containers that have names are called "variables", containers that do not have names are (surprisingly enough) "anonymous". So, in Perl 5, "$x = [ 1 ];" creates a reference (a value) to an anonymous array (a nameless container) containing the literal number 1 (a value) and stores it in $x (a named container). So, if you want, you can say that $x is a single level of indirection to get to its value...but, in the example above, its value is [ 1 ], not 1. Therefore, you have another layer of indirection. The name doesn't tell you anything about how many layers of indirection you're going to get. And yes, Juerd and I have fundamentally different opinions of what has got identity. To me only values can be identical. Cells are an implementation vehicle to handle values. It depends on how you define "identity", I suppose. --Dks
Re: available operator characters
Larry Wall skribis 2005-05-06 18:22 (-0700): > (But then you need to put postfix first in the heading.) The heading uses junctions, and junctions are unordered ;) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: available operator characters
On Fri, May 06, 2005 at 06:24:00PM +0200, Juerd wrote:
: {} href|closure hash (deref+)subscript (no ws)
: {}? (clash) AVAILABLE (ws)
s/AVAILABLE/statement block/
Actually, I'd try to find a way to combine all the paired ws-dependent
entries onto the same line, since splitting them to separate lines
induces a fake clash. Maybe
{} href|closure hash (deref+)subscript / statement block
or some such. (But then you need to put postfix first in the heading.)
Larry
Re: available operator characters
On Fri, May 06, 2005 at 10:43:07AM -0600, Luke Palmer wrote:
: > :: namespace ternary
:
: That's "class sigil" in term position. Separating namespaces never
: have preceding whitespace, so they're always part of some larger term.
Really more like a package sigil, which can be used as a module, class,
role, or type sigil.
: > Xactive repeat ???
: > XX active repeat ???
:
: Those two haven't been blessed, and, though I don't have the message,
: I think I remember Larry being a little hesitant about adding those.
The question is whether to treat the left arg the same way we treat
attribute defaults, with one free closure call. We could say that
{ rand 10 } x 100
{ rand 10 } xx 100
should just automatically call the closure on the left repeatedly. In
the rare, rare case that you want to actually replicate a closure, you'd
have to say
{ { rand 10 } } x 100
{ { rand 10 } } xx 100
Then we save two operators. We could also pass the counter in as $_:
{ foo($_) } xx 100; # call foo(0), foo(1)...foo(99)
Which means
@chars = { substr($x, $_, 1) } xx $x.chars;
would be a silly way to write a split ''.
Larry
Re: Fwd: Re: Pugs 6.2.0 released.
"Juerd" <[EMAIL PROTECTED]> wrote: You both use "iff". What does that mean? I believe it's to be read "if and only if". Jonathan
Re: Fwd: Re: Pugs 6.2.0 released.
On Sat, May 07, 2005 at 02:04:45AM +0200, Juerd wrote:
: Juerd skribis 2005-05-07 1:23 (+0200):
: > Perl 5's perlop says: "It cannot short circuit, of course." Can
: > someone explain why it cannot?
:
: I was confused. It is entirely obvious why it can't.
On the other hand, one(...) semantics can short circuit false as
soon as you find two trues, except that one(...) is not guaranteed
to execute in any particular order, whereas I think xor and ^^
should be make list associative but execute left-to-right, short
circuiting on the second true discovered, so you have some hope of
ordering the harder conditions later in a sequence and bypassing them.
In either case the one true value is returned. This seems to me to
be the most useful semantics. Presumably one could also get ordered
tests like this:
$trueone = infix: map { $_ = '' unless /foo/ } =$fh;
and return the one line in $fh that contains "foo", bombing out immediately
if there are two such lines. (I'm assuming infix: can be called
as a list operator there...)
Parity XOR is fine for +^, ~^, and even ?^, of course.
Larry
Re: available operator characters
Juerd skribis 2005-05-06 18:24 (+0200):
> |AVAILABLE any()
We can use this for labels:
|foo| for ... {
while ... {
...;
next foo if ...;
}
}
It'll confuse the heck out of Ruby coders, but I do like this syntax. It
makes labels stand out, as was one of the requirements, and it puts a
little less strain on the colon.
(Now, if we really want to bug Rubyfolk, we could make labels per block
instead of per statement, and put them inside the curlies:
for ... { |foo|
while ... {
...;
next foo if ...;
}
}
*evil grin*)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Fwd: Re: Pugs 6.2.0 released.
Juerd skribis 2005-05-07 1:23 (+0200): > Perl 5's perlop says: "It cannot short circuit, of course." Can > someone explain why it cannot? I was confused. It is entirely obvious why it can't. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Fwd: Re: Pugs 6.2.0 released.
Trewth Seeker wrote: > Mark A. Biggar wrote: > > Trewth Seeker wrote: > > > In this case, we are dealing with '^^', a meaningless > > > unpronounceable symbol. Caret caret. > > > Oh, but wait ... we also spell it 'xor', When reading code, it's probably read as xor, but when discussing syntax itself, I think caret caret is much more appropriate. > > > So what does that say about proposing that xor(p1,p2,...) is true > > > if an odd number of p[i] are true? Not much, I think. Logical xor doesn't make sense with more than two arguments. > > > Clearly, xor is true iff *exactly* one of its arguments is true, Yes, if(f?) exactly one of its TWO arguments is true. You both use "iff". What does that mean? > > > and of course it should return that argument (or bool::false if no > > > argument is true). How 'of course' is that? Lacking specification in Perl 6 documents, Perl 5's behaviour is the rule, and Perl 5 returns true or false, not the argument that was true, or false. I agree that it would be more useful if xor did indeed evaluate to the single true element if there is one (and only one). Perl 5's perlop says: "It cannot short circuit, of course." Can someone explain why it cannot? > > As long as you build "p1 xor p2 xor ..." out of binary xor ops that > > is the result you get. Computing parity is much more common that > > your multi-arg operation. Parity with logic xor? With bitwise xor, sure, agreed, that's the single most useful application of the bitop. But explain to me how you get some useful parity with xor'ed conditions? > Sorry, but you're quite wrong here, because that literature applies to > an associative operator, which Perl's xor is not. ((1 xor 2) xor 3) > == 3, while (1 xor (2 xor 3)) == 1. Pugs agrees. (1 xor 2 xor 3) is also 3. > and it ignores the context of the discussion in which it has been > noted that the value of "p1 xor p2" is either p1 or p2 or > bool::false, but not "true". Is this official yet? > My position is that it should either have its linguistic meaning, or > expressions of the form "p1 xor p2 xor p3" should be disallowed, since > there is no other natural meaning for it. bool::true is not an > acceptable result (unless one of p1, p2, or p3 is bool::true), and > simply picking one or the other of p1, p2, and p3 when they are all > true is arbitrary. All of which was obvious if you were to follow my > advice about problem solving. Anyone using chained logic xor booleanly expecting it to get true only if exactly one of the values is true, deserves punishment because they should be using a one() junction instead. Which, not entirely coincidentally, is available as &infix:<^> too, which looks suspicously like &infix:<^^>, don't you think? Anyone using chained logic xor for parity, ... hm, should explain to me how they use parity as a condition, because I don't quite yet grok the usefulness of this. Anyone using chained logic xor in another way should be punished for not using parens in a complex expression. (With and/or it's a minor offense, because they're much more common.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Fwd: Re: Pugs 6.2.0 released.
Here's the same message, with less annoying word wrapping. (Especially useful for mailers that show different levels of quotes in different colours.) Trewth Seeker wrote: > Mark A. Biggar wrote: > > Trewth Seeker wrote: > > > I see here another case of a common erroneous approach to > > > problem-solving. People are trying to enumerate definitions to > > > impose on something, rather than starting with the thing at hand > > > and exhausting any clues it may provide before moving on. This > > > can lead to serious and, in hindsight, embarrassing mistakes. > > > > > > In this case, we are dealing with '^^', a meaningless > > > unpronounceable symbol. Oh, but wait ... we also spell it 'xor', > > > which I supppose is often pronounced "ex or", which might be the > > > source of the difficulty. Because 'xor' stands for ... ... > > > 'exclusive or'. Exclusive? It's not hard to figure out what that > > > means. Here are some of the relevant dictionary definitions: > > > > > > Not allowing something else; incompatible: mutually exclusive > > > conditions Not accompanied by others; single or sole > > > > > > So what does that say about proposing that xor(p1,p2,...) is true > > > if an odd number of p[i] are true? Other than that people should > > > pronounce these operators out loud more often? > > > > > > Clearly, xor is true iff *exactly* one of its arguments is true, > > > and of course it should return that argument (or bool::false if no > > > argument is true). > > > > > > That should now be so blatantly obvious that everyone should be > > > embarrassed for not having seen it immediately. But don't run > > > from embarrassment (or become defensive and attack the messenger) > > > -- it's a powerful tool (which is why we evolved to have it). It > > > should cause one to question one's thought processes and consider > > > how to improve upon them, which is all to the good, isn't it? > > > > Except that xor or ^^ is only a binary operation, there is no > > "xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only be > > understood if you add () to disambiguate the order that the binary > > ops are performed. Fortunately, xor is associative so it doesn't > > matter how you add the (), you get the same answer. Try it out, you > > will discover that "p1 xor p2 xor ..." is true iff an odd number of > > the p's are true. > > > > As long as you build "p1 xor p2 xor ..." out of binary xor ops that > > is the result you get. Computing parity is much more common that > > your multi-arg operation. Besides, all the literature about logic > > and circuit design define "p1 xor p2 xor ..." in terms of binary > > xor, so your trying to buck hundreds of years of consensus. > > Sorry, but you're quite wrong here, because that literature applies to > an associative operator, which Perl's xor is not. ((1 xor 2) xor 3) > == 3, while (1 xor (2 xor 3)) == 1. I again ask that you pay more > attention to the thing you're dicussing, rather than to simply > generate stuff out of your own head, so as to avoid trivial > embarrassing error. You wrote q(Try it out, you will discover that > "p1 xor p2 xor ..." is true iff an odd number of the p's are true) > > --- > > this fails on two counts; 1) it begs the question, which was how "p1 > xor p2 xor p3" should be evaluated -- it can only be "tried out" if > that answer has already been decided upon; and it ignores the context > of the discussion in which it has been noted that the value of "p1 xor > p2" is either p1 or p2 or bool::false, but not "true". > > The literature on logic design treats n-ary exclusive xor as modular > arithmetic, which is natural to do since it is an associative > operator. But it provides no guidance as to the value of "1 xor 2 xor > 3", nor do your remarks, starting out with your claim that there is no > "xor(p1,p2,...)". The language is being defined, so such claims are > meaningless; there is no reason why xor cannot be an n-ary function. > My position is that it should either have its linguistic meaning, or > expressions of the form "p1 xor p2 xor p3" should be disallowed, since > there is no other natural meaning for it. bool::true is not an > acceptable result (unless one of p1, p2, or p3 is bool::true), and > simply picking one or the other of p1, p2, and p3 when they are all > true is arbitrary. All of which was obvious if you were to follow my > advice about problem solving. (signatures removed)
Fwd: Re: Pugs 6.2.0 released.
Oops, this should have been redirected to perl6-language@perl.org, so I'm doing that now. --- Trewth Seeker <[EMAIL PROTECTED]> wrote: > Date: Fri, 6 May 2005 13:15:37 -0700 (PDT) > From: Trewth Seeker <[EMAIL PROTECTED]> > Subject: Re: Pugs 6.2.0 released. > To: "Mark A. Biggar" <[EMAIL PROTECTED]> > CC: perl6-compiler@perl.org > > > --- "Mark A. Biggar" <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > > > I see here another case of a common erroneous approach to > > > problem-solving. People are trying to enumerate definitions > to > > impose > > > on something, rather than starting with the thing at hand and > > > exhausting any clues it may provide before moving on. This can > > lead to > > > serious and, in hindsight, embarrassing mistakes. > > > > > > In this case, we are dealing with '^^', a meaningless > > unpronounceable > > > symbol. Oh, but wait ... we also spell it 'xor', which I > suppose > > is > > > often pronounced "ex or", which might be the source of the > > difficulty. > > > Because 'xor' stands for ... ... 'exclusive or'. Exclusive? > > It's not > > > hard to figure out what that means. Here are some of the > > relevant > > > dictionary definitions: > > > > > > Not allowing something else; incompatible: mutually > exclusive > > > conditions > > > Not accompanied by others; single or sole > > > > > > So what does that say about proposing that xor(p1,p2,...) is > true > > if an > > > odd number of p[i] are true? Other than that people should > > pronounce > > > these operators out loud more often? > > > > > > Clearly, xor is true iff *exactly* one of its arguments is > true, > > and of > > > course it should return that argument (or bool::false if no > > argument is > > > true). > > > > > > That should now be so blatantly obvious that everyone should be > > > embarrassed for not having seen it immediately. But don't run > > from > > > embarrassment (or become defensive and attack the messenger) -- > > it's a > > > powerful tool (which is why we evolved to have it). It should > > cause > > > one to question one's thought processes and consider how to > > improve > > > upon them, which is all to the good, isn't it? > > > > Except that xor or ^^ is only a binary operation, there is no > > "xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only > be > > > > understood if you add () to disambiguate the order that the > binary > > ops > > are performed. Fortunately, xor is associative so it doesn't > > matter how > > you add the (), you get the same answer. Try it out, you will > > discover > > that "p1 xor p2 xor ..." is true iff an odd number of the p's are > > true. > > As long as you build "p1 xor p2 xor ..." out of binary xor ops > > that is > > the result you get. Computing parity is much more common that > your > > > > multi-arg operation. Besides, all the literature about logic and > > > circuit design define "p1 xor p2 xor ..." in terms of binary xor, > > so > > your trying to buck hundreds of years of consensus. > > Sorry, but you're quite wrong here, because that literature applies > to an associative operator, which Perl's xor is not. ((1 xor 2) > xor > 3) == 3, while (1 xor (2 xor 3)) == 1. I again ask that you pay > more > attention to the thing you're dicussing, rather than to simply > generate stuff out of your own head, so as to avoid trivial > embarrassing error. You wrote q(Try it out, you will discover that > "p1 xor p2 xor ..." is true iff an odd number of the p's are true) > -- > this fails on two counts; 1) it begs the question, which was how > "p1 > xor p2 xor p3" should be evaluated -- it can only be "tried out" if > that answer has already been decided upon; and it ignores the > context of the discussion in which it has been noted that the value > of "p1 xor p2" is either p1 or p2 or bool::false, but not "true". > > The literature on logic design treats n-ary exclusive xor as > modular > arithmetic, which is natural to do since it is an associative > operator. But it provides no guidance as to the value of "1 xor 2 > xor 3", nor do your remarks, starting out with your claim that > there > is no "xor(p1,p2,...)". The language is being defined, so such > claims are meaningless; there is no reason why xor cannot be an > n-ary > function. My position is that it should either have its linguistic > meaning, or expressions of the form "p1 xor p2 xor p3" should be > disallowed, since there is no other natural meaning for it. > bool::true is not an acceptable result (unless one of p1, p2, or p3 > is bool::true), and simply picking one or the other of p1, p2, and > p3 > when they are all true is arbitrary. All of which was obvious if > you > were to follow my advice about problem solving. > > -- ts > > > > Yahoo! Mail > Stay connected, organized, and protected. Take the tour: > http://tour.mail.yahoo.com/mailtour.html > > __ Yahoo
Re: stdio
On Fri, May 06, 2005 at 08:19:05AM -0400, Aaron Sherman wrote:
: "open" as a verb is extremely ambiguous. In dictionary searches I see as
: many as 19 definitions just for the verb form.
Well, sure, but also need to take Perl history into account, where dwimmy
open is considered something of a liability.
I think the dwimminess of open() probably arises only from MMD, and
a string or array of string in the first argument implies ordinary
file open. That means perhaps we have
open uri($x)
to type $x to a \w+: handled string, so MMD can see it. When means
you can pass a uri object to a generic open just fine, as long as your
program generates the type. But random strings wouldn't accidentally
trigger uri processing. Alternately,
open URI: $x
will single dispatch to the URI class.
: "open" as a POSIX function is not ambiguous at all. But will the POSIX
: model be the model on which P6 is based (as P5 was), or will the POSIX
: model simply be one of many models supported by open and other
: built-ins?
One of many.
: I think that it's fair to say that Perl has grown beyond POSIX. If it
: also presents the URI model, that's not all bad, is it?
As long as it's not the accidental default.
: Same goes for the Unix command-line conventions (e.g. cat's "-" special
: filename). I should be able to request a "pure POSIX" open, but I'm not
: sure it should be the default for one of English's most powerfully
: flexible verbs.
io() is probably the place for complete dwimmery.
: > and perhaps even
: >
: > File::Copy::copy("-","-");
:
: This brings up something interesting. If we have:
:
: sub File::Copy::copy(IO $file1, IO $file2) {...}
:
: the above doesn't work.
:
: I think I want:
:
: sub File::Copy::copy(IO $file1 :r, IO $file2 :w) {...}
:
: But does that work the way I think it does? Does that end up calling:
:
: IO.new("-", :r);
:
: and
:
: IO.new("-", :w);
:
: ? If not, how do I ensure that this works correctly?
Those are all pretty bletcherous. How 'bout
io('-') ==> io('-');
: > Sure enough, there's an easy way:
: >
: > class IO is ParrotIO does RegisteredStringConstructor {...}
: > role RegisteredStringConstructor {
: > has %:registry;
: > sub register(Any $pattern, Type $type) {
: > %:registry{$pattern} = $type;
: > }
: > multi method new(Str $string,*%rest) {
: > for %:registry.keys -> $pat {
: > if $string ~~ $pat {
: > return
%:registry{$pat}.bless(:string($string),*%rest);
: > }
: > }
:
: I would need some error handling here, and possibly would need to defer
: to a parent as a fallback.
:
: That brings up the idea of delegation... should this be handled by
: delegation instead of the way I've done it? Not sure. I'm still trying
: to figure out how to make this scope correctly so that:
:
: use IO;
: {
: use IO::URI :open;
: open("http://www.perl.org/",:r);
: }
: open("http://www.perl.org",:r);
:
: opens two very different things: a socket to a host and port as directed
: by a URI vs a file named "www.perl.org" in a directory called "http:".
my &open ::= &open:(URI);
or maybe some kind of currying. Multiple handlers would need some way
of ordering them though. Seems like I put something into the delegation
model to deal with that already, like
has @:iolist handles ;
: > Optional export features of IO::* could allow:
: >
: > * pipeline command execution
: > * thread and/or process coupling
: > * handle duping
: > * much more
: >
: > Thus, you would control these features like so:
: >
: > use IO;
: > use IO::Funky :register_string_open_funkiness;
: > open("funk",:w);
:
: Which is probably just the tip of the iceberg. You might, for example,
: want to lay out a user-defined filesystem, or open database tables as
: files, etc.
I think lumping everything under the IO rubric is perhaps a mistake, unless
we also give shortcuts for all the common cases, in which case maybe we
should go for a flatter hierarchy to begin with, and leave the deep names
for CPAN modules.
: Of course, you can do all of this explicitly through OO syntax, but it
: would be nice to uniformly export locator semantics as strings so that
: command-line and other string-based user interaction could be made more
: powerful with a single "use".
Just so easy things stay easy. Foo::Bar::Baz::meth names are not
construed by everyone as easy to use.
Larry
Re: bitter complaints
On Fri, May 06, 2005 at 06:46:58PM +0200, Juerd wrote:
: According to S03, the yada operator "complains bitterly" when used. In
: #perl6, we can't agree on what that means. Please help. Does it die,
: warn or fail?
:
: 18:46 < Corion> Juerd: "Complain bitterly" is "output a warning" to me.
: 18:46 < Juerd> It's "die" to me
: 18:46 < Odin-> Juerd: Hmm. I'd read it as "print a huge, ten page banner
: alerting to an error, and then go on"...
:
: And we want ??? and !!! to be aliases for ... if it dies, or to dieing
: yadas if ... itself merely warns:
:
: 18:46 < Corion> Juerd: But "..." is more like "uh - I hope you know what
: you're doing", where "???" is more like "WTF?", and "!!!" is more like "WTF!"
: 18:47 < Corion> Juerd: I see "..." as having practical use when stubbing
: out code - I would want the code to warn but continue. How else would
: you do that?
: 18:47 < Corion> sub do_magic { ... }
: 18:47 < Corion> looks good, and should warn "do_magic is not yet
: implemented at $?LINE"
: 18:48 < Corion> while
: 18:48 < Corion> sub magic { ??? }
: 18:48 < Corion> should die.
:
: Though we'd have to discuss the precise meanings of "WTF?" and "WTF!".
I think I'd like to see:
... fail "$?BLOCKNAME is not yet implemented"
??? warn "$?BLOCKNAME is not yet implemented"
!!! die "$?BLOCKNAME is not yet implemented"
In other words, it's okay to call an undefined function in your
prototype as long as you don't actually use the value. And then you
can force ... to !!! with use fatal.
Larry
Re: receivers of pipes (the sharp end again)
Larry Wall skribis 2005-05-06 11:07 (-0700):
> But then how do you know if you just want to pass one as a scalar and
> not iterate it?
Assuming =:
=iterator # the iterator itself, passable (autoreffing)
$=iterator # get one element
@=iterator # get remaining elements, lazily
This would mean we'd get
for @=$fh -> $line { ... }
or
=it := =$fh; # =it := $fh.it # =it = $fh.it # I dunno.
for @=it -> $line { ... }
Ugly.
Another alternative would be
$fh.it # the iterator itself, passable
=$fh # synonym for $fh.it.next, where a real iterator has .it
# returning $self, so that =$iterator and =$handle both
# work, without special magic.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: available operator characters
On Fri, May 06, 2005 at 11:25:31AM -0700, Larry Wall wrote: : Any Object does Hash, and treats any argumentless method as a potential : hash key. I should also point out that the main reason for this is to allow easier translation of Perl 5 idioms to Perl 6 without having to guess whether $foo contains an unblessed hash ref or a real Perl 6 object. We're not actually recommending peole use hash notation to call attribute methods. Larry
Re: available operator characters
On Fri, May 06, 2005 at 06:49:44PM +0200, Juerd wrote: : Luke Palmer skribis 2005-05-06 10:43 (-0600): : > Why the %!@ would you ignore that!? :-) : : I hate my brain. Now I wonder if Bool.does(Hash). Does it? :) Any Object does Hash, and treats any argumentless method as a potential hash key. So Bool is likely to recognize $boolean and return 0 or 1, possibly disguised as Bool::true or Bool::false. On the other hand, a low-level bool type might not choose to box itself to Bool just so you can treat it as a hash and get the low level value back out. Then again, it might. :-) Larry
Re: reduced precedence
Luke Palmer skribis 2005-05-06 12:04 (-0600): > : I propose that reduce become a metaoperator that can be applied to > : any binary operator and turns it syntactically into a list operator. Thanks for the quick reply. 20:14 < pmichaud> oh yes, Luke has the relevant quote 20:15 < pmichaud> listop, definitely. 20:15 < autrijus> it's done :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: reduced precedence
On Fri, May 06, 2005 at 12:04:16PM -0600, Luke Palmer wrote: > On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote: > > In #perl6, we can't decide what it should be. There are good arguments > > for listop precedence ([+] 1..9) and for unary precedence ([EMAIL > > PROTECTED] < > > $bar). My preference is listop precedence. > > Good, because that's Larry's preference, too: > > : I propose that reduce become a metaoperator that can be applied to > : any binary operator and turns it syntactically into a list operator. Okay, [+] is now a listOp in Pugs, between Y and ==>, until further notice. :-) Thanks, /Autrijus/ pgpDuzqPESK19.pgp Description: PGP signature
Re: available operator characters
On Fri, May 06, 2005 at 01:31:43PM -0400, Rob Kinyon wrote: : > I'm sticking to non-words here, as I mentally parse not and true as : > single-arg subs, single-arg subs as unary operators, etcetera. I can't : > help it, but I have absolutely no idea how to determine the difference. : > Is it &prefix: or just ¬? I have no idea. I do know that it's : > &infix:, not &x. : : Though, P6 mayl give us the ability to create circumfix operators (as : seen in the entire reduce thread). I think that syntax will also allow : for functions to be parsed as infix operators, right? Sure, but in that case we usually call them methods. :-) Larry
Re: receivers of pipes (the sharp end again)
> Or perhaps we should by default restrict short ones to simple > operators, since it's pretty obvious that [+] is doing *some* kind > of addition, while [EMAIL PROTECTED]&$*#«=] is not quite so obvious. In other > words, we apply some kind of Huffman amplification to the metaoperator, > where the rich stay rich, but the poor get poorer. Or something > like that. I always admired the Great Dalmutti as a game that has > the gall (or sense of reality) to prejudice itself in favor of the > overdogs rather than the underdogs. If we we were more democratic, > we'd require "reduce" on the short ones instead of the long ones. :-) I like this idea. It provides more huffman-coding for readability. Rob
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 07:54:09PM +0200, Juerd wrote: : Larry Wall skribis 2005-05-06 10:37 (-0700): : > Alternately, we could make =$foo an lvalue, but ==> =$foo is a bit strange, : > and people will think it means to write to filehandle $foo. Or we could : > force people to say something evil like ==> my $foo is Iterator. : : I would personally not mind having an extra primary sigil for iterators. : They're different enough, and used enough. But then how do you know if you just want to pass one as a scalar and not iterate it? Larry
Re: Perl6 and support for Refactoring IDE's
Matisse, Just one note before we take this off-list: Maybe this isn't the right place to keep discussing this, so I'll take pointers to other places. I'm very worried about the continued viability of Perl for major projects and am trying connect with other people and see what can be done about it. I share some of your fears, and would be very much interested in talking about them with you (and others). Actually I gave a small lightening speech on this topic at last year's Perl gathering at Budapest, which I will hopefully make into an article some day... IMHO Perl needs some more marketing :) - Fagzal
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 01:51:58PM -0400, Rob Kinyon wrote: : I understand that the reduce [] operator will have its standard forms : ([+], [<], etc) which will be immediately recognizable just like all : the other 3-char operators (==>, etc) will be. I'm just concerned : about the extended form and readability. It's possible that we can allow both the reduce[*] and [*] forms, and let local policy dictate matters cobolish vs mathish. As a general rule we've trying to eliminate synonyms in Perl 6, but this might be a good place for one. Or perhaps we should by default restrict short ones to simple operators, since it's pretty obvious that [+] is doing *some* kind of addition, while [EMAIL PROTECTED]&$*#«=] is not quite so obvious. In other words, we apply some kind of Huffman amplification to the metaoperator, where the rich stay rich, but the poor get poorer. Or something like that. I always admired the Great Dalmutti as a game that has the gall (or sense of reality) to prejudice itself in favor of the overdogs rather than the underdogs. If we we were more democratic, we'd require "reduce" on the short ones instead of the long ones. :-) Larry
Re: reduced precedence
On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote: > What is the precedence of a reduction operator? > > Pugs currently implements it at the symbolic unary level, like the > filetest operators. But that's just one of many guesses. > > In #perl6, we can't decide what it should be. There are good arguments > for listop precedence ([+] 1..9) and for unary precedence ([EMAIL PROTECTED] < > $bar). My preference is listop precedence. Good, because that's Larry's preference, too: : I propose that reduce become a metaoperator that can be applied to : any binary operator and turns it syntactically into a list operator. Luke
reduced precedence
What is the precedence of a reduction operator? Pugs currently implements it at the symbolic unary level, like the filetest operators. But that's just one of many guesses. In #perl6, we can't decide what it should be. There are good arguments for listop precedence ([+] 1..9) and for unary precedence ([EMAIL PROTECTED] < $bar). My preference is listop precedence. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: receivers of pipes (the sharp end again)
Larry Wall skribis 2005-05-06 10:37 (-0700): > Alternately, we could make =$foo an lvalue, but ==> =$foo is a bit strange, > and people will think it means to write to filehandle $foo. Or we could > force people to say something evil like ==> my $foo is Iterator. I would personally not mind having an extra primary sigil for iterators. They're different enough, and used enough. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl6 and support for Refactoring IDE's
On Fri, May 06, 2005 at 10:26:26AM -0600, Luke Palmer wrote: : In other words, Perl 6 is open to the possibility of such an IDE, and : is going to provide the machinery necessary to build a really good : one, but I doubt it will become a development milestone. I think that, just as Perl 1 built in all the system interfaces, and Perl 5 allowed interfaces to every database under the sun, we should just make sure that Perl 6 can interface easily to every existing and future IDE, including any that might be written particular with Parrot in mind. Larry
Re: receivers of pipes (the sharp end again)
On 5/6/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, May 06, 2005 at 01:26:10PM -0400, Rob Kinyon wrote:
> : > : Does this mean that @{foo()} can be written as @ foo()?
> : >
> : > I would prefer not. Use foo()[] instead.
> :
> : Does this mean that some constructs in Perl are parsed immediately
> : (such as foo() ...) and some are deferred (such as the [ in [>>+^<<]
> : ...)? I would think this potentially makes a difference in how P6 code
> : is read ...
>
> I don't believe that [>>+^<<] does deferred parsing. Reduction
> operators are not a fancy form of eval. Like symbolic refs, they're
> a factoring out of something that would otherwise have to be done
> by eval. Basically, they're emulating what
>
> @x.join(" $op ").eval
>
> *would* do, which is why [<] and [|] can work. But that's because the
> list-associative operators actually have some kind of listy interface
> for the general reduction code to call, or else they have special
> code to bypass the left-associativity of the naïve solution.
I apologize - I didn't make myself clear. I meant as a human reader,
not as the compiler. The reader would have to defer parsing of the [
until they see the whole expression for [>>+^<<], but would have to
parse foo() immediately to provide the context for the [ seen right
after. (This kinda relates to the thread I created yesterday re:
operatizing.)
I understand that the reduce [] operator will have its standard forms
([+], [<], etc) which will be immediately recognizable just like all
the other 3-char operators (==>, etc) will be. I'm just concerned
about the extended form and readability.
Rob
Re: Perl6 and support for Refactoring IDE's
Thanks for your comments - I was afraid I'd get flamed for suggesting something wasn't perfect about Perl :-) On May 6, 2005, at 9:31 AM, Fagyal Csongor wrote: IMHO subversioning does not have too much to do with the language itself. Subversioning operates on files. An IDE might integrate some interface for this task, but that is a different question. You are right - it's not a language issue, sorry I left that in. Have you considered using the "DONATE" button on http://e-p-i-c.sourceforge.net/ ? :))) Yes :-) I've donated :-) I contributed some changes to Devel::Refactor (added rename_subroutine and a test suite) and now I have loaded the Java source for the EPIC editor into Eclipse and started looking at how to add support for 'rename_subroutine' - but my Java skills are less than minimal :-) In another post, On May 6, 2005, at 9:26 AM, Luke Palmer wrote: I think you're absolutely right. Perl should have an IDE with Eclipse-like context-sensitivity and refactoring support. However, it's hardly in Perl's philosophy or interest to bless one. and I agree that Perl should not bless any one IDE, and I am *very* happy to read that Perl6 will make it much easier for good tools to be created for Perl, as Luke Palmer said: One thing is for sure. Perl 6 is providing enough introspection and parsing capabilities to make it possible to write a context-sensitive IDE, unlike Perl 5 (well, Perl 5 made it *possible*, I suppose, but Perl 6 will make it obvious). Perl 6 is exposing its whole grammar at the language level, so you can say "give me a syntax tree for this chunk of code" and it will. Even if there are modules that change the syntax with macros (though your editor might have trouble understanding what the macros mean). So, perhaps that leave me (us) in the following situation: 1) Do what I can do help Perl6 happen faster (not much I can do, the current types of programming required is beyond my skills) Maybe I can help evangelize Perl6. 2) Try and improve the tools that do exist for Perl5 - I am doing this with Devel::Refactor and EPIC, but I don't know if I'll learn enough Java to make a difference in EPIC any time soon. 3) Try and keep Perl alive in other ways so it's still around when Perl6 arrives. Yesterday I was at an engineering Open House at Google, and I asked one of the engineers "What can Perl do for Google?", and he basically said (I'm paraphrasing) "Not much, we are a Java and Python shop. Getting a real refactoring IDE for Perl 5 is more compelling a story then a virtual machine (Parrot) that will run multiple dynamically-typed languages." (they already have Jython) Now that was just one person's statement, but this fellow (John Brewer, www.jera.com) is not a Perl hater - he uses Perl, and he's bright, level headed and was not trying to be hostile. In fact he said these things to me and to Larry Wall who was listening very politely :-) Maybe this isn't the right place to keep discussing this, so I'll take pointers to other places. I'm very worried about the continued viability of Perl for major projects and am trying connect with other people and see what can be done about it. --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 01:26:10PM -0400, Rob Kinyon wrote:
: > : Does this mean that @{foo()} can be written as @ foo()?
: >
: > I would prefer not. Use foo()[] instead.
:
: Does this mean that some constructs in Perl are parsed immediately
: (such as foo() ...) and some are deferred (such as the [ in [>>+^<<]
: ...)? I would think this potentially makes a difference in how P6 code
: is read ...
I don't believe that [>>+^<<] does deferred parsing. Reduction
operators are not a fancy form of eval. Like symbolic refs, they're
a factoring out of something that would otherwise have to be done
by eval. Basically, they're emulating what
@x.join(" $op ").eval
*would* do, which is why [<] and [|] can work. But that's because the
list-associative operators actually have some kind of listy interface
for the general reduction code to call, or else they have special
code to bypass the left-associativity of the naïve solution.
Larry
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 10:45:57AM -0600, Luke Palmer wrote: : On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote: : > When piping to a scalar, I assume its reftype will determine what will : > happen. But what if the scalar is undef? Is it then assumed to want to : > behave like an array? : : If you're piping into a scalar without parens, I think it should : always become an array ref. I think it would be more general to return an iterator or some kind of "promise", insofar as it doesn't commit to storing the values, but merely to returning them in the order produced. You can always use $foo[] for the other meaning. Alternately, we could make =$foo an lvalue, but ==> =$foo is a bit strange, and people will think it means to write to filehandle $foo. Or we could force people to say something evil like ==> my $foo is Iterator. I guess the real question is whether ==> my $x is really assigning a list or binding an iterator to a Lazy slot somewhere. It feels like the latter is more useful. Which means that ==> @x can return as soon as it binds the iterator to @x.specs. It doesn't have to wait for all the values to be produced, which an assignment implies (kinda sorta). Which, if we continue with () as an explicit pipe target, ==> @x = () would force assignment semantics. Alternately we could assume assignment and force binding with ==> @x := (). Just depends on how lazy we want to be by default, I guess. I don't have a good feeling for how to answer that. I guess you want to be as lazy as possible without getting into trouble. Larry
Re: available operator characters
> I'm sticking to non-words here, as I mentally parse not and true as > single-arg subs, single-arg subs as unary operators, etcetera. I can't > help it, but I have absolutely no idea how to determine the difference. > Is it &prefix: or just ¬? I have no idea. I do know that it's > &infix:, not &x. Though, P6 mayl give us the ability to create circumfix operators (as seen in the entire reduce thread). I think that syntax will also allow for functions to be parsed as infix operators, right? Rob
Re: receivers of pipes (the sharp end again)
> : Does this mean that @{foo()} can be written as @ foo()?
>
> I would prefer not. Use foo()[] instead.
Does this mean that some constructs in Perl are parsed immediately
(such as foo() ...) and some are deferred (such as the [ in [>>+^<<]
...)? I would think this potentially makes a difference in how P6 code
is read ...
Rob
Re: receivers of pipes (the sharp end again)
Larry Wall skribis 2005-05-06 10:19 (-0700):
> If someone wants to use an array, I don't see why they wouldn't just use @.
Because it's an argument of a very generic function, and it could just
as well be a subref or hashref.
sub mypipe($receiver, [EMAIL PROTECTED]) { @list ==> $receiver }
> my %result <== [;] @pairgenerators;
> my %result{()} = 1 <== [;] @keygenerators;
> Interestingly, reduction with [;] works at the top level and can't
> be confused with statement-final semicolon.
Nice.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: available operator characters
Patrick R. Michaud skribis 2005-05-06 12:20 (-0500): > Ummm, what about C and C ? I'm sticking to non-words here, as I mentally parse not and true as single-arg subs, single-arg subs as unary operators, etcetera. I can't help it, but I have absolutely no idea how to determine the difference. Is it &prefix: or just ¬? I have no idea. I do know that it's &infix:, not &x. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 06:55:47PM +0200, Juerd wrote:
: Luke Palmer skribis 2005-05-06 10:45 (-0600):
: > > How do you pipe to an array returned by a sub? ==> @ foo()?
: > Well, you'd have to be piping into a returned array ref, because you
: > can't pipe into the list the sub returns. So I think it's ==>
: > @{foo()}
: > > Off topic, but I just thought of this again: is whitespace allowed or
: > > disallowed between sigil and name?
: > Disallowed.
:
: Does this mean that @{foo()} can be written as @ foo()?
I would prefer not. Use foo()[] instead.
Larry
Re: receivers of pipes (the sharp end again)
On Fri, May 06, 2005 at 06:35:45PM +0200, Juerd wrote:
: Which things can receive?
:
: If I recall things correctly, we already have these:
:
: sub # slurpy list
: arrary
: hash
:
: Would it make sense to add, for example,
:
: filehandle # write
:
: It may not, as it's not reversible like the others are: a filehandle in
: list context doesn't slurp. It's probably better to let this be done
: only with io().
That's one of the reasons io() is so Huffmanly short, I imagine.
: When piping to a scalar, I assume its reftype will determine what will
: happen. But what if the scalar is undef? Is it then assumed to want to
: behave like an array?
How does it autovivify, in other words? Maybe it autovivifies to
an iterator:
do_stuff() ==> my $iter;
for =$iter {...}
If someone wants to use an array, I don't see why they wouldn't just use @.
: When is the pointy side evaluated?
Whenever it asks for more data, and more data is available.
: How do you pipe to an array returned by a sub? ==> @ foo()?
==> foo()[]
That'd work for
==> $foo[]
as well, presumably, and autovivify an array in $foo.
We probably ought to consider the parallel aspects of piping to a hash,
since there's no requirement that a hash be built in order. With the
recent change to allow multiple input pipes, the pipes could probably
be run in parallel:
my %result <== [<==] @pairgenerators;
my %result{()} = 1 <== [<==] @keygenerators;
Actually that wouldn't work, since %result <== @a <== @b implies that
@b passes through @a on its way to %result. Maybe I mean something
more like:
my %result »<==« @pairgenerators;
my %result{()} = 1 »<==« @keygenerators
But actually, %result <== @a <== @b doesn't imply passage through
@a unless <== is right associative like assignment. If it's left
associative, it means (%result <== @a) <== @b, which can probably be
parallelized, just like @b ==> %result <== @a, and any other constructs
that can be borrowed from the B*f* class of languages.
I suppose ==> is left associative, which means that
@a ==> foo() ==> %result
does go through foo(). But that probably means
%result <== foo() <== @a
really wants to be right associative, which means we can't reduce with
it. However, we just got through saying that ; is basically equivalent
to <==. But ; could be construed as left associative, so maybe we can
say it like this:
my %result <== [;] @pairgenerators;
my %result{()} = 1 <== [;] @keygenerators;
Interestingly, reduction with [;] works at the top level and can't
be confused with statement-final semicolon.
So if we want to parallize input pipes, we just bind to Lazy *array
and arrange to read whichever lazy list has something for us. Probably
need some kind of internal support for that. Maybe any(@array).shift can
do it.
: Off topic, but I just thought of this again: is whitespace allowed or
: disallowed between sigil and name?
Disallowed.
Larry
Re: available operator characters
On Fri, May 06, 2005 at 06:24:00PM +0200, Juerd wrote: > To try and make it easier to pick (ASCII) operators, a simple table of > what's given away and what's available. Please let me know if there are > any mistakes. > > If anyone knows how to fill in the "???" parts, be my guest! > [...] > > \w+ infix only Ummm, what about C and C ? Pm
Re: available operator characters
Luke Palmer skribis 2005-05-06 11:04 (-0600): > Because we're marking all of our singular nouns with $, and you have > to admit, the $ sigil in perl code is much more common than @ and %. > What good is a noun marker if you mark some of your verbs with it too? But verbing doesn't weird language at all! Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: available operator characters
On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote: > Luke Palmer skribis 2005-05-06 10:43 (-0600): > > > !not none() ??? > > Nope. In order to create those, you just need to say none(). There > > is no operator form. > > Do we have postfix ! for factorials, or is it available? No, it's available. What would we use to demonstrate how to write postfix operators (not to mention recursive functions) if we made that standard? > > > $$ AVAILABLE?AVAILABLE > > Nope. Not in term position. I hardly think it would be a good idea > > to make an operator out of it (or even a single $), however. > > Why would a single $ be a bad operator? We already have the single % for > mod, and that works well. I think @ and $ are perfect candidates for > infix operators. Because we're marking all of our singular nouns with $, and you have to admit, the $ sigil in perl code is much more common than @ and %. What good is a noun marker if you mark some of your verbs with it too? Luke > > That's "class sigil" in term position. Separating namespaces never > > have preceding whitespace, so they're always part of some larger term. > > Is there any important difference between "namespace" and "class" in > Perl 6? Do they share the same, ehm, namespace? (classspace?) Just making sure you weren't considering the :: in $Foo::Bar to be an operator. There is a difference between class and namespace in that a class is a type and a namespace isn't. But I think you mark them both with the :: sigil in this case. Luke
Re: receivers of pipes (the sharp end again)
Luke Palmer skribis 2005-05-06 10:45 (-0600):
> > How do you pipe to an array returned by a sub? ==> @ foo()?
> Well, you'd have to be piping into a returned array ref, because you
> can't pipe into the list the sub returns. So I think it's ==>
> @{foo()}
> > Off topic, but I just thought of this again: is whitespace allowed or
> > disallowed between sigil and name?
> Disallowed.
Does this mean that @{foo()} can be written as @ foo()?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: available operator characters
Luke Palmer skribis 2005-05-06 10:43 (-0600):
> Thanks! Here's an annotated bit for each ?.
Only the triple-questionmarks were meant as questions. I should have
picked a better meta-operator for AVAILABLE?. But apparently, even
though I didn't mean to ask so many questions, there still are answers I
hadn't thought about.
Thanks for your detailed reply!
> > !not none() ???
> Nope. In order to create those, you just need to say none(). There
> is no operator form.
Do we have postfix ! for factorials, or is it available?
> > $$ AVAILABLE?AVAILABLE
> Nope. Not in term position. I hardly think it would be a good idea
> to make an operator out of it (or even a single $), however.
Why would a single $ be a bad operator? We already have the single % for
mod, and that works well. I think @ and $ are perfect candidates for
infix operators.
> I suppose it is. That would destroy Damian's favorite little idiom:
> while ($x --> 0) {...}
aww :)
> That's "class sigil" in term position. Separating namespaces never
> have preceding whitespace, so they're always part of some larger term.
Is there any important difference between "namespace" and "class" in
Perl 6? Do they share the same, ehm, namespace? (classspace?)
Thanks again.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: bitter complaints
On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> According to S03, the yada operator "complains bitterly" when used. In
> #perl6, we can't agree on what that means. Please help. Does it die,
> warn or fail?
>
> 18:46 < Corion> Juerd: "Complain bitterly" is "output a warning" to me.
> 18:46 < Juerd> It's "die" to me
> 18:46 < Odin-> Juerd: Hmm. I'd read it as "print a huge, ten page banner
> alerting to an error, and then go on"...
>
> And we want ??? and !!! to be aliases for ... if it dies, or to dieing
> yadas if ... itself merely warns:
It dies if ever executed, IIRC. Would you want:
sub get_user_list() {...}
my @users = get_user_list;
To merely warn? I think die "get_user_list not implemented" is more
appropriate there.
I can see something like:
sub term: { warn "You should probably put something here" }
Being useful, but not that useful.
Luke
Re: available operator characters
Luke Palmer skribis 2005-05-06 10:43 (-0600): > Why the %!@ would you ignore that!? :-) I hate my brain. Now I wonder if Bool.does(Hash). Does it? :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
bitter complaints
According to S03, the yada operator "complains bitterly" when used. In
#perl6, we can't agree on what that means. Please help. Does it die,
warn or fail?
18:46 < Corion> Juerd: "Complain bitterly" is "output a warning" to me.
18:46 < Juerd> It's "die" to me
18:46 < Odin-> Juerd: Hmm. I'd read it as "print a huge, ten page banner
alerting to an error, and then go on"...
And we want ??? and !!! to be aliases for ... if it dies, or to dieing
yadas if ... itself merely warns:
18:46 < Corion> Juerd: But "..." is more like "uh - I hope you know what
you're doing", where "???" is more like "WTF?", and "!!!" is more like "WTF!"
18:47 < Corion> Juerd: I see "..." as having practical use when stubbing
out code - I would want the code to warn but continue. How else would
you do that?
18:47 < Corion> sub do_magic { ... }
18:47 < Corion> looks good, and should warn "do_magic is not yet
implemented at $?LINE"
18:48 < Corion> while
18:48 < Corion> sub magic { ??? }
18:48 < Corion> should die.
Though we'd have to discuss the precise meanings of "WTF?" and "WTF!".
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: receivers of pipes (the sharp end again)
On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> When piping to a scalar, I assume its reftype will determine what will
> happen. But what if the scalar is undef? Is it then assumed to want to
> behave like an array?
If you're piping into a scalar without parens, I think it should
always become an array ref.
> How do you pipe to an array returned by a sub? ==> @ foo()?
Well, you'd have to be piping into a returned array ref, because you
can't pipe into the list the sub returns. So I think it's ==>
@{foo()}
> Off topic, but I just thought of this again: is whitespace allowed or
> disallowed between sigil and name?
Disallowed.
Luke
Re: available operator characters
On 5/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> To try and make it easier to pick (ASCII) operators, a simple table of
> what's given away and what's available. Please let me know if there are
> any mistakes.
Thanks! Here's an annotated bit for each ?.
> If anyone knows how to fill in the "???" parts, be my guest!
> !not none() ???
Nope. In order to create those, you just need to say none(). There
is no operator form.
> !! AVAILABLE?AVAILABLE?
Given prefix:, I suppose that is available.
> @@ AVAILABLE?AVAILABLE
Yep.
> $$ AVAILABLE?AVAILABLE
Nope. Not in term position. I hardly think it would be a good idea
to make an operator out of it (or even a single $), however.
> %hash mod
> %% AVAILABLE?AVAILABLE?
Yes.
> \\ AVAILABLE?AVAILABLE
Uh huh.
> == AVAILABLE?num eq
Fortunately yes. Let's keep it that way.
> --> AVAILABLE AVAILABLE?
I suppose it is. That would destroy Damian's favorite little idiom:
while ($x --> 0) {...}
But I don't think that's a huge loss. :-)
> <-> don't touch it, I'm going to use this for -> is rw :)
In operator position. In term position it is a single-quoted -.
> ?? AVAILABLE?ternary
Yep.
> :: namespace ternary
That's "class sigil" in term position. Separating namespaces never
have preceding whitespace, so they're always part of some larger term.
> \w+ infix only
> xpassive repeat
> xx passive repeat
> Xactive repeat ???
> XX active repeat ???
Those two haven't been blessed, and, though I don't have the message,
I think I remember Larry being a little hesitant about adding those.
> Yzip()
> many still available!
>
> With double characters (like ~~), "AVAILABLE?" means that if we start
> using that, stacking of the single thing will start requiring
> whitespace, as with = and == in $foo = =$fh)
>
> "ws?" means that whitespace may be needed for disambiguation.
>
> I left out colon and semicolon because they're too special to fit in a
> term|op table. I think it's more than safe to assume they're taken :)
Um, yes.
> <> is more flexible than {}, [] and () because it's a quoting operator
> (the inside is not an expression).
>
> I think it's best to ignore entirely the fact that we can use more
> triple character proper operators :)
Why the %!@ would you ignore that!? :-)
Luke
receivers of pipes (the sharp end again)
Which things can receive? If I recall things correctly, we already have these: sub # slurpy list arrary hash Would it make sense to add, for example, filehandle # write It may not, as it's not reversible like the others are: a filehandle in list context doesn't slurp. It's probably better to let this be done only with io(). When piping to a scalar, I assume its reftype will determine what will happen. But what if the scalar is undef? Is it then assumed to want to behave like an array? When is the pointy side evaluated? How do you pipe to an array returned by a sub? ==> @ foo()? Off topic, but I just thought of this again: is whitespace allowed or disallowed between sigil and name? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl6 and support for Refactoring IDE's
Matisse, Will Perl 6 help us have tools that are as good or better than the ones available for Java, C#, etc? I've been using Perl since 1994 and for the past several years have used it to build a number of complex mod_perl applications. I love Perl. The following may be considered heresy, but I believe that these days the quality of the whole development environment is just as important, maybe *more* important than the language itself. I mean that the availability of *easily integrated* tools including IDE, automated testing tools, refactoring, deployment tools, etc. are a HUGE factor in determining what language gets used for a large project Heresy or not, I think you are (mostly) right. Actually I would say your are right *unfortunately*. Available tools are a huge factor, yes - not in a way as which language to select for a project, but which one to *deselect*. And currently Perl (I mean Perl5) is not doing very well compared to others. I've become scared that if Perl is to continue to be viable for large, complex, multi-developer projects that the tools need to serious catch-up with what is available for Java, for example. Things like: - Refactoring Support (see http://www.refactoring.com/) - CVS and/or Subversion integration - Support for integrating regression tests and auto-building - Automated syntax and dependency checking IMHO subversioning does not have too much to do with the language itself. Subversioning operates on files. An IDE might integrate some interface for this task, but that is a different question. Syntax checking in general is very hard to do in Perl5/6 because of the great amount of line noise there (consider yourself in the middle of writing a regexp :)) The perl6 compiler must be able to do syntax checking, though :-), and the design of Perl6, as I understand, definetely gives you more possibilities compared to Perl5. For the others, some more knowledgeable folks will probably provide some answers and ideas. However, I think that the language design and implementation does not have too much to do with IDE availability. I've been using Eclipse, with the EPIC plugin (http://e-p-i-c.sourceforge.net/) and so far I like it. It uses Devel::Refactor to support "extract subroutine", but a lot more is needed to match what you can do with Java these days. What are others' thoughts on this? Have you considered using the "DONATE" button on http://e-p-i-c.sourceforge.net/ ? :))) - Fagzal
Re: Perl6 and support for Refactoring IDE's
On 5/6/05, J Matisse Enzer <[EMAIL PROTECTED]> wrote: > I've become scared that if Perl is to continue to be viable for large, > complex, multi-developer projects that the tools need to serious > catch-up with what is available for Java, for example. Things like: > >- Refactoring Support (see http://www.refactoring.com/) >- CVS and/or Subversion integration >- Support for integrating regression tests and auto-building >- Automated syntax and dependency checking > > I've been using Eclipse, with the EPIC plugin > (http://e-p-i-c.sourceforge.net/) and so far I like it. It uses > Devel::Refactor to support "extract subroutine", but a lot more is > needed to match what you can do with Java these days. > > What are others' thoughts on this? I think you're absolutely right. Perl should have an IDE with Eclipse-like context-sensitivity and refactoring support. However, it's hardly in Perl's philosophy or interest to bless one. One thing is for sure. Perl 6 is providing enough introspection and parsing capabilities to make it possible to write a context-sensitive IDE, unlike Perl 5 (well, Perl 5 made it *possible*, I suppose, but Perl 6 will make it obvious). Perl 6 is exposing its whole grammar at the language level, so you can say "give me a syntax tree for this chunk of code" and it will. Even if there are modules that change the syntax with macros (though your editor might have trouble understanding what the macros mean). In other words, Perl 6 is open to the possibility of such an IDE, and is going to provide the machinery necessary to build a really good one, but I doubt it will become a development milestone. Luke
available operator characters
To try and make it easier to pick (ASCII) operators, a simple table of
what's given away and what's available. Please let me know if there are
any mistakes.
If anyone knows how to fill in the "???" parts, be my guest!
\W+ Term (pre|circ) Operator (post|in)
`AVAILABLE AVAILABLE
`` AVAILABLE AVAILABLE
~stringy concat
~... string bitops
~~ AVAILABLE?smart match
!not none() ???
!= ! ==
!~ ! ~~
!! AVAILABLE?AVAILABLE?
@array AVAILABLE
@@ AVAILABLE?AVAILABLE
#comment comment
$scalarAVAILABLE
$$ AVAILABLE?AVAILABLE
%hash mod
%% AVAILABLE?AVAILABLE?
^AVAILABLE one()
^^ AVAILABLE xor
&sub all()
&& (clash) and
*splat multiply
** steam roller power
() group sub (deref+)call (no ws)
()? (clash) AVAILABLE (ws)
\ref AVAILABLE
\\ AVAILABLE?AVAILABLE
|AVAILABLE any()
|| AVAILABLE or
[] aref|reduce array (deref+)subscript (no ws)
[]? (clash) AVAILABLE (ws)
{} href|closure hash (deref+)subscript (no ws)
{}? (clash) AVAILABLE (ws)
+numeric add
+... numeric bitops
++ preincpostinc
=iterate assign
=> AVAILABLE pair
== AVAILABLE?num eq
==> pipe pipe
-0-substract
-> sub sub
-- predecpostdec
--> AVAILABLE AVAILABLE?
'' q AVAILABLE ('|'')
"" qqAVAILABLE ("|"")
,??? list sep
,, ??? ???
<> qwhash (deref+)subscript (no ws)
<>? (clash) AVAILABLE (ws)
<(clash) less-than (ws)
<= (clash) le (ws)
<== pipe pipe
<-> don't touch it, I'm going to use this for -> is rw :)
>AVAILABLE (ws)greater-than
>= AVAILABLE (ws)ge (ws?)
<<>> qwhash (deref+)subscript (no ws)
<<[>>]? (clash) AVAILABLE (ws)
<< hyper hyper
>> hyper hyper
.$_. (deref+)subscript|method call
/(clash) divide
// m// defined-or
?true AVAILABLE
?... boolean bitops
?? AVAILABLE?ternary
:: namespace ternary
\w+ infix only
xpassive repeat
xx passive repeat
Xactive repeat ???
XX active repeat ???
Yzip()
many still available!
With double characters (like ~~), "AVAILABLE?" means that if we start
using that, stacking of the single thing will start requiring
whitespace, as with = and == in $foo = =$fh)
"ws?" means that whitespace may be needed for disambiguation.
I left out colon and semicolon because they're too special to fit in a
term|op table. I think it's more than safe to assume they're taken :)
<> is more flexible than {}, [] and () because it's a quoting operator
(the inside is not an expression).
I think it's best to ignore entirely the fact that we can use more
triple character proper operators :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Perl6 and support for Refactoring IDE's
Will Perl 6 help us have tools that are as good or better than the ones available for Java, C#, etc? I've been using Perl since 1994 and for the past several years have used it to build a number of complex mod_perl applications. I love Perl. The following may be considered heresy, but I believe that these days the quality of the whole development environment is just as important, maybe *more* important than the language itself. I mean that the availability of *easily integrated* tools including IDE, automated testing tools, refactoring, deployment tools, etc. are a HUGE factor in determining what language gets used for a large project I've become scared that if Perl is to continue to be viable for large, complex, multi-developer projects that the tools need to serious catch-up with what is available for Java, for example. Things like: - Refactoring Support (see http://www.refactoring.com/) - CVS and/or Subversion integration - Support for integrating regression tests and auto-building - Automated syntax and dependency checking I've been using Eclipse, with the EPIC plugin (http://e-p-i-c.sourceforge.net/) and so far I like it. It uses Devel::Refactor to support "extract subroutine", but a lot more is needed to match what you can do with Java these days. What are others' thoughts on this? --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: reduce metaoperator
On Fri, May 06, 2005 at 12:23:49PM +1000, Stuart Cook wrote:
> On 5/6/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> > (snip) As long as each meta-operator
> > explicitly knows what type of regular operator it accepts (and
> > produces), there shouldn't be any problems with ambiguity.
> >
>
> Having posted that, I immediately thought of some problems:
>
> If a meta-operator has
> {meta-fixity => prefix|circumfix, result-fixity => prefix}
> then it can be confused with a term, e.g.:
>
> $x = [+1, -2, +3]; # opening [ indicates a term
> $y = [+] @stuff; # opening [ indicates a meta-op producing a prefix operator
>
> This might confuse the parser, though I suppose you could always try
> both possibilities and see which one works.
It might not be a problem -- I'm thinking we may end up tokenizing
most or all of the meta operators, so that [+] would be considered
its own token, and then the "longest matching token" rule
would be sufficient to disambiguate the terms:
$x = [+1, -2, +3]; # token [ indicates a term
$y = [+] @stuff; # token [+] indicates a meta-op prefix operator
Or, the entry for the reduce meta operator might look something like
%prefixmetaops[ rx / \[ %infixops \] / ] = ...
in which case the parser would still be able to easily disambiguate
the differences when it's expecting an operator.
Pm
Re: stdio
On Thu, 2005-05-05 at 15:15, Aaron Sherman wrote:
> Dash this all on the rocks if you want, but understand that this is not
> an off-the-cuff reply, but something that I've spent a lot of time
> mulling over
[...]
> First off, IMHO, open should be an alias for a closure-wrapped
> constructor, like so:
>
> sub open := IO.new;
Some reading later, I see mixed references to &, but I thought & had
been re-glommed for other purposes yep, pugs confirms & works.
> This makes "open" the maximally
> dwimish operator. You can always introduce a "sysopen" and "stdiopen"
> and "sockopen", etc. if you want domain-specific behavior exclusively
> (e.g. treat everything as a filename only, or as a host:port only, etc).
This deserves a bit more detail than I gave it before (pardon, I'm
typing as I debug work code).
"open" as a verb is extremely ambiguous. In dictionary searches I see as
many as 19 definitions just for the verb form.
"open" as a POSIX function is not ambiguous at all. But will the POSIX
model be the model on which P6 is based (as P5 was), or will the POSIX
model simply be one of many models supported by open and other
built-ins?
I think that it's fair to say that Perl has grown beyond POSIX. If it
also presents the URI model, that's not all bad, is it?
Same goes for the Unix command-line conventions (e.g. cat's "-" special
filename). I should be able to request a "pure POSIX" open, but I'm not
sure it should be the default for one of English's most powerfully
flexible verbs.
> and perhaps even
>
> File::Copy::copy("-","-");
This brings up something interesting. If we have:
sub File::Copy::copy(IO $file1, IO $file2) {...}
the above doesn't work.
I think I want:
sub File::Copy::copy(IO $file1 :r, IO $file2 :w) {...}
But does that work the way I think it does? Does that end up calling:
IO.new("-", :r);
and
IO.new("-", :w);
? If not, how do I ensure that this works correctly?
> Sure enough, there's an easy way:
>
> class IO is ParrotIO does RegisteredStringConstructor {...}
> role RegisteredStringConstructor {
> has %:registry;
> sub register(Any $pattern, Type $type) {
> %:registry{$pattern} = $type;
> }
> multi method new(Str $string,*%rest) {
> for %:registry.keys -> $pat {
> if $string ~~ $pat {
> return
> %:registry{$pat}.bless(:string($string),*%rest);
> }
> }
I would need some error handling here, and possibly would need to defer
to a parent as a fallback.
That brings up the idea of delegation... should this be handled by
delegation instead of the way I've done it? Not sure. I'm still trying
to figure out how to make this scope correctly so that:
use IO;
{
use IO::URI :open;
open("http://www.perl.org/",:r);
}
open("http://www.perl.org",:r);
opens two very different things: a socket to a host and port as directed
by a URI vs a file named "www.perl.org" in a directory called "http:".
> Optional export features of IO::* could allow:
>
> * pipeline command execution
> * thread and/or process coupling
> * handle duping
> * much more
>
> Thus, you would control these features like so:
>
> use IO;
> use IO::Funky :register_string_open_funkiness;
> open("funk",:w);
Which is probably just the tip of the iceberg. You might, for example,
want to lay out a user-defined filesystem, or open database tables as
files, etc.
Of course, you can do all of this explicitly through OO syntax, but it
would be nice to uniformly export locator semantics as strings so that
command-line and other string-based user interaction could be made more
powerful with a single "use".
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: The pipe's sharp end
On 5/6/05, Brad Bowman <[EMAIL PROTECTED]> wrote:
> Hi,
>
> <$*IN> ==> process() ==> print;
>
> This A06 example got me thinking.
> Could non-variadic subrountines in a pipeline be useful?
>
> A single arg sub or block could be a map without the "map":
>
> <$*IN> ==> &process ==> print;
> # print map { process($_) } <$*IN>
>
> (1..6) ==> { $_++ } ==> say;
Hmm. Well, considering that that is the same as:
(1..6) ==> map { $_++ } ==> say;
And in fact, you can just slap map in front of anything you want to do
that, I don't think we're buying much by letting you leave it off.
What if you give it a 1-ary sub that you thought was slurpy, and in
fact does something different (hmm, that doesn't seem very likely).
How do we handle options and the like?
Still, semantics like that are dwimmery, and the pipe operators are as
yet non dwimmy, so we'd be paying a price. Is that more or less than
three characters (when the pipe operators are already three
characters)?
Also, as you point out below, the semantics are less than obvious for
subs with arity > 1. So it would be tough to figure out what IM
anyway.
Luke
The pipe's sharp end
Hi,
<$*IN> ==> process() ==> print;
This A06 example got me thinking.
Could non-variadic subrountines in a pipeline be useful?
A single arg sub or block could be a map without the "map":
<$*IN> ==> &process ==> print;
# print map { process($_) } <$*IN>
(1..6) ==> { $_++ } ==> say;
A two param sub might reduce (I just caught up on the thread)
but that wouldn't play nicely with infinite or lazy lists.
Since that seems to be the point of pipelines, it's probably
a bad idea. It could produce a stream of the accumulated results:
(1..6) ==> { $^a + $^b } ==> ...;
# (3,6,10,15,21) or (1,3,6,10,15,21)
Alternatively, the list could be processed pairwise,
with or without overlaps, producing:
(1+2),(2+3),(3+4),(4+5),(5+6) # overlapping
(1+2), (3+4), (5+6) # non-overlapping
Overlapping seems more useful and less likely to cause
problems with an odd length list.
I think I should just post this before I start on:
(1..6) ==> { $^a ... $^b ... $^c }
Brad
--
It is bad to carry even a good thing too far. Even concerning things such as
Buddhism, Buddhist sermons, and moral lessons, talking too much will bring
harm. -- Hagakure http://bereft.net/hagakure/
