On Fri, Jan 17, 2003 at 12:19:01PM -0500, Dan Sugalski wrote:
> At 8:08 AM -0800 1/17/03, David Storrs wrote:
> >On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> >> At 7:13 AM -0800 1/17/03, David Storrs wrote:
> >> >
> >> >Do we at least all agree that it would be a good thing if
At 8:08 AM -0800 1/17/03, David Storrs wrote:
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
At 7:13 AM -0800 1/17/03, David Storrs wrote:
>Do we at least all agree that it would be a good thing if Unicode were
>the default character set for everything, everywhere? That is,
>e
* David Storrs <[EMAIL PROTECTED]> [2003-01-17 19:29:25]:
> On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> > At 7:13 AM -0800 1/17/03, David Storrs wrote:
> > >Do we at least all agree that it would be a good thing if Unicode were
> > >the default character set for everything, ever
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote:
> > On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote:
> > > The headers I received make no mention of character set - does
> your mailer
> > > mark the message in any wa
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> At 7:13 AM -0800 1/17/03, David Storrs wrote:
> >Do we at least all agree that it would be a good thing if Unicode were
> >the default character set for everything, everywhere? That is,
> >editors, xterms, keyboards, etc?
>
> No. No,
At 7:13 AM -0800 1/17/03, David Storrs wrote:
Do we at least all agree that it would be a good thing if Unicode were
the default character set for everything, everywhere? That is,
editors, xterms, keyboards, etc?
No. No, we don't.
--
Dan
On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote:
> On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote:
> > The headers I received make no mention of character set - does your mailer
> > mark the message in any way? If not, then STMP will assume it's good old
> > 7 bi
On 2003-01-16 at 16:42:15, Buddha Buck wrote:
> [Note: I originally sent this to Mr. Nobody alone, but that wasn't my
> intent. I'm re-sending it here, where I wanted it to go in the first
> place. -- bmb]
This came in with a content type text/plain, charset=us-ascii.
US-ASCII is by definition 7
On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote:
> The headers I received make no mention of character set - does your mailer
> mark the message in any way? If not, then STMP will assume it's good old
> 7 bit ASCII
Thus we are back to using uuencode :-)
-Scott
--
Jonathan Scott Du
On Thu, Jan 16, 2003 at 04:59:43PM -0500, Buddha Buck wrote:
> Buddha Buck wrote:
> >
> >
> >Maybe, maybe not On my machine right now, it is very easy for me to
> >type various accented letters, like a, e, etc, making words like resume
> >(or is that resume) nearly as fast to type as the non-a
Buddha Buck wrote:
Maybe, maybe not On my machine right now, it is very easy for me to
type various accented letters, like a, e, etc, making words like resume
(or is that resume) nearly as fast to type as the non-accented version
resume.
Hmmm, that's not what I wrote... On my machine, I
[Note: I originally sent this to Mr. Nobody alone, but that wasn't my
intent. I'm re-sending it here, where I wanted it to go in the first
place. -- bmb]
Mr. Nobody wrote:
trigraphs are actually better, even if you are unicode capable. ~> is
far
easier to type than ctrl-u-15F9E2A01 or whate
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:
[... Massive elision ...]
> >
> > Right now almost all of us are in that boat. And we're talking
> about
> > trigraph ops, like ~> and <~ and |~> and [+=] and whatever. As we
> get
> > better, more Unic
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
>
> --- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > > --- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > > > [EMAIL PROTECTED] (Dan Sugalski) writes:
> > > > > Ah, that's a different question. Having Uni
Whoever is working for qlcomm.com tech support and subscribed from work
should probably unsubscribe and use a personal account, unless your
boss wants 20+ messages per day coming in to your corporate mailbox.
--- Administrator <[EMAIL PROTECTED]> wrote:
>
>
> Dear Customer,
>
> Your query has
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > --- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] (Dan Sugalski) writes:
> > > > Ah, that's a different question. Having Unicode synonyms may
> well
> > > be
> > > > considered reason
[EMAIL PROTECTED] (Mr. Nobody) writes:
> Argh, I just realized the original was probably sarcastic too. Now I look
> like an idiot. Well, moreso than before.
There has been more than a touch of sarcasm about nearly every post in
this thread in the last two days.
--
"So i get the chance to reread
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> > Well, I don't know about anyone else, but *I'm* planning on making
> > many, many Unicode synonyms, to make my code shorter and more readable.
> >
> > For example, C is too long, so I want to just mak
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> Well, I don't know about anyone else, but *I'm* planning on making
> many, many Unicode synonyms, to make my code shorter and more readable.
>
> For example, C is too long, so I want to just make it curly-f,
> (Æ). And C is even longer, so I'm g
Glad to see someone heeded that warning about unrecognizable sarcasm;
no danger of misinterpretation here . . . :)
On 2003-01-16 at 10:01:04, Michael Lazzaro wrote:
> Well, I don't know about anyone else, but *I'm* planning on making
> many, many Unicode synonyms, to make my code shorter and more
On Thursday, January 16, 2003, at 08:57 AM, Mark J. Reed wrote:
On 2003-01-16 at 11:41:56, Dan Sugalski wrote:
And keyboards, don't forget keyboards. These pesky primitive ones we
have now would require a lot of shift-control-alt-meta-cokebottle key
sequences...
Unicode may have thousands of c
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Mr. Nobody:
> # --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> # > It's very much like the good old days of trigraphs. But on the plus
> # > side, once all the losers get their fonts/xterms/editors
> # up-to-speed
> # > on extended character sets, the
Mr. Nobody:
# --- Austin Hastings <[EMAIL PROTECTED]> wrote:
# > It's very much like the good old days of trigraphs. But on the plus
# > side, once all the losers get their fonts/xterms/editors
# up-to-speed
# > on extended character sets, the trigraphs will die a
# forgotten death.
#
# How ab
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Simon Cozens <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Dan Sugalski) writes:
> > > Ah, that's a different question. Having Unicode synonyms may well
> > be
> > > considered reasonable thing
> >
> > Sounds like the good old days of trigra
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:08 AM -0800 1/16/03, Austin Hastings wrote:
> >--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] (Dan Sugalski) writes:
> >> > Ah, that's a different question. Having Unicode synonyms may
> well
> >> be
> >> > considered reaso
On 2003-01-16 at 11:41:56, Dan Sugalski wrote:
> And keyboards, don't forget keyboards. These pesky primitive ones we
> have now would require a lot of shift-control-alt-meta-cokebottle key
> sequences...
Unicode may have thousands of characters, but how many of them do you
think you'll use often
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> And keyboards, don't forget keyboards. These pesky primitive ones we
> have now would require a lot of shift-control-alt-meta-cokebottle key
> sequences...
And vt100 consoles ! There are still sysadmins that struggle with a buggy
perl script, having r
At 8:08 AM -0800 1/16/03, Austin Hastings wrote:
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Ah, that's a different question. Having Unicode synonyms may well
be
> considered reasonable thing
Sounds like the good old days of trigraphs.
It's very
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Dan Sugalski) writes:
> > Ah, that's a different question. Having Unicode synonyms may well
> be
> > considered reasonable thing
>
> Sounds like the good old days of trigraphs.
It's very much like the good old days of trigraphs. Bu
On Wed, Jan 15, 2003 at 10:50:57PM -0500, Dan Sugalski wrote:
> At 12:05 AM + 1/16/03, Simon Cozens wrote:
> >[EMAIL PROTECTED] (Dan Sugalski) writes:
> >> Ah, that's a different question. Having Unicode synonyms may well be
> >> considered reasonable thing
> >
> >Sounds like the good old day
At 12:05 AM + 1/16/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
Ah, that's a different question. Having Unicode synonyms may well be
considered reasonable thing
Sounds like the good old days of trigraphs.
I was shooting for the good old days of sarcasm that people no
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Ah, that's a different question. Having Unicode synonyms may well be
> considered reasonable thing
Sounds like the good old days of trigraphs.
--
A witty saying means nothing. -Voltaire
[EMAIL PROTECTED] (Mr. Nobody) writes:
> Unicode operators in the core are a very, very, very, very, very, very, very,
> very, very, very, very, very, very bad idea.
We've done that.
--
COBOL is for morons.
-- E.W. Dijkstra
Mr. Nobody wrote:
> --- Buddha Buck <[EMAIL PROTECTED]> wrote:
>
> > Mr. Nobody wrote:
> >
> > > --- Buddha Buck <[EMAIL PROTECTED]> wrote:
> > >
> > > > We've already had this discussion.
> > >
> > > So if we already talked about why they're such a terrible idea,
> > > why are people still pr
At 11:19 AM -0800 1/13/03, Austin Hastings wrote:
So the real question should be "What kind of upgrade path are we
providing for converting these tired old multigraphs into single
uniglyphs?"
Ah, that's a different question. Having Unicode synonyms may well be
considered reasonable thing, thoug
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:52 AM -0800 1/13/03, Austin Hastings wrote:
> >--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> >> --- Buddha Buck <[EMAIL PROTECTED]> wrote:
> >> > Mr. Nobody wrote:
> >> >
> >> > >
> >> > > Unicode operators in the core are a very, very, very
--- Buddha Buck <[EMAIL PROTECTED]> wrote:
> Mr. Nobody wrote:
> > --- Buddha Buck <[EMAIL PROTECTED]> wrote:
> >
> >>Mr. Nobody wrote:
> >>
> >>
> >>>Unicode operators in the core are a very, very, very, very, very, very,
> >>
> >>very,
> >>
> >>>very, very, very, very, very, very bad idea.
> >>
At 10:52 AM -0800 1/13/03, Austin Hastings wrote:
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
--- Buddha Buck <[EMAIL PROTECTED]> wrote:
> Mr. Nobody wrote:
>
> >
> > Unicode operators in the core are a very, very, very, very, very,
very,
> very,
> > very, very, very, very, very, very bad
--- Thom Boyer <[EMAIL PROTECTED]> wrote:
> Mr. Nobody <[EMAIL PROTECTED]> says:
> > Unicode operators in the core are a very, very, very, very, very, very,
> very,
> > very, very, very, very, very, very bad idea.
>
> OK, now I think I know how _you_ would vote on the subject of Unicode
> operator
--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Buddha Buck <[EMAIL PROTECTED]> wrote:
> > Mr. Nobody wrote:
> >
> > >
> > > Unicode operators in the core are a very, very, very, very, very,
> very,
> > very,
> > > very, very, very, very, very, very bad idea.
> >
> > We've already had this di
--- Buddha Buck <[EMAIL PROTECTED]> wrote:
> Mr. Nobody wrote:
>
> >
> > Unicode operators in the core are a very, very, very, very, very, very,
> very,
> > very, very, very, very, very, very bad idea.
>
> We've already had this discussion. We wouldn't be bringing up using
> unicode operators
Mr. Nobody wrote:
Unicode operators in the core are a very, very, very, very, very, very, very,
very, very, very, very, very, very bad idea.
We've already had this discussion. We wouldn't be bringing up using
unicode operators for this function if we hadn't already talked about
unicode oper
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 12, 2003 at 11:50:14AM +, Richard J Cox wrote:
> >
> > U+21DC "Leftwards Squiggle Arrow" and U+21DE "Rightwards Squiggle Arrow"
> would
> > seem to fit the bill rather well maybe the ascii <~ and ~> are merely
> > aliases of the tru
On Sun, Jan 12, 2003 at 11:50:14AM +, Richard J Cox wrote:
>
> U+21DC "Leftwards Squiggle Arrow" and U+21DE "Rightwards Squiggle Arrow" would
> seem to fit the bill rather well maybe the ascii <~ and ~> are merely
> aliases of the true symbols?
If we go this route, I would suggest that w
On Friday, January 10, 2003, 9:05:42 PM, you (mailto:[EMAIL PROTECTED]) wrote:
> Universe 2 (pro-unicode): "If we had a Unicode 'squiggly arrow' operator,
> then however it looks on everybody's display, it ought to at least look like
> some kind of squiggly arrow."
U+21DC "Leftwards Squiggle Arr
Luke Palmer writes:
> I don't think so. Rather, that becomes:
>
> him.hit(I);
>
> And to clarify, you should probably format it like this:
>
> hit him: I;
>
> But computer languages aren't generally used to specify past tense
> anyway
>
why priperties are sort of ... becau
On Friday, January 10, 2003, at 09:56 PM, Damian Conway wrote:
Just out of curiosity, how did you measure that? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) returns Int is exported {
return sum [»ord«split//,$x]
On Fri, 10 Jan 2003 14:12:12 +, Thom Boyer wrote:
> 'Course, then I've gotta explain why
> $x = 7 ~> 63;
> doesn't evaluate to 9
Surely because you haven't yet overloaded gozinta for the Number class!
-- c
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? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) retur
Let me just chime in here that I have been reading all the
messages via mutt in an xterm font in which the
tilde is at the top of the space, and this has in no way
affected my appreciation of the new operators.
I don't want them to look like arrows, because that's reminiscent
of ->, which is misle
On Fri, Jan 10, 2003 at 03:55:30PM -0500, Andrew Rodland wrote:
> On Friday 10 January 2003 11:42 am, Paul Johnson wrote:
> > Damian Conway said:
> > > Andy Wardley wrote:
> > >> The arrow is a special case. I don't read that first character
> > >> as '-', I think of the operator as one. I guess
Paul Johnson wrote:
> When I later saw it using mutt in an xterm, the tilde was at the top of
> the character, where I was more used to seeing it and it didn't look like
> an arrow any more, nor did it look very good to me.
Ah yes, that's the problem. On all my fonts, the tilde appears at
the top
> Date: Fri, 10 Jan 2003 08:12:48 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
>
> --- attriel <[EMAIL PROTECTED]> wrote:
> > Could someone explain how to know what's the indirect object? (who
> > knew
> > the "sentence diagramming" would be USEFUL!!)
>
> Short version:
>
> If there'
Andrew Rodland <[EMAIL PROTECTED]> wrote:
> 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.
Here, here! Al
Paul Johnson <[EMAIL PROTECTED]> wrote:
> When I later saw it using mutt in an xterm, the tilde was at the top of
> the character, where I was more used to seeing it and it didn't look like
> an arrow any more, nor did it look very good to me.
Well, at least now I understand why some people didn't
On Friday 10 January 2003 11:42 am, Paul Johnson wrote:
> Damian Conway said:
> > Andy Wardley wrote:
> >> 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.
> >
> > I'm suggesting
--- attriel <[EMAIL PROTECTED]> wrote:
> Ah. OK, thanks :) I had the basic idea, but I wasn't sure how to
> tell in perl which parameter was the indirect object :o
Right, "o" in your sentence above is the object.
> if I'm following this right, it's the inferred object such that (in
> p5) if I
Trey Harris raised the spectre of:
shades of C++, how about just
$*STDERR <~ $foo;
Yes. Assuming C were suitably overloaded.
or
$foo ~> $*STDERR;
Yes. Assuming C were suitably overloaded.
Not sure whether that would come "standard", but if not, here's
a first cut of the necessary mod
Damian Conway said:
> Andy Wardley wrote:
>> 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.
>
> I'm suggesting that ~> and <~ will be the same.
I think that in part this may depe
--- attriel <[EMAIL PROTECTED]> wrote:
> Could someone explain how to know what's the indirect object? (who
> knew
> the "sentence diagramming" would be USEFUL!!)
Short version:
If there's two people in the sentence, the verb-ee is either the direct
or indirect object. If there's two people and
Mr. Nobody wrote:
I find the normal function call and assignment far more readable than using
some weird ugly operator.
and later:
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
Andy Wardley wrote:
s/~=/=~/
Indeed. And that's precisely why we're changing it to ~~ in Perl 6. ;-)
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 th
> 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 stu
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 co
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
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
--- "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.
--- 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 ri
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 nic
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? Th
(/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 {...} gre
--- 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:
>
>
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;
>
>> 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 'm
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
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
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:
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
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 pro
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 bina
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 pri
Trey Harris wrote:
I love this.
And any class could override the <~ operator, right?
Right.
I suppose it could be done like arithmetic
overloading, if you define both <~ ("I'm being pointed at from the right")
and ~> ("I'm being pointed at from the left") in your class then Perl will
use wh
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 08 Jan 2003 12:14:10 +0800
> > From: Damian Conway <[EMAIL PROTECTED]>
> >
> > Can I suggest that an alternative solution might be the following:
> >
> > Suppose Perl 6 had two new very low precedence operators: ~> and <~
> > (a.
Dave Whipp wrote:
Something else springs to mind. Consider the C syntax:
for 1,2,3 ~> foo -> $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
I think I see what
Dave Whipp wrote in perl.perl6.language :
> But with the different precedence. At last, I can assign from a list without
> using parentheses:
>
> @a = 1, 2, 3; # newbie error
> @a <~ 1, 2, 3; # would work
or :
@a <~ 1 <~ 2 <~ 3;
or :
1, 2, 3 ~> @a;
which would be also written as :
Nicholas Clark wrote in perl.perl6.language :
>> Actually I don't think you can define a grammar where two operators have
>> the same precedence but different associativity. Be it a pure BNF
>> grammar, or a classical yacc specification (using the %left and %right
>> declarations).
>
> But that wo
"Buddha Buck" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> and similarly,
>
> $a <~ ...;
>
> is equivalent to
>
> $a = ...;
But with the different precedence. At last, I can assign from a list without
using parentheses:
@a = 1, 2, 3; # newbie error
@a <~
> Actually I don't think you can define a grammar where two operators have
> the same precedence but different associativity. Be it a pure BNF
> grammar, or a classical yacc specification (using the %left and %right
> declarations).
But that would mean only perl6 could pass perl6, which isn't much
Damian Conway wrote:
> [...] <~ and ~>
Michael Lazzaro wrote:
> I too think this idea is fabulous. You are my hero.
I also think this is semantically fabulous but syntactically slightly
dubious. '~' reads 'match' in my book, so I'm reading the operators
as 'match left' and 'match right'. Or p
-Original Message-
Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote:
> Actually I don't think you can define a grammar where two operators have
> the same precedence but different associativity. Be it a pure BNF
> grammar, or a classical yacc specification (using the %left and %right
> decl
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 08, 2003 at 05:14:06PM +0100, 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 )
On Tuesday, January 7, 2003, at 08:14 PM, Damian Conway wrote:
Just when you thougth it was safe to go back on the mailing list,
Damian attempts to resurrect a dead can of worms:
And all because Mike Lazzaro wrote:
OK, but let it be known that the resulting megathread is now _your_
fault, not
Jonathan Scott Duff:
# And that, of course, leads us to sort of "unzip" were mutual
# exclusion is not a requisite:
#
# @list ~| grep length == 1 ~> @onecharthings
# ~| grep [0..29] ~> @numberslessthan30
# ~| grep /^\w+$/ ~> @words
# ~| grep $_%2==0 ~> @e
Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> Not necessarily. <~ will necessarily need to be right-associative,
> while ~> left, however.
Not sure if you aren't getting this backwards, but anyway I often find
myself confused with right and left.
> It would be logical to give them the same
> prece
--- attriel <[EMAIL PROTECTED]> 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;
> >
> > which is probably not what i wanted...
>
>
Luke Palmer wrote:
I would, from the descriptions, imagine that:
@keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw;
Would parse as:
@keep <~ grep /good/ <~ @list;
@list ~> grep /bad!/ ~> @throw;
Nope. <~ and ~> only *rearrange* arguments, so if you only type @list
once, you can only
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 8 Jan 2003 10:45:37 -0600
> From: Jonathan Scott Duff <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Mail-Followup-To: frederic fabbro <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Content-Dispositi
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 8 Jan 2003 11:30:51 -0500 (EST)
> From: "attriel" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
>
> Note 1) This is the second time I'm typing this
> Note 2) Ctr
On Wed, Jan 08, 2003 at 08:31:51AM -0800, Austin Hastings wrote:
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > @out = @a ~> grep {...} ~> map {...} ~> sort;
> > ...
> > @out <~ sort <~ map {...} <~ grep {...} <~ @a;
For the record, I think this is great.
> Bril
On Wed, Jan 08, 2003 at 05:14:06PM +0100, 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;
>
> which is probably not wha
1 - 100 of 115 matches
Mail list logo
