On Mon, Jun 14, 2004 at 06:05:10PM -0400, Mark J. Reed wrote:
:
: On 2004-06-14 at 22:58:58, Matthew Walton wrote:
: > 'it would be better to explicitly just say
: >
: > (@list.grep value) = undef
: >
: > although I think that might be supposed to be
: >
: > (@list.grep value) »= undef;
:
: Th
Well, I'd speak up
for intentionally allowing some silly alternatives
except that's IMO unnecessary.
With all the apparently-wonderful new possibilities
which we'll soon have
(OK, maybe not as soon as we'd like),
it seems most likely
that some will turn out to be silly.
George "tim toady"
On Mo
Mark J. Reed wrote:
On 2004-06-14 at 22:58:58, Matthew Walton wrote:
'it would be better to explicitly just say
(@list.grep value) = undef
although I think that might be supposed to be
(@list.grep value) »= undef;
Those do different things according to my understanding. The first
removes all matc
On 2004-06-14 at 22:58:58, Matthew Walton wrote:
> 'it would be better to explicitly just say
>
> (@list.grep value) = undef
>
> although I think that might be supposed to be
>
> (@list.grep value) »= undef;
Those do different things according to my understanding. The first
removes all matchi
Austin Hastings wrote:
Perhaps we could consider the junctive lvalues as a sort of implied
?= operation:
junction(@list) = value
means
unless junction(@list) == value
{
given junction {
when 'none' { (@list.grep value) = undef; }
when 'any' { for 0 .. random(@list) { @
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Date: Wed, 28 Jan 2004 12:34:15 +1100
> From: "Damian Conway" <[EMAIL PROTECTED]> Add to Address Book
> To: "Language List" <[EMAIL PROTECTED]>
>Subject: Re: Semantics of vector operations (Damian
Scott wrote:
I'm just waiting for Damian to speak up :-)
I'm not at all comfortable with the notion of junctions as lvalues.
I've *always* considered a junction to be a special kind of constant, just as
a number or a string or a reference is.
I have trouble with junctive lvalues because I think t
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > Agreed. Cryptic, but in a different way than
Smylers writes:
> > ... It's almost getting to the point where we want to allow
> > disambiguating underscores in operators: >>_+<_<<. Alternately we
> > give up on <<>> as a qw// replacement and allow spaces: >> +< <<.
>
> How about going back to what you originally decreed in Apocalypse 2,
> th
Damian Conway writes:
> Larry mused:
>
> > ... I don't think people would be terribly pleased when they see
> > things like:
> >
> > @a »+<<« @b
>
> > [it] would certainly motivate people to move toward editors and
> > terminals that can display:
> >
> > @a »+<<« @b
>
> Yes, it would
Larry Wall writes:
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
>
> : Larry Wall writes:
> :
> : > On the other hand, we've renamed all the other bitwise operators,
> : > so maybe we should rename these too:
> : >
> : > + : > +>
Austin Hastings writes:
> With Larry's new "vectorized sides" suggestion, putting a guillemot on
> the right side of the operator ...
Austin, we've been through this before -- kindly return that guillemot
to wherever you picked it up from. It's hassle enough having unicode in
Perl, without us al
[Apologies for the delay in responding to this (and other) messages -- I
read some of these a couple of weeks ago but didn't want to reply till
I'd read the entire thread, then I was away a bit ...]
Larry Wall writes:
> On the other hand, it's possible that we should extend the visual
> metaphor
On Feb 02, David Wheeler wrote:
> On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote:
>
> >>I realize this is a tad OT, but can anyone tell me how I can get Emacs
> >>to properly display Unicode characters? I expect that others on the
> >>list could benefit, too.
> >
> >(require 'un-define)
>
>
On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote:
I realize this is a tad OT, but can anyone tell me how I can get Emacs
to properly display Unicode characters? I expect that others on the
list could benefit, too.
(require 'un-define)
Since I really don't understand Lisp, and since that simply
On Feb 2, 2004, at 5:20 PM, Larry Wall wrote:
That being said, we can potentially use × U+00D7 MULTIPLICATION SIGN.
(Though my vim can't seem to decide whether it's a single-width or a
double-width character, urgh...)
I realize this is a tad OT, but can anyone tell me how I can get Emacs
to prop
On Mon, Feb 02, 2004 at 11:44:17AM -0700, Luke Palmer wrote:
: Alex Burr writes:
: > --- Andy Wardley <[EMAIL PROTECTED]> wrote:
: >
: > > Adding unicode operators to Perl will just reinforce
: > > its reputation as
: > > a "line noise" language.
: >
: > Perl6, the language with *real* runes.
: >
On Mon, Feb 02, 2004 at 01:14:48PM -0500, John Macdonald wrote:
: On Mon, Feb 02, 2004 at 09:59:50AM +, Simon Cozens wrote:
: > [EMAIL PROTECTED] (Andy Wardley) writes:
: > > Sure, make Perl Unicode compliant, right down to variable and operator
: > > names. But don't make people spend an aft
Alex Burr writes:
> --- Andy Wardley <[EMAIL PROTECTED]> wrote:
>
> > Adding unicode operators to Perl will just reinforce
> > its reputation as
> > a "line noise" language.
>
> Perl6, the language with *real* runes.
>
> Come to think of it, some of the ogham runes would
> look more incharacter
On Mon, Feb 02, 2004 at 09:59:50AM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Andy Wardley) writes:
> > Sure, make Perl Unicode compliant, right down to variable and operator
> > names. But don't make people spend an afternoon messing around with mutt,
> > vim, emacs and all the other tools
--- Andy Wardley <[EMAIL PROTECTED]> wrote:
> Adding unicode operators to Perl will just reinforce
> its reputation as
> a "line noise" language.
Perl6, the language with *real* runes.
Come to think of it, some of the ogham runes would
look more incharacter as a 'distribute' operator than
guill
[EMAIL PROTECTED] (Andy Wardley) writes:
> Sure, make Perl Unicode compliant, right down to variable and operator
> names. But don't make people spend an afternoon messing around with mutt,
> vim, emacs and all the other tools they use, just so that they can read,
> write, email and print Perl
Luke Palmer wrote:
> But I'm still sure that the unicode-deficient would rather write:
I suspect the unicode-deficient would rather write Ruby.
Adding unicode operators to Perl will just reinforce its reputation as
a "line noise" language.
I know it has been said before, and I'm sure it will be
I wrote:
> But I think that literal >> and << are quite nice alternatives for  and
> Â [1], and if the only think that's holding us back is the bitshift
> operators, we should kill them -- turn them into functions or something.
> C and C aren't so bad, are they?
Or named operators. As in:
$
Austin Hastings writes:
> > -Original Message-
> > From: Gordon Henriksen [mailto:[EMAIL PROTECTED]
> > Austin Hastings wrote:
> >
> > > OTOH, Robin's concern for how to code when you're stuck with 7 bit
> > > ascii on the boot console of a Sun box remains valid, and *I* sure
> > > would ra
> -Original Message-
> From: Gordon Henriksen [mailto:[EMAIL PROTECTED]
> Austin Hastings wrote:
>
> > OTOH, Robin's concern for how to code when you're stuck with 7 bit
> > ascii on the boot console of a Sun box remains valid, and *I* sure
> > would rather have a short name available in a
Austin Hastings wrote:
OTOH, Robin's concern for how to code when you're stuck with 7 bit
ascii on the boot console of a Sun box remains valid, and *I* sure
would rather have a short name available in a standard way.
Perhaps a solution is a cultural one, that it simply be a point of good
style
Jonathan Lang writes:
> Luke Palmer wrote:
> > Scott Walters writes:
> > > Would it be possible to subclass things on the fly, returning a
> > > specialized object representing the argument that knew how to
> > > vectorize when asked to add? Aren't add, subtract, multiply, and so
> > > on, imple
Luke Palmer wrote:
> Scott Walters writes:
> > Would it be possible to subclass things on the fly, returning a
> > specialized object representing the argument that knew how to
> > vectorize when asked to add? Aren't add, subtract, multiply, and so
> > on, implemented as class methods in Perl 6,
On Fri, Jan 30, 2004 at 06:55:39AM -0700, Luke Palmer wrote:
: Luke Palmer writes:
: > Of course you mean "æinteracting withæ other correctly." :-)
:
: Grr! That ruined that joke! I'd better get this unicode thing figured
: out before Perl 6 is released.
:
: Âinteracting with other correct
Luke Palmer writes:
> Scott Walters writes:
> > This would lend itself a P5 backport that did overload on its argument, too. If
> > it found that the thing on the right hand side was also overloaded into the
> > same class, it is could use a single iterator on both sides, otherwise it would
> > tre
Scott Walters writes:
> On 0, Rod Adams <[EMAIL PROTECTED]> wrote:
> >
> > Also, isn't it a pain to type all these characters when they are not on
> > your keyboard? As a predominately Win2k/XP user in the US, I see all
> > these glyphs just fine,but having to remember Alt+0171 for a æ is going
Austin Hastings wrote:
From: Rod Adams [mailto:[EMAIL PROTECTED]
Question in all this: What does one do when they have to _debug_ some
code that was written with these lovely Unicode ops, all while stuck in
an ASCII world?
That's why I suggested a standard script for Unicode2Ascii be shi
> -Original Message-
> From: Rod Adams [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 29, 2004 11:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Semantics of vector operations
>
> Question in all this: What does one do when they have to _debug_ some
> co
> -Original Message-
> From: Austin Hastings [mailto:[EMAIL PROTECTED]
> > From: Rod Adams [mailto:[EMAIL PROTECTED]
> >
> > Question in all this: What does one do when they have to _debug_ some
> > code that was written with these lovely Unicode ops, all while stuck in
> > an ASCII w
On 0, Rod Adams <[EMAIL PROTECTED]> wrote:
>
> Also, isn't it a pain to type all these characters when they are not on
> your keyboard? As a predominately Win2k/XP user in the US, I see all
> these glyphs just fine,but having to remember Alt+0171 for a « is going
> to get old fast... I much so
Luke Palmer wrote:
Austin Hastings writes:
I think you guys may be talking at cross purposes. Robin, I think, is
talking primarily about coding, while Damian talks of reading.
Perhaps Damian's solution is a Unicode2Ascii perl script that emits formal
names, combined with the implementation in P
Austin Hastings writes:
> I think you guys may be talking at cross purposes. Robin, I think, is
> talking primarily about coding, while Damian talks of reading.
>
> Perhaps Damian's solution is a Unicode2Ascii perl script that emits formal
> names, combined with the implementation in Perl of the
>
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Austin Hastings writes:
> > Perhaps Damian's solution is a Unicode2Ascii perl script that
> > emits formal names, combined with the implementation in Perl of the
> > E alternative spellings.
> >
> > OTOH, Robin's conc
Robin Berjon asked:
>> Unicode has a *lot* of potential operators.
>
> Are all these for use in the core language though?
Not yet...but give us time! >;-)
> I was thinking about defining short names for the core stuff, and people
> can use the thirty letter names for more complicated things.
Yes
> -Original Message-
> From: Robin Berjon [mailto:[EMAIL PROTECTED]
> Damian Conway wrote:
> > Robin Berjon wrote:
> > > I wasn't proposing to come up with short names for all the Unicode
> > > repertoire, just for the characters that are used as operators :)
That
> > > shouldn't be to
> -Original Message-
> From: John Macdonald [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 29, 2004 8:30 AM
> To: Robin Berjon
> Cc: Damian Conway; [EMAIL PROTECTED]
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 29, 2004 at 11:52:04A
Damian Conway wrote:
Robin Berjon wrote:
> I wasn't proposing to come up with short names for all the Unicode
> repertoire, just for the characters that are used as operators :) That
> shouldn't be too long, should it?
I'm not so sure about that. I can already see those
mathematician/physicists
Robin Berjon wrote:
> I wasn't proposing to come up with short names for all the Unicode
> repertoire, just for the characters that are used as operators :) That
> shouldn't be too long, should it?
I'm not so sure about that. I can already see those mathematician/physicists
gazing hungrily at the
On Thu, Jan 29, 2004 at 11:52:04AM +0100, Robin Berjon wrote:
> I have nothing against using the Unicode names for other entities for
> instance in POD. The reason I have some reserve on using those for
> entitised operators is that E RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's re
Damian Conway wrote:
Robin Berjon wrote:
Picking the HTML entity names is better than the Unicode ones as the
latter are way too long. They may not cover all the characters we
need, but we can make up missing ones in a consistent fashion.
I fear there are too many "missing ones" for that.
Any rea
Robin Berjon wrote:
Picking the HTML entity names is better than the Unicode ones as the
latter are way too long. They may not cover all the characters we need,
but we can make up missing ones in a consistent fashion.
I fear there are too many "missing ones" for that.
Any reason we couldn't acce
Damian Conway wrote:
Frankly, I'd *much* rather see:
@sum = @a E+< @b;
my Vector $outer = $vec1 E $vec2;
which at least has the benefit of being consistent with POD notation.
I very much second that. Entities have been one of the worst features of
XML (and, in the end, a fairly usel
Larry mused:
But we also have the ambiguity with <<'' and friends, so maybe the real
problem is trying to make the << and >> workarounds look too much like
« and ». Maybe they should be :<< and :>> or some such. Maybe we
should be thinking about a more general trigraph (shudder) policy.
Nooo
> "JW" == John Williams <[EMAIL PROTECTED]> writes:
JW> On Fri, 23 Jan 2004, Larry Wall wrote:
>> Sorry, I was just copying the designers of supercomputers in my
>> terminology. So you can really blame Seymour Cray for misappropriating
>> the term. On a Cray, "vector processing" is j
On Fri, 23 Jan 2004, Larry Wall wrote:
> Sorry, I was just copying the designers of supercomputers in my
> terminology. So you can really blame Seymour Cray for misappropriating
> the term. On a Cray, "vector processing" is just operations applied
> in parallel to two one-dimensional lists. Unfo
On Friday, January 23, 2004, at 10:57 , Larry Wall wrote:
Anyway, if we do use _ for that, the people who want to warp Perl into
Prolog will have to use something else for unnamed bindings. :-)
Use ¬! Then the AppleScripters will feel right at home when they upgrade
to Perl 6. :/
—
Gordon Hen
On Fri, Jan 23, 2004 at 07:53:49PM -0800, Jonathan Lang wrote:
: Dave Whipp wrote:
: > But, presumably, you could write a macro that has a whitespace-eater
: > encoded
: > somehow. That is,
: >
: > macro leach() { chomp_trailing_whitespace; return "?" }
: > macro reach () { chomp_leading_whitespac
On Fri, Jan 23, 2004 at 06:43:04PM -0800, Dave Whipp wrote:
: "Larry Wall" <[EMAIL PROTECTED]> wrote in message
: news:[EMAIL PROTECTED]
: > That is, suppose you have:
: >
: > macro leach () { return "ï" }
: > macro reach () { return "ï" }
: >
: > You could unambiguosly write
: >
: > le
Dave Whipp wrote:
> But, presumably, you could write a macro that has a whitespace-eater
> encoded
> somehow. That is,
>
> macro leach() { chomp_trailing_whitespace; return "»" }
> macro reach () { chomp_leading_whitespace; return "«" }
>
> then the macro magic would expand "leach eq reach" as "»
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> That is, suppose you have:
>
> macro leach () { return "»" }
> macro reach () { return "«" }
>
> You could unambiguosly write
>
> leach+reach
>
> but (assuming spaces not allowed within distributed operators) you
On Fri, Jan 23, 2004 at 05:20:41PM -0700, Doug McNutt wrote:
: I have been a lurker since early November. Dan S. suggested I get over
: here when I wrote a piece on the summary list describing my feelings
: about vector operations in perl 6. My information was based on the
: recent O'Reilly book an
On Fri, Jan 23, 2004 at 01:54:21PM -0800, Dave Whipp wrote:
: When I see these long squiggles of line noise, I can't help thinking that
: English might be a better alternative. Using Larry's terminology from a few
: posts ago, we might think of:
:
: @a \C[leach] + \C[reach] @b
:
: Not mnemonic
I have been a lurker since early November. Dan S. suggested I get over here when I
wrote a piece on the summary list describing my feelings about vector operations in
perl 6. My information was based on the recent O'Reilly book and I had to confess that
I have never in my life opened a CVS file.
When I see these long squiggles of line noise, I can't help thinking that
English might be a better alternative. Using Larry's terminology from a few
posts ago, we might think of:
@a \C[leach] + \C[reach] @b
Not mnemonic in a visual sense, but extendable to all sorts of trigraph
contexts. Indee
Larry Wall writes:
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
> : Larry Wall writes:
> : > On the other hand, we've renamed all the
> : > other bitwise operators, so maybe we should rename these too:
> : >
> : > + : > +>bitwi
On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > On the other hand, we've renamed all the
: > other bitwise operators, so maybe we should rename these too:
: >
: > +< bitwise left shift
: > +> bitwise right shift
:
: I could h
Larry Wall writes:
> On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote:
> :I just realized a potential flaw here. Consider the code
> : $a >>= 1;
> :
> :Will this right-shift the value of $a one bit and assign the result to $a
> : (the current meaning)? Or will it assig
Luke Palmer <[EMAIL PROTECTED]> writes:
> @A »+« @B # One-at-a-time
> @A «+» @B # Outer product
>
> Or something. Hmm, then both:
>
> @A »+ $b
> @A «+ $b
There is a page you may find inspiring:
http://www.ritsumei.ac.jp/~akitaoka/index-e.html
Sorry, I could n
On Thu, Jan 22, 2004 at 08:08:13PM -0500, Joe Gottman wrote:
:I just realized a potential flaw here. Consider the code
: $a >>= 1;
:
:Will this right-shift the value of $a one bit and assign the result to $a
: (the current meaning)? Or will it assign the value 1 to each element i
- Original Message -
From: "Luke Palmer" <[EMAIL PROTECTED]>
To: "Austin Hastings" <[EMAIL PROTECTED]>
Cc: "Larry Wall" <[EMAIL PROTECTED]>; "Language List" <[EMAIL PROTECTED]>
Sent: Thursday, January 22, 2004 4:28 PM
Subjec
On Thu, Jan 22, 2004 at 01:34:33PM -0600, Jonathan Scott Duff wrote:
: On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote:
: > Me? I handle it by making it an adverb on the base operator. :-)
:
: Does that mean it should get the colon? :)
Only if all adverbs in English end in -ly.
Of
On Thu, Jan 22, 2004 at 02:28:09PM -0700, Luke Palmer wrote:
: Well, for being called "vector operators", they're ending up pretty
: useless as far as working with mathematical vectors.
Which is why I suggested calling them distributors or some such.
: As a
: mathematician, I'd want:
:
: @ve
On Thu, Jan 22, 2004 at 01:28:42PM -0500, Austin Hastings wrote:
> > From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> > On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > > In reverse order:
> > >
> > > > %languageometer.values ?+= rand;
> > >
> > > This is the same as
>
On Thu, Jan 22, 2004 at 11:25:41AM -0800, Larry Wall wrote:
> On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote:
> : > -Original Message-
> : > From: Larry Wall [mailto:[EMAIL PROTECTED]
> : > I think some people will want to think of it one way, while others
> : > will want t
Luke Palmer writes:
> > (1,2,3,4,5) +Â foo() # Maybe the same as above? What does
> > infix:+(@list,$scalar) do?
>
> Well, what does a list return in scalar context? In the presence of the
> C comma, it returns 5 for the last thing evaluated. In its absence, it
> returns 5 for the lengt
Austin Hastings writes:
> > Sortof. I think Larry was implying that rand returned an infinite list
> > of random numbers in list context. If not, then what he said was wrong,
> > because it would be sick to say that:
> >
> > (1,2,3,4,5) Â+Â foo()
> >
> > Calls foo() 5 times.
>
> Why would
> -Original Message-
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 3:52 PM
> To: Austin Hastings; Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> Jonathan Scott Duff writes:
> > On T
Austin Hastings writes:
> How do you handle operator precedence/associativity?
>
> That is,
>
>$a + $b + $c
>
> If you're going to vectorize, and combine, then you'll want to group. I
> think making the vectorizer a grouper as well kills two birds with one
> stone.
>
> $a + >>$b + $c<<
>
* Larry Wall <[EMAIL PROTECTED]> [2004-01-22 18:40]:
> You might argue that we should force people to think of it one
> way or the other.
I wouldn't, because if I did I'd should've been talking to Guido
rather than you in the first place. :-)
And because I'm talking to you, I'll wonder whether ma
Jonathan Scott Duff writes:
> On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> > In reverse order:
> >
> > > %languageometer.values Â+= rand;
> >
> > This is the same as
> >
> > all( %languageometer.values ) += rand;
> >
> > right?
Well, yes. It's also the same as e
On Thu, Jan 22, 2004 at 01:10:25PM -0500, Austin Hastings wrote:
: > -Original Message-
: > From: Larry Wall [mailto:[EMAIL PROTECTED]
: > I think some people will want to think of it one way, while others
: > will want to think of it the other way. If that's the case, the
: > proper place
On Thu, Jan 22, 2004 at 01:10:23PM -0500, Austin Hastings wrote:
> In reverse order:
>
> > %languageometer.values ?+= rand;
>
> This is the same as
>
> all( %languageometer.values ) += rand;
>
> right?
It's the same as
$r = rand;
$_ += $r for %languageometer.values
> -Original Message-
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 1:16 PM
> To: Austin Hastings
> Cc: Larry Wall; Language List
> Subject: Re: Semantics of vector operations (Damian)
>
>
> On Thu, Jan 22, 2004
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 12:39 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote:
> : Good
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 12:50 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote:
> : * Piers Cawle
On Thu, Jan 22, 2004 at 03:57:26AM +0100, A. Pagaltzis wrote:
: * Piers Cawley <[EMAIL PROTECTED]> [2004-01-21 23:33]:
: > And once you go to an image based IDE and have access to the
: > bytecode of the code you're writing there's all *sorts* of
: > interesting things you can do. And that's before
On Thu, Jan 22, 2004 at 03:53:04AM +0100, A. Pagaltzis wrote:
: Good point; however, this means different way to think of the
: vector ops than we had so far. Basically, we're moving from the
: realm of vector ops to that of vectorized operands.
:
: In light of this, I think Austin's proposal of m
Gah. Not a good combination do heavy editing and insufficient
proofreading make.
* A. Pagaltzis <[EMAIL PROTECTED]> [2004-01-22 03:55]:
> Good point; however, this means
a
> different way to think of the vector ops than we had so far.
> Basically, we're moving from the realm of vector ops to that
* Piers Cawley <[EMAIL PROTECTED]> [2004-01-21 23:33]:
> And once you go to an image based IDE and have access to the
> bytecode of the code you're writing there's all *sorts* of
> interesting things you can do. And that's before one starts to
> imagine attaching the IDE/debugger to a running proce
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 20:35]:
> On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
> > It seems to me that this is too big a semantic choice to make
> > merely by omission of a single (and quite dainty) character.
> > I'd rather express this by forcing a context on
On Wed, Jan 21, 2004 at 04:01:43PM -0500, Austin Hastings wrote:
> Perhaps the right way to vectorize the arguments is to delimit them with
> vectorization markers?
>
> @a + >>$b<<
or @a + @$b even!
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> This would be relatively straightforward for syntax highlighters,
> LW> I think. But Perl 6 will throw other curves at highlighters that
> LW> will be much more difficult to solve, such as
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 21, 2004 2:33 PM
> To: Language List
> Subject: Re: Semantics of vector operations
>
>
> On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
> : That said, I&
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> This would be relatively straightforward for syntax highlighters,
LW> I think. But Perl 6 will throw other curves at highlighters that
LW> will be much more difficult to solve, such as the fact that any
LW> C potentially changes the
On Wed, Jan 21, 2004 at 03:21:01PM +0100, A. Pagaltzis wrote:
: That said, I'm not sure how keen I am on the idea of "one-sided"
: vector operators. It seems to me that this is too big a
: semantic choice to make merely by omission of a single (and quite
: dainty) character. I'd rather express this
On Tue, Jan 20, 2004 at 11:06:13PM -0500, Austin Hastings wrote:
: If only from a syntax-highlighting point of view, this is a horrible
: proposal. Make it die.
This would be relatively straightforward for syntax highlighters,
I think. But Perl 6 will throw other curves at highlighters that
will
* Larry Wall <[EMAIL PROTECTED]> [2004-01-21 01:44]:
> Note that if we do take this approach, we'll have to require the
> space after = in
>
> @list = «a b c d e»;
This shouldn't be a problem. The whitespace rule changes I
believe should be avoided (Abigail does have a point there) is if
whit
Warning: spacey, tangential semi-argument ahead.
Larry Wall writes:
> On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote:
> : A thought occurred to me. What should this return:
> :
> : [1,2,3] Â+Â [4,5,6]
> :
> : At first glance, one might say [5,7,9]. But is that really the best
Austin Hastings wrote:
> Larry Wall wrote:
> > On the other hand, it's possible that we should extend the visual
> > metaphor of »« and apply it asymmetrically when one of the arguments
> > is expected to be scalar. That would mean that your last three lines
> > would be written:
> >
> > (1,
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On the other hand, it's possible that we should extend the visual metaphor
> of »« and apply it asymmetrically when one of the arguments is expected to
> be scalar. That would mean that your last three lines would be wr
Larry Wall wrote:
> Note that if we do take this approach, we'll have to require the space
> after = in
>
> @list = «a b c d e»;
Perl 6 has already set the precedent of the presence or absence of
whitespace being syntactically important (as opposed to Python, where the
amount and type of whi
On Tue, Jan 20, 2004 at 01:54:33AM -0700, Luke Palmer wrote:
: A thought occurred to me. What should this return:
:
: [1,2,3] »+« [4,5,6]
:
: At first glance, one might say [5,7,9]. But is that really the best
: way to go? I'm beginning to think that it should be the same as
: whatever [1,
98 matches
Mail list logo
