Re: Pike 7.4
[EMAIL PROTECTED] (Mr. Nobody) writes: > We can't use « or ». Not only are they impossible to type on some editors, > but they're different in CP437 (the DOS charset), Latin1, and UTF8. We've done this. -- I've looked at the listing, and it's right! -- Joel Halpern
Re: L2R/R2L syntax (was Re: Everything is an object.)
Philip Hellyer wrote: Damian's proposal didn't say anything about array params. If I understood him correctly, then this should print "FOO" on standard out: my $foo = "FOO"; $foo ~> print; Correct. The opposite 'squiggly arrow' fiddles the indirect object, so perhaps this would print "FOO" on standard error (modulo the STDERR syntax, which I think changed when I wasn't looking): $foo ~> print <~ STDERR; Bad Philip! Wicked, wicked Philip! ;-) One *might* argue that <~ ought to be of higher precedence than ~> (i.e. that invocants ought to be bound ahead of other arguments). If so, then: $foo ~> print <~ $*STDERR is really: $foo ~> print $*STDERR: is really: $foo ~> print $*STDERR: $foo So yes. But don't do that! ;-) Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Jonathan Scott Duff suggested:
> Oh, then we just need a syntax to split the streams. ... I know!
>
> @list ~| grep /bad!/ ~> @throw ~| grep /good/ ~> @keep;
Unfortunately, that's already taken (it's the bitwise-OR-on-a-string operator).
Fortunately that doesn't matter, since no extra binary operator is actually
needed to achieve the unzipping you desire.
All we need is a unary prefix form of ~>.
Unary ~> would (by analogy to unary dot) append the current topic to the
argument list of its operand.
Thus, your examples become simply:
given @list {
~> grep /bad!/ ~> @throw;
~> grep /good/ ~> @keep;
}
And:
given @list {
~> grep length == 1 ~> @onecharthings;
~> grep [0..29] ~> @numberslessthan30;
~> grep /^\w+$/ ~> @words;
~> grep $_%2==0 ~> @evennumbers;
}
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro wrote: I'm not even sure how that would parse, though that: > @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw; > would go like: > ( @keep <~ grep /good/ <~ @list ) ~> grep /bad!/ ~> @throw; Correct, if <~ is indeed slightly higher precedence than ~> which is probably not what i wanted... True. The presence of both operators in an expression probably ought to trigger a (silenceable) warning. Damian
Re: Variable Types Vs Value Types
Rafael Garcia-Suarez asked: > Damian Conway <[EMAIL PROTECTED]> wrote: > >>There are in fact *two* types associated with any Perl variable > > How does it work regarding inheritance and polymorphism ? > E.g. consider > my @a is Set of Apple; > my @b is Basket of Fruit; > with Apple isa Fruit, and Basket is a Set. > > I assume I can use @a or @b where the expected type is: > > @a @b > Set ok ok > Set of Fruit ok ok > Set of Apple ok no(?) > Basketno ok > Basket of Fruit no ok > Basket of Apple no no(?) All of these seem to make the same incorrect assumption: that the implementation type specifies what a variable evaluates to. It doesn't. The storage type does that. So, saying: my @a is Set of Apple; doesn't make C<@a> evaluate to an object of class C. Nor does it define that @a can store a C. We *can* answer your real question (about inheritance and compound types), but we have to start with the right declarations: my $a returnsSet of Apple; my $b returns Basket of Fruit; or: my Set of Apple $a; my Basket of Fruit $b; and a generic assignment: $c = $a; $c = $b; Now we can fill in your list (which is somewhat expanded): AssignmentOK?Because... ===== === my Set $c = $aok $c's type: Set (of Object) ^ ^ | | $a's type: Set of Apple my Set $c = $bok $c's type: Set (of Object) ^ ^ | | $b's type: Basket of Fruit my Set of Fruit $c = $a ok $c's type: Set of Fruit ^ ^ | | $a's type: Set of Apple my Set of Fruit $c = $b ok $c's type: Set of Fruit ^ ^ | | $b's type: Basket of Fruit my Set of Apple $c = $a ok $c's type: Set of Apple ^ ^ | | $a's type: Set of Apple my Set of Apple $c = $b no $c's type: Set of Apple ^ X | | $b's type: Basket of Fruit my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket $c = $b ok $c's type: Basket (of Object) ^ ^ | | $b's type: Basket of Fruit my Basket of Fruit $c = $ano $c's type: Basket of Fruit X ^ | | $a's type: Set of Apple my Basket of Fruit $c = $bok $c's type: Basket of Fruit ^ ^ | | $b's type: Basket of Fruit my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple my Basket of Apple $c = $bno $c's type: Set of Apple ^ X | | $b's type: Basket of Fruit ^ As usual the | arrow between two classes represents the C<.isa> relationship. X And I've used the symbol
Re: Pike 7.4
Chris Dutton wrote:
For example, I'm struggling to see how one could use the [*] to do this:
@names = «Gödel Escher Bach»;
@ages = $today »-« %date_of_birth{@names}
While I agree that hyper-operators are the better way to go(though I can
see advantages either way), I was bored, so I tried to figure out a not
entirely unpleasant Perl6-ish version of the Pike syntax.
@ages[*] = $today - %date_of_birth{@names}.values[*]
Well done. Thanks for working that out, Chris. And, in the process,
confirming my sense that vector ops are a better solution here.
;-)
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Andy Wardley wrote:
I also think this is semantically fabulous but syntactically slightly
dubious. '~' reads 'match' in my book,
Really? We don't have any trouble in Perl 5 with an = character
being used in various unrelated operators:
== comparison
=assignment
~= match
=> comma
<= less than or equal to
or with - as a component of each of:
-- decrement
-difference
-= subtraction
-> dereference
-X file op
I'm just suggesting the same for the ~ character:
~~ smart-match
~concatenate
~| stringy bitwise OR
~> append args
<~ invocate
I would prefer something like <| and |> which has a more obvious
connotation (to me at least) of "pipe left" or "pipe right".
I can certainly see the appeal, and I did consider this very alternative
(after Dan had privately suggested the two symbols to me). But they simply
don't work as well visually.
I mean, compare:
@a ~> grep {...} ~> map {...} ~> sort ~> @a;
@a <~ sort <~ map {...} <~ grep {...} <~ @a;
with:
@a |> grep {...} |> map {...} |> sort |> @a;
@a <| sort <| map {...} <| grep {...} <| @a;
I don't know about *your* font, but in mine the ~> and <~ versions are
at least twice as readable as the |> and <| ones.
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
In a message dated Thu, 9 Jan 2003, Damian Conway writes: > One *might* argue that <~ ought to be of higher precedence than ~> > (i.e. that invocants ought to be bound ahead of other arguments). > > If so, then: > >$foo ~> print <~ $*STDERR > > is really: > >$foo ~> print $*STDERR: > > is really: > >$foo ~> print $*STDERR: $foo > > So yes. > > But don't do that! Well, shades of C++, how about just $*STDERR <~ $foo; or $foo ~> $*STDERR; ? Stylistically, I often find myself needing to embed a complex expression in a print(), and as anyone who's read my articles knows, I really despise parens in normal sub calls (not method calls). Yes, yes, I could do $*STDERR.print() instead, but I'm trying to reduce visual clutter, not resort to a mechanism that requires it :-) Trey -- I'm looking for work. If you need a SAGE Level IV with 10 years Perl, tool development, training, and architecture experience, please email me at [EMAIL PROTECTED] I'm willing to relocate for the right opportunity.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway wrote:
> Really? We don't have any trouble in Perl 5 with an = character
> being used in various unrelated operators:
>
> == comparison
> =assignment
> ~= match
s/~=/=~/
> => comma
> <= less than or equal to
But these are all roughly related to the concept of "equality", be it
testing equality, enforcing equality by assignment, equality in terms of
matching a pattern, setting a parameter to equal a value, testing is
something is equal or less than equal to something else.
The use of '=' seems entirely consistent in these operators.
> -- decrement
> -difference
> -= subtraction
> -> dereference
> -X file op
The first 3 all relate to the familiar concept of 'minus', or more
precisely a delta between two values. The last uses '-' as 'dash',
another familiar concept which doesn't grate against the first usage,
IMHO. The arrow is a special case. I don't read that first character
as '-', I think of the operator as one. I guess the visual cue forces
me to see it like that.
These operators may not be internally self-consistent, but I don't think
it's a problem having different meaning for '-', given that both meanings
are well understood to anyone who knows basic math and has used a command
line program with a -x argument.
> I'm just suggesting the same for the ~ character:
>
> ~~ smart-match
> ~concatenate
> ~| stringy bitwise OR
> ~> append args
> <~ invocate
This is where I get lost. I see 4 different concepts being overloaded
onto '~'.
In the first it indicates 'match' just as it always has for =~ and !~.
In the second, it is being used for concatentation - nothing to do with
matching. In the third it is being used to cast stringwisely - nothing
to do with matching or concatenation. In the fourth and fifth it is being
used to re-order arguments - nothing to do with matching, concatenation
(well, possibly concatenation of argument lists) or stringwise casting.
Now that I look at it again, the '~~' operator bothers me in particular.
The first '~' seems to indicate 'stringwise' in keeping with '~|'
and the second implies 'match' in keeping with '=~'.
I find it questionable to use the same character twice in one operator
and have different semantics implied for each. '~' should either be
'match' or 'stringwise' but not both.
I would like to see '~' kept for matching and just matching. It is well
known in this role and is analogous to the "roughly equals" operator
in the Real World (extended ASCII character 247 - just don't ask me to type
it).
I also think '_' should be used for concatenation because it's in keeping
with the existing use of 123_456.
As a prefix character to indicate stringwise (numberwise, bitwise, etc)
casting, can we not use a single character prefix, e.g. 's' for string,
'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
$a s| $b;# stringwise
$a b| $b;# bitwise
$a n| $b;# numberwise
@a v| @b;# vector
@a vsn| @b; # vector stringwise bitwise
I see these as being similar to regex flags. In a regex we don't
have two separate metacharacters for matching \w case sensitively or
insensitively. Instead we use the 'i' flag outside the regex or
within the regex, scoping the parts of the pattern to which it applies:
m/foo/i
m/(?i:foo)/
m:i/foo/
I think we should adopt the same strategy for regular operators. Rather
than create umpteen new operators to perform every operation in every
different style, we should keep the operation orthogonal to the context
in which the operator is applied. So instead of having a vector addition
operator, we have an addition operator and a vector flag which can be
applied to it.
> I mean, compare:
> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
> with:
> @a |> grep {...} |> map {...} |> sort |> @a;
>
> I don't know about *your* font, but in mine the ~> and <~ versions are
> at least twice as readable as the |> and <| ones.
In my font, or perhaps more importantly, to my eye, the |> and |< are
more readable. But regardless, I think it's more important to make the
operators consistent with each other, than to make them look pretty or
easy to read. The latter is important, of course, but I personally believe
that it's no use making something easy to read if the meaning is still hard
to comprehend. Better to make something harder to read but easier to
understand.
A
Re: Array Questions
Michael Lazzaro asked:
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes. Though we would need a syntax for specifying that string parameter for the
generic C class. And, of course, a mechanism for constructing the
non-generic version of the generic class from the corresponding argument.
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed. In fact, there may even be a standard property that does this kind of
thing:
# Note: this is purely speculative...
my $str is from($filename); # text in file becomes chars in string
my @lines is from($filename); # lines in file become elements in array
my %config is from($filename); # colon-separated fields in file become kv pairs in hash
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote:
I don't like either of these operators. What's wrong with
>
> @out = sort map {...} grep {...} @a
>
> ?
For a start, if these functions were to become (only) methods in Perl 6,
it would have to be:
@out = sort map grep @a: {...} : {...} :;
And even if we do have both functional and methodical versions, this:
@out <~ sort <~ map {...} <~ grep {...} <~ @a;
is still clearer in its intent than:
@out = sort map {...} grep {...} @a;
And the squiggly version is also reversible, for those who are more
comfortable with reading left-to-right.
@a ~> grep {...} ~> map {...} ~> sort ~> @out;
Plus we get a "tee" functionality from unary ~>.
Damian
Re: Variable Types Vs Value Types
On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote:
> At 7:29 PM -0700 1/7/03, John Williams wrote:
> >Perhaps you could explain how the $0 object will work in your mind.
> >A5 assert that $0 is a object, and it behaves as an array and a hash,
> >depending on how you subscript it. Typeglobs are gone, and we're all
> >hoping the TIE interface is gone too, so how will this effect be
> >accomplished?
>
> All variables in parrot are implemented as PMCs, and all PMCs may be
> accessed with a string, integer, or PMC subscript or set of
> subscripts. For PMCs that don't do subscripting this will be a fatal
> error, for those that do it'll do whatever the PMC is supposed to do.
> (In the case of $0, do the lookup)
That's phrased like it's the type of the subscript value which determines
whether it's a hash-like or array-like access. Shouldn't it be the type of
brackets which do that?
In other words, I don't want to see this happen:
$a[1]; # array-like
$a['1'];# hash-like
$a{1}; # array-like
$a{'1'};# hash-like
It should be like this:
$a[1]; # array-like
$a['1'];# array-like
$a{1}; # hash-like
$a{'1'};# hash-like
Maybe it is the right way round, and I've read your remarks the wrong way.
Or maybe it is the value type which determines the type of access at the PMC
level, and it's up to the compiler to force the type based on the brackets.
--
Peter Haworth [EMAIL PROTECTED]
"After all, what is your hosts' purpose in having a party? Surely not for
you to enjoy yourself; if that were their sole purpose, they'd have simply
sent champagne and women over to your place by taxi."
-- P J O'Rourke
Re: Variable Types Vs Value Types
On Thu, 9 Jan 2003, Peter Haworth wrote: > On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote: > > At 7:29 PM -0700 1/7/03, John Williams wrote: > > >Perhaps you could explain how the $0 object will work in your mind. > > >A5 assert that $0 is a object, and it behaves as an array and a hash, > > >depending on how you subscript it. Typeglobs are gone, and we're all > > >hoping the TIE interface is gone too, so how will this effect be > > >accomplished? > > > > All variables in parrot are implemented as PMCs, and all PMCs may be > > accessed with a string, integer, or PMC subscript or set of > > subscripts. For PMCs that don't do subscripting this will be a fatal > > error, for those that do it'll do whatever the PMC is supposed to do. > > (In the case of $0, do the lookup) > > That's phrased like it's the type of the subscript value which determines > whether it's a hash-like or array-like access. Shouldn't it be the type of > brackets which do that? Yes, that's what I meant, even if I didn't say it clearly. "How you subscript it" would be either "with brackets" or "with braces". ~ John Williams
Re: Pike 7.4
On Thursday, January 9, 2003, at 05:36 AM, Damian Conway wrote:
Chris Dutton wrote:
@ages[*] = $today - %date_of_birth{@names}.values[*]
Well done. Thanks for working that out, Chris. And, in the process,
confirming my sense that vector ops are a better solution here.
;-)
Glad I could contribute in some small way.
Re: Variable Types Vs Value Types
> my Set of Apple $a; > my Basket of Fruit $b; > > and a generic assignment: > > $c = $a; > $c = $b; > > Now we can fill in your list (which is somewhat expanded): > AssignmentOK?Because... ======== my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple Now, just to be sure I didn't miss a step: That second entry is wrong, sin't it? it should be OK? no b/c: C's Type : Basket of Apple X^ || A's Type : Set of Apple yes? (I'm trying to make sure I didn't miss a majikal mystery conversion step that seems contradictory but somehow exists anyway :o) --attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
>> I'm just suggesting the same for the ~ character:
>>
>> ~~ smart-match
>> ~concatenate
>> ~| stringy bitwise OR
>> ~> append args
>> <~ invocate
>
> This is where I get lost. I see 4 different concepts being overloaded
> onto '~'.
>
> In the first it indicates 'match' just as it always has for =~ and !~.
> In the second, it is being used for concatentation - nothing to do with
> matching. In the third it is being used to cast stringwisely - nothing
> to do with matching or concatenation. In the fourth and fifth it is
> being used to re-order arguments - nothing to do with matching,
> concatenation (well, possibly concatenation of argument lists) or
> stringwise casting.
Well, I always used =~ // for strings, and (from what I gather) ~~ is the
uber =~ in that it can figure out types and meaningfully guess what
"matches" means, so I see the first 3 as "string toys", just as the -- -
and -= were all "subtraction"
I'll give you that ~> and <~ don't do stringy things, though :) But I
think they'd be read, once it's more than theories in email messages ;o,
as single ops (like the ->) rather than "squiggly and arrow" it'd be
"squigglyarrow" ... I think the major concern would, to me, be that ~> and
-> are kinda close, visually, and I imagine nearly indistinguishable in
some fonts :/
> I would like to see '~' kept for matching and just matching. It is well
> known in this role and is analogous to the "roughly equals" operator in
> the Real World (extended ASCII character 247 - just don't ask me to type
> it).
Now you've given them ideas :) we're all gonna be typing ≈ (OK, so,
all I can get is that it's unicode 2248; still haven't figured out how to
ACTUALLY type it :o Alt-247() seems to be the wrong character though and
I don' see it anywhere on my HTML ascii chart :/
> I also think '_' should be used for concatenation because it's in
> keeping with the existing use of 123_456.
That actually reads like _ is a null character "This is not the character
you are looking for. There is no character, there is only zool" kinda
thing ... I know it's concat, but it reads more like a "visual separation
character that is COMPLETELY ignored by the parser, except insofar as to
explicitly ignore it"
> As a prefix character to indicate stringwise (numberwise, bitwise, etc)
> casting, can we not use a single character prefix, e.g. 's' for string,
> 'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
>
>$a s| $b;# stringwise
>$a b| $b;# bitwise
>$a n| $b;# numberwise
>@a v| @b;# vector
>@a vsn| @b; # vector stringwise bitwise
I think this was brought up during the operators thread (I admit, I only
skimmed it ... I had 6 or 7 versions in my inbox when I got to it :/) and
the "against"s pointed out that it would mandate whitespace separation
(although, some of the coders I know could live with some mandatory style
guidelines, ugh) ...
>> I mean, compare:
>> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
>> with:
>> @a |> grep {...} |> map {...} |> sort |> @a;
>>
>> I don't know about *your* font, but in mine the ~> and <~ versions are
>> at least twice as readable as the |> and <| ones.
>
> In my font, or perhaps more importantly, to my eye, the |> and |< are
> more readable. But regardless, I think it's more important to make the
To me, for some reason, |> reads as a forward gate "Do not continue unless
the previous item was true; if it was, feed the result here" ... <|
doesn't read like much, and |< looks like some 1337 h4xx0r trying to be
cool, honestly :o It just looks broken! As an op, I would expect it to
translate to "OR Less Than" and I can't come up with how to use that "$a
== 7 |< 200" I guess :o
And would the consistency rules require them to be:
~> ~< ? so that the ops look similar? (If so, I'm gonna vote that ~<
looks like a fish and is just weird :)
--attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway writes:
> Unary ~> would (by analogy to unary dot) append the current topic to the
> argument list of its operand.
>
> Thus, your examples become simply:
>
> given @list {
> ~> grep /bad!/ ~> @throw;
> ~> grep /good/ ~> @keep;
> }
>
> And:
>
> given @list {
> ~> grep length == 1 ~> @onecharthings;
> ~> grep [0..29] ~> @numberslessthan30;
> ~> grep /^\w+$/ ~> @words;
> ~> grep $_%2==0 ~> @evennumbers;
> }
>
> Damian
>
but if I dont want to force @list in scalar context ???
since ~> and friends are _pure_ grammar while given is not ,
probably we can have unary postfix ~> ( or |~> )
{
@list ~> ; # ( or @list |~> ; )
~> grep length == 1 ~> @onecharthings;
~> grep [0..29] ~> @numberslessthan30;
~> grep /^\w+$/ ~> @words;
~> grep $_%2==0 ~> @evennumbers;
}
as a way to multiplex @list
arcadi
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Mr. Nobody wrote:
>
> > I don't like either of these operators. What's wrong with
> >
> > @out = sort map {...} grep {...} @a
> >
> > ?
>
> For a start, if these functions were to become (only) methods in Perl 6,
> it would have to be:
>
> @out = sort map grep @a: {...} : {...} :;
That's why I want them to be normal functions, not methods.
>
> And even if we do have both functional and methodical versions, this:
>
> @out <~ sort <~ map {...} <~ grep {...} <~ @a;
>
> is still clearer in its intent than:
>
> @out = sort map {...} grep {...} @a;
I find the normal function call and assignment far more readable than using
some weird ugly operator.
> And the squiggly version is also reversible, for those who are more
> comfortable with reading left-to-right.
>
> @a ~> grep {...} ~> map {...} ~> sort ~> @out;
That's going to be just plain confusing. Arguments to functions are supposed
to be on the right. And what's up with using them for assignment? That's
making them even more overcomplicated and ugly. Do you care about readability
at all? It seems to me that ~> and <~ have no use except making perl 6 uglier
and more complicated than it already is. They're completely unnecessary.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Variable Types Vs Value Types
At 2:08 PM + 1/9/03, Peter Haworth wrote: On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote: At 7:29 PM -0700 1/7/03, John Williams wrote: >Perhaps you could explain how the $0 object will work in your mind. >A5 assert that $0 is a object, and it behaves as an array and a hash, >depending on how you subscript it. Typeglobs are gone, and we're all >hoping the TIE interface is gone too, so how will this effect be >accomplished? All variables in parrot are implemented as PMCs, and all PMCs may be accessed with a string, integer, or PMC subscript or set of subscripts. For PMCs that don't do subscripting this will be a fatal error, for those that do it'll do whatever the PMC is supposed to do. (In the case of $0, do the lookup) That's phrased like it's the type of the subscript value which determines whether it's a hash-like or array-like access. Shouldn't it be the type of brackets which do that? [snip] Maybe it is the right way round, and I've read your remarks the wrong way. Or maybe it is the value type which determines the type of access at the PMC level, and it's up to the compiler to force the type based on the brackets. Got it in two, more or less. I'm waffling on whether a type flag in the key structure is necessary--I can see it going both ways. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
(/dks attempts to pour water.)
Damian Conway <[EMAIL PROTECTED]> wrote:
> > And even if we do have both functional and methodical versions, this:
> >
> > @out <~ sort <~ map {...} <~ grep {...} <~ @a;
> >
> > is still clearer in its intent than:
> >
> > @out = sort map {...} grep {...} @a;
Mr. Nobody wrote:
> I find the normal function call and assignment far more readable than using
> some weird ugly operator.
Ok, but "weird" and "ugly" are personal opinions--that is, they are a
question of aesthetics, not language design, and aesthetics varies
from person to person. A lot of other people (myself included), seem
to find the ~> operator to be kinda cool. Is this a case where we
could just agree that TIMTOWTDI?
> > And the squiggly version is also reversible, for those who are more
> > comfortable with reading left-to-right.
> >
> > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
>
> That's going to be just plain confusing. Arguments to functions are supposed
> to be on the right.
Don't think of it as a function call then. Think of it as a pipeline,
where data flows in the direction of the arrows.
> And what's up with using them for assignment? That's
> making them even more overcomplicated and ugly. Do you care about readability
> at all? It seems to me that ~> and <~ have no use except making perl 6 uglier
> and more complicated than it already is. They're completely unnecessary.
Now don't hold back on account of social niceties like not wanting to
cloud the issue with emotion or low-level ad hominem attacks. Tell us
what you _really_ think. :>
--Dks
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody <[EMAIL PROTECTED]> wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
>
> That's going to be just plain confusing. Arguments to functions are
supposed
> to be on the right. And what's up with using them for assignment? That's
> making them even more overcomplicated and ugly. Do you care about
readability
> at all? It seems to me that ~> and <~ have no use except making perl 6
uglier
> and more complicated than it already is. They're completely unnecessary.
1) "Arguments to functions are supposed to be on the right."
Hmmm. If you use a mathematical context, I guess "supposed to" could be code
for "I've always done it that way". But certainly not "supposed to" in any
cosmic sense.
But what The Damian is proposing is much more like a Unix pipeline than
mathematics.
@a ~> grep {...} ~> map {...} ~> sort ~> @out;
makes much more sense when you see it as being much more akin to
cat a | grep ... | tr ... | sort > out
than
let out = sort(map {...} (grep {...} @a))
No, it's not like the math that is one of Perl's influences. It's like the
Unix shells, which is another of Perl's influences.
2) "And what's up with using them for assignment? That's making them even
more overcomplicated and ugly. "
If you read ~> and <~ as "stuff this thingy into that doohicky", assignment
makes perfect sense. They are plumbing connectors: sometimes they connect
the water softener to the water heater (one device to another), and
sometimes they connect to the water supply (a source) or the sink (a sink).
I don't see that as an overcomplication, but as a very straightforward and
obvious extension.
3) "Do you care about readability at all? It seems to me that ~> and <~
have no use except making perl 6 uglier and more complicated than it already
is."
I think ~> and <~ look pretty nice. They read well as a single symbol, they
make good sense, they make it possible to say more directly exactly what
your code means, they show the direction of data flow quite well, and the
"ripply water" look emphasizes the plumbing analogy.
=thom
Tom MacKenzie: Say, Jubal...how do you feel about astrology?
Jubal Harshaw: Never touch the stuff. Prefer brandy.
--Stranger in a Strange_Land
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 09, 2003 at 11:01:51AM -0700, Thom Boyer wrote: > Mr. Nobody <[EMAIL PROTECTED]> wrote: > 3) "Do you care about readability at all? It seems to me that ~> and <~ > have no use except making perl 6 uglier and more complicated than it already > is." > > I think ~> and <~ look pretty nice. They read well as a single symbol, they > make good sense, they make it possible to say more directly exactly what > your code means, they show the direction of data flow quite well, and the > "ripply water" look emphasizes the plumbing analogy. Yep. The only niggling problem that I have is that ~> and <~ aren't stringy but the look like they should be. If we hadn't already taken ->, I'd've preferred to see -> and <- instead. But, I'm sure I'll be happy with whatever Larry decides. He always seems to apply the appropriate discriminator in his synthesis of ideas. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- Thom Boyer <[EMAIL PROTECTED]> wrote:
> Mr. Nobody <[EMAIL PROTECTED]> wrote:
> > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
> >
> > That's going to be just plain confusing. Arguments to functions are
> supposed
> > to be on the right. And what's up with using them for assignment? That's
> > making them even more overcomplicated and ugly. Do you care about
> readability
> > at all? It seems to me that ~> and <~ have no use except making perl 6
> uglier
> > and more complicated than it already is. They're completely unnecessary.
>
> 1) "Arguments to functions are supposed to be on the right."
>
> Hmmm. If you use a mathematical context, I guess "supposed to" could be
> code
> for "I've always done it that way". But certainly not "supposed to" in any
> cosmic sense.
>
> But what The Damian is proposing is much more like a Unix pipeline than
> mathematics.
> @a ~> grep {...} ~> map {...} ~> sort ~> @out;
> makes much more sense when you see it as being much more akin to
> cat a | grep ... | tr ... | sort > out
> than
> let out = sort(map {...} (grep {...} @a))
> No, it's not like the math that is one of Perl's influences. It's like the
> Unix shells, which is another of Perl's influences.
It's not letting you do anything that you couldn't do before with normal
function calls and assignment.
> 2) "And what's up with using them for assignment? That's making them even
> more overcomplicated and ugly. "
>
> If you read ~> and <~ as "stuff this thingy into that doohicky", assignment
> makes perfect sense. They are plumbing connectors: sometimes they connect
> the water softener to the water heater (one device to another), and
> sometimes they connect to the water supply (a source) or the sink (a sink).
>
> I don't see that as an overcomplication, but as a very straightforward and
> obvious extension.
I see it as making a bad idea even worse. I've never liked having one thing
doing multiple completely different and ambiguous actions. (Does "$a ~> $b"
mean "$b.($a)" or "$b = $a"? How about "if $a ~> foo {...}"?)
> 3) "Do you care about readability at all? It seems to me that ~> and <~
> have no use except making perl 6 uglier and more complicated than it
> already
> is."
>
> I think ~> and <~ look pretty nice. They read well as a single symbol, they
> make good sense, they make it possible to say more directly exactly what
> your code means, they show the direction of data flow quite well, and the
> "ripply water" look emphasizes the plumbing analogy.
I agree that they look nice. It's a shame that they're being used for such an
awful proposal.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Thom Boyer <[EMAIL PROTECTED]> wrote:
> > Mr. Nobody <[EMAIL PROTECTED]> wrote:
> > > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > > > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
> > >
> > > That's going to be just plain confusing. Arguments to functions
> are
> > supposed
> > > to be on the right. And what's up with using them for assignment?
> That's
> > > making them even more overcomplicated and ugly. Do you care about
> > readability
> > > at all? It seems to me that ~> and <~ have no use except making
> perl 6
> > uglier
> > > and more complicated than it already is. They're completely
> unnecessary.
> >
> > 1) "Arguments to functions are supposed to be on the right."
> >
> > Hmmm. If you use a mathematical context, I guess "supposed to"
> could be
> > code
> > for "I've always done it that way". But certainly not "supposed to"
> in any
> > cosmic sense.
> >
> > But what The Damian is proposing is much more like a Unix pipeline
> than
> > mathematics.
> > @a ~> grep {...} ~> map {...} ~> sort ~> @out;
> > makes much more sense when you see it as being much more akin to
> > cat a | grep ... | tr ... | sort > out
> > than
> > let out = sort(map {...} (grep {...} @a))
> > No, it's not like the math that is one of Perl's influences. It's
> like the
> > Unix shells, which is another of Perl's influences.
>
> It's not letting you do anything that you couldn't do before with
> normal
> function calls and assignment.
Actually, this is false. The notion of directional pipeline operators
immediately begat two children, to wit:
1- The notion of simultaneous, synchronous execution of pipes, as in:
a ~> b ~> m <~ y <~ z;
Which people have sort of backed away from, but I think there still
might be something there, even if I can't personally set it yet.
2- It also (re) introduced the conceptual framework of unix pipes,
which immediately led to the (IMO: really good) suggestion of a "tee"
mechanism:
widget ~| expr a ;
~| expr b ;
~| expr c ;
And that one, I think, conceals a whole boatload of conceptual power.
So to me the pipeline operators are kind of like the ?: operator --
true, you don't need it (you could use C) but it enables other
things. Except in this case it might enable some really cool things.
And don't worry about the ~> syntax looking awkward. We'll probably
convert it to a Unicode special character in production :-) :-) :-).
=Austin
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody:
# It's not letting you do anything that you couldn't do before
# with normal function calls and assignment.
We're writing a useful language, not a Turing machine.
# I see it as making a bad idea even worse. I've never liked
# having one thing doing multiple completely different and
# ambiguous actions. (Does "$a ~> $b" mean "$b.($a)" or "$b =
# $a"? How about "if $a ~> foo {...}"?)
It means C<$a.infix:~>($b)>, where $a's class inherits:
method infix:~> (Perl6::Call $call);
method infix:~> (Code $sub);
method infix:~> ($target);
Or somesuch.
# I agree that they look nice. It's a shame that they're being
# used for such an awful proposal.
He was saying that they look nice for this application, so you obviously
don't agree.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: Variable Types Vs Value Types
On Wed, Jan 08, 2003 at 05:59:14PM +0800, Damian Conway wrote: > > my Array @array := SpecialArray.new; > > > > Should the value in @array act like an Array or a SpecialArray? Most > > people would say SpecialArray, because a SpecialArray ISA Array. > > Weell...*I'd* say that @array should act like an Array (that is, you should > only be able to call the methods specified by the Array class), except that > any method calls should be polymorphically resolved to invoke the > equivalent SpecialArray methods. > > But maybe that's just saying the same thing. Is there a linguist in the house? Will an English major do? If SpecialArray extends the interface of Array, then these two statements are not the same; the first statement gives you all of SpecialArray's functionality while the second statement gives you only a subset. --Dks
"Disappearing" code
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for debugging and
assertions. What everyone wanted to do was write code like this:
debug("Doing foo with $bar and $baz");
foo($bar, $baz);
And then have the entire call to debug() just plain disappear when the
program was run with a certain flag, or when a particular constant was set,
or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
use constant DEBUG => 0;
...
debug("Doing foo with $bar and $baz") if DEBUG;
foo($bar, $baz);
But all those "if DEBUG"s or "DEBUG &&"s were a pain. So I'm wondering what
the solution will be in Perl 6.
-John
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday, January 9, 2003, at 03:05 AM, Damian Conway wrote: I don't know about *your* font, but in mine the ~> and <~ versions are at least twice as readable as the |> and <| ones. Just out of curiosity, how did you measure that? ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: "Disappearing" code
> Date: Thu, 09 Jan 2003 19:55:20 -0500
> From: John Siracusa <[EMAIL PROTECTED]>
>
> Has there been any discussion of how to create code in Perl 6 that's there
> under some conditions, but not there under others? I'm thinking of the
> spiritual equivalent of #ifdef, only Perlish.
>
> In Perl 5, there were many attempts to use such a feature for debugging and
> assertions. What everyone wanted to do was write code like this:
>
> debug("Doing foo with $bar and $baz");
> foo($bar, $baz);
> And then have the entire call to debug() just plain disappear when the
> program was run with a certain flag, or when a particular constant was set,
> or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
>
> use constant DEBUG => 0;
> ...
> debug("Doing foo with $bar and $baz") if DEBUG;
> foo($bar, $baz);
Well, I just do:
sub debug {
print STDERR shift, "\n" if DEBUG;
}
And hopefully (I don't know P5 internals so well) that optimizes to a
no-op so there's not even a function call there. But it's a
negligible overhead anyway.
> But all those "if DEBUG"s or "DEBUG &&"s were a pain. So I'm wondering what
> the solution will be in Perl 6.
Not that C code is devoid of C<#ifdef>s everywhere there's conditional
code
I don't see how you could do much without actually labeling what you
wanted to disappear. You could always use:
sub debug(&code) {
&code() if DEBUG;
}
For a more versatile and readable solution. I'm not sure what could
be more concise than that.
Luke
Re: "Disappearing" code
On 1/9/03 9:01 PM, Luke Palmer wrote:
> Well, I just do:
>
> sub debug {
> print STDERR shift, "\n" if DEBUG;
> }
>
> And hopefully (I don't know P5 internals so well) that optimizes to a
> no-op so there's not even a function call there.
I don't know P5 internals so well either, but I'm guessing you'll still get
the function call to debug().
> But it's a negligible overhead anyway.
Hey, it adds up! Okay, maybe it doesn't...but still, Perl 6 Should Be Able
To Do This! :) And I'd also like inline constructs like:
ASSERT $foo > 5 && is_happy(blah);
that may or may not be the same as the debug situation in Perl 6.
> I don't see how you could do much without actually labeling what you
> wanted to disappear.
I basically want a language-level guarantee that the call to debug()
disappears entirely under certain conditions. I don't want to have to rely
on details of the optimizer or whatever.
-John
Re: "Disappearing" code
On 1/9/03 10:10 PM, Michael G Schwern wrote:
> I would assume it to be a compiler hint via subroutine attribute.
>
> sub debug ($msg) is off {
> print STDERR $msg;
> }
>
> some "this subroutine is a no-op if a flag is set" attribute.
Hm, not quite as convenient as setting a package global (constant)
somewhere. Maybe that same "off" bit could be set "from a distance" at
compile time?
-John
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday 09 January 2003 01:01 pm, Thom Boyer wrote:
> If you read ~> and <~ as "stuff this thingy into that doohicky", assignment
> makes perfect sense. They are plumbing connectors: sometimes they connect
> the water softener to the water heater (one device to another), and
> sometimes they connect to the water supply (a source) or the sink (a sink).
>
> I don't see that as an overcomplication, but as a very straightforward and
> obvious extension.
>
Agreed. I think that this is pretty nice.
> 3) "Do you care about readability at all? It seems to me that ~> and <~
> have no use except making perl 6 uglier and more complicated than it
> already is."
>
> I think ~> and <~ look pretty nice. They read well as a single symbol, they
> make good sense, they make it possible to say more directly exactly what
> your code means, they show the direction of data flow quite well, and the
> "ripply water" look emphasizes the plumbing analogy.
But you're missing the most important part!
I propose that these operators should be named "gozinta" ( ~>)
and "comezouta" ( <~ ), just so that we can say that perl has them. Not to
mention that the names work pretty well, for me.
Observe:
@a ~> map { ... } ~> grep { ... } ~> sort { ... } ~> @b;
@a gozinta map, which gozinta grep, then it gozinta sort, then it all gozinta
@b.
print sort { ... } <~ mymethod(42) <~ @b;
call sort on what comezouta calling mymethod(42) on what comezouta @b.
I think. Indirect objects are still somewhat confusing. :)
If I'm reading the info right on <~, then we want to make it clear that you
_don't_ put it between print and stuff you want to print, or in other words
that "this ain't cout".
Anyway, cool beans. :)
-- Andrew "hobbs" Rodland < arodland at noln dot com >
P.S. Delurk. Hi.
