On Fri, Nov 01, 2002 at 02:40:08AM +0200, [EMAIL PROTECTED] wrote:
>
> for @a -> $x, $y { ... $x is topic ... }
>
> for @a ; @b ->
> $x, $y ; $z { ... WHAT is topic ? ... }
>
> what is topic in multi stream loop ?
Always the first, so $x in both. Unless you specify otherwise:
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 22:36:58 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-Accept-Language: en,pdf
> Cc: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Larry Wall wrote:
> > Please don't think
Larry Wall wrote:
> Please don't think of C as a boolean type. There is no boolean
> type in Perl, only a boolean context. Or looking at it from the
> other direction, *every* type is a boolean type.
Er... dang. While I certainly agree with the concept in principle, I'm
having a hard time stick
On Thu, 2002-10-31 at 12:15, Larry Wall wrote:
> On 31 Oct 2002, brian wheeler wrote:
> : I agree considering, this isn't APL and the problems people have had
> : mailing examples (let alone creating them!).
>
> Nevertheless, it has already been decreed that Perl 6 programs are
> written in Unicod
Larry wrote:
> I don't much care whether they short-circuit or not. I could argue it
> either way. I think it'd be okay if they short-circuit. Anybody who
> uses an operator like ?& expecting it to force a side effect on the
> second expression is nuts. And there's something (though not much)
* Larry Wall ([EMAIL PROTECTED]) [01 Nov 2002 15:59]:
[...]
> I was misconfigured here. My pine was marking it as UTF-8 even though
> the window was Latin-1. So you ought to be able to see this: @a «*» @b.
That appeared perfectly.
> I'm definitely going to look into mutt though...gotta have Unic
On Fri, 1 Nov 2002, Iain 'Spoon' Truskett wrote:
: > This is currently running in a window that does Latin-1 rather than
: > UTF-8. Do these French quotes come through?
:
: > @a «+» @b
:
: The window may say Latin-1, but the mail header said UTF-8.
:
: As it happens, I couldn't see them unt
* Larry Wall ([EMAIL PROTECTED]) [31 Oct 2002 08:22]:
[...]
> This is currently running in a window that does Latin-1 rather than
> UTF-8. Do these French quotes come through?
> @a «+» @b
The window may say Latin-1, but the mail header said UTF-8.
As it happens, I couldn't see them until I
On Thu, 31 Oct 2002, Dave Storrs wrote:
: On Wed, 30 Oct 2002, Larry Wall wrote:
:
: > If no one saw them then it could well be a problem on my end.
: > I'm trying to use a mailer (pine) that doesn't know about UTF-8 in
: >
: > @a «+» @b
:
: I'm using Pine 4.33 on FreeBSD 4.3, and I see
On Fri, 1 Nov 2002, Damian Conway wrote:
: Austin Hastings wrote:
:
: > In the C that I learned, the &^| ops were bitwise.
: >
: > Likewise, the && || ops were lazy booleans.
: >
: > So what's a single-letter boolean act like? Is it lazy? Does it retain
: > its bitwise-ness but (since boolean) f
On Wed, 30 Oct 2002, Larry Wall wrote:
> If no one saw them then it could well be a problem on my end.
> I'm trying to use a mailer (pine) that doesn't know about UTF-8 in
>
> @a «+» @b
I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine.
--Dks
On Thu, 31 Oct 2002, Michael Lazzaro wrote:
: While writing documentation: a trivial question on the boolean type,
: C:
Please don't think of C as a boolean type. There is no boolean
type in Perl, only a boolean context. Or looking at it from the
other direction, *every* type is a boolean type.
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote:
: Erik Steven Harrison writes:
: >
: >
: > All that said, can anyone come up with a case to
: > confuse with <$File_Handle>?
: >
: >
:
: it seems that parser cannot confuse them because is operator and
: parser expect operator, while <$File_
On Thu, 31 Oct 2002, David Wheeler wrote:
: On Thursday, October 31, 2002, at 02:43 PM, Michael Lazzaro wrote:
:
: > Q: Can bits/bools be undefined?
: >
: > Perl conventions would indicate yes.
:
: IIRC, native data types, which are all lowercase (e.g., int, bit, long,
: etc.) cannot be undef.
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote:
: does it mean that *all* postfix operators have to be "attached"
: without space to their operand or used with space eater modifyer
:
: or
:
: only those for which parser ( or we ) knows that they may be confused
: with binary op or term ?
I think
I've banged together a first attempt at a miniparrot- that is, something
that can be built on any ANSI C system without anything other than a
compiler.
Right now, as a proof of concept, it's building a source tree and a shell
script which would build miniparrot under gcc. A real version woul
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Fri, 1 Nov 2002 03:08:37 +
> From: Andrew Wilson <[EMAIL PROTECTED]>
> Mail-Followup-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> On Fri
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
> Austin Hastings wrote:
>> traits = any ( ... )
>> requirements = .. & ..
>> if $requirements eq $traits
>>
>> Should that be traits = all()?
>
> No. Because later we say (effectively):
>
> print "True love\n"
> if a
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
> Damian Conway writes:
>> BTW, Both Larry and I do understand the appeal of interleaving
>> sources and iterators. We did consider it at some length back
>> in January, when we spent a week thrashing this syntax out.
>>
>> Of course, I can't speak for
> actually , ones we decide that ^ *is necessary for vectorization , we
> can allow other brackets , optional brackets ( where unambiguous ) ,
> and spaces inside the brackets :
>
> @a ^+= @b
> @a ^[+]= @b
> @a ^(+)= @b
> @a ^( + )= @b
> @a ^{ + }= @b
> @a ^{+}= @b
> @a ^[ + ]= @b
>
rig
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett
wrote:
(Whine: my Perl undergrad students are too young to remember or
appreciate text adventures. At least some of you oldsters here will
understand.)
Hey! We're not old, we're just version 1.0!
Can we have a "grue" operator
> > get guillemot
> Taken.
Extra credit for those of you who remembered that that's a bird, not a
punctuation mark.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel?" "Ariel, her name is
Markus Laire:
# Emacs and vim also works on Windows, not just UNIX.
So does DOS 'edit'. That doesn't mean Windows users use it. Windows
users want tools that look and act like Windows tools--if they didn't,
they'd be using another OS. Neither GNU emacs nor xemacs fits the bill,
and I doubt vim
> > On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
> > > ... using backtick in vector operators ... A pair of backticks could
> > > be used if the vector-equals distinction is required:
> > > @a `+`= @b;
> > > @a `+=` @b;
> > Thats ugly, IMO.
> Oh, I wasn't claiming that it'
> Date: Thu, 31 Oct 2002 15:16:17 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
>
> --- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > > > Austin Hastings wrote:
> >
for @a -> $x, $y { ... $x is topic ... }
for @a ; @b ->
$x, $y ; $z { ... WHAT is topic ? ... }
what is topic in multi stream loop ?
arcadi
Oops. About that thing, I was wrong. Though there is a case
that does it:
sub bar();
sub postfix:bar($x) returns IO::Handle;
$x = length ;
If it's possible to have a distinct sub and an operator with the same
name. If not, I believe the distinction is precisely the same as that
of
Larry Wall writes:
>
> sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) ! }
>
> which could be fixed with the _:
>
> sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) _! }
>
> Weird, but it's all consistent with the distinction we're already
> making on curlies, whic
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > > Austin Hastings wrote:
> > > > traits = any ( ... )
> > > > requirements = .. & ..
> > > > if $requirements eq $traits
> > > >
> > > > Should that be traits = all()?
> > >
> > > No. Because later we
On 31 Oct 2002 at 15:59, Mark J. Reed wrote:
> Once you wander away from Latin-1 into the more general world
> of Unicode, you start running into trouble on the input side.
> On Windows you pretty much have to use the Character map accessory.
> Emacs and vim still work on UNIX, but I don't know of
On Thursday, October 31, 2002, at 02:43 PM, Michael Lazzaro wrote:
Q: Can bits/bools be undefined?
Perl conventions would indicate yes.
IIRC, native data types, which are all lowercase (e.g., int, bit, long,
etc.) cannot be undef. However, their class equivalents (e.g., Int,
Bit, Long, etc)
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 14:45:16 -0800
> From: "Erik Steven Harrison" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> X-Sent-Mail: off
> Reply-To: [EMAIL PROTECTED]
> X-Sender-Ip: 152.18.50.63
> Organization: Angelfire (http://email.angelfire.
* Ed Peschko ([EMAIL PROTECTED]) [01 Nov 2002 07:19]:
[...]
> for @a -> $a_variable1 is rw, $a_variable2 is rw;
> @b -> $b_variable is rw;
> @c -> $c_variable is rw;
> @d -> $d_variable is rw;
> @e -> $e_variable1 is rw, $e_variable2 is rw;
> {
> }
> is much, *much* cle
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse with <$File_Handle>?
If you assume infinite lookahead, it's fine, but if not...
...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:
Erik Steven Harrison writes:
>
>
> All that said, can anyone come up with a case to
> confuse with <$File_Handle>?
>
>
it seems that parser cannot confuse them because is operator and
parser expect operator, while <$File_Handle> is a term .
but human can confuse .
I personally also
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 14:07:34 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
>
> --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > Austi
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
>I can honestly say at this point that I'd rather give up <$iterator>
>than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is ever going to be
confused for <$File_Handle>? The vector operation co
While writing documentation: a trivial question on the boolean type,
C:
my bit $light_switch;
Q: Can bits/bools be undefined?
Perl conventions would indicate yes. Does that mean that an array of
bits:
my bit @bitfield;
takes up, at minimum, two bits per, um, bit?
Sorry if this ques
[EMAIL PROTECTED] writes:
> 1) for @a -> $x ; @b -> $y { ... }
>
> ===>>>
>
> 2) for @a ; @b -> $x ; $y { ... }
You've got it! Semicolon naturally breaks things apart, not groups them
together!
--
Anything to do with HTML processing /usually/ involves a pact
with an evil super
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
> > traits = any ( ... )
> > requirements = .. & ..
> > if $requirements eq $traits
> >
> > Should that be traits = all()?
>
> No. Because later we say (effectively):
>
> print "True love\n"
> if all(@desidera
Me writes:
> > > A ^ prefix visually interferes a lot more
> >
> > I know it clutters up things a bit, that's my very argument; that
> > ^[ ] clutters up things even *more*. especially, with use of arrays:
> >
> > @array[1,2,3] ^[+=] @array[4,5,6];
> >
> > bleah.
> >
> > @array[1,2,3
> Maybe. I slightly prefer the first line right now.
> But it's close, and I think I've gotten too used to
> both notations to know what I'd think if I saw one
> or other for the first time, and I don't know what
> I'd think after a month of use of one or other. As
> I said, it's close. This will
Graham Barr wrote:
> On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
>
> > ... using backtick in vector operators ... A pair of backticks could
> > be used if the vector-equals distinction is required:
> >
> > @a `+`= @b;
> > @a `+=` @b;
>
> Thats ugly, IMO.
Oh, I wasn't
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > And if you really want to drool at all the neat glyphs that the
> > wonderful, magical world of math has given us, check out:
> >
> > http://www.unicode.org/charts/PDF/U2A00.pdf
> >
> > now *theres* some brackets!
>
> Ooh! Let's use 2AF
Damian Conway writes:
>
> BTW, Both Larry and I do understand the appeal of interleaving
> sources and iterators. We did consider it at some length back
> in January, when we spent a week thrashing this syntax out.
>
> Of course, I can't speak for Larry, but in the end I concluded
> that i
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Oct 2002, Markus Laire wrote:
> The really great thing about the French quotes is that they visually
> keep the user aware of the composition. «+=» is obviously a variety
> of
> +=, whereas ^+= is not obvious, though shorter. (Square bracke
On Thursday, October 31, 2002, at 12:18 PM, Chip Salzenberg wrote:
According to Michael Lazzaro:
?? ?? ?? ??? ??? ??? ??? ??? ???
??? ??? ??? ??? ??? ??? ??? ??? ???
??? ???
??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ???
Am I the only person who discovered Korean spam
On 2002-10-31 at 12:45:23, David Wheeler wrote:
> Plus, it turns out not to be at all hard to type on Mac OS X. ;-)
Well, the angle quotes happen to fall within Latin-1, and so they're
easier to get to. On Windows you can either set up special key mappings or
just type ALT+171 for « and ALT+187 fo
Austin Hastings wrote:
In the C that I learned, the &^| ops were bitwise.
Likewise, the && || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the "
Ed Peschko wrote:
Larry Wall writes:
I think decent formatting would make it clearer:
for@a; @b
-> $x is rw; y {
$x = $y[5];
}
But this isn't very scalable:
Sure it is. You just have to think more two-dimensionally...
for @a; @b; @c; @d; @e
-> $a_variabl
On Thursday, October 31, 2002, at 11:36 AM, Me wrote:
A ^ prefix visually interferes a lot more with the op being
hypered. I didn't understand that until I first saw use of
square brackets (interestingly, use of angle brackets
didn't grab my attention, though that may have been
due to other fact
On Tue, 29 Oct 2002, Andy Dougherty wrote:
> On Tue, 29 Oct 2002, Andy Dougherty wrote:
>
> > Here's my proposal for stage one: This patch is intended to define
> > explicitly what the different compiler and linker commands and flags
> > are, what they are supposed to mean, and how they are to b
According to Michael Lazzaro:
>?? ?? ?? ??? ??? ??? ??? ??? ???
>??? ??? ??? ??? ??? ??? ??? ??? ???
>??? ???
>??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ???
Am I the only person who discovered Korean spam on p6-lang?
--
Chip Salzenberg - a.k.a. -<[EM
Larry Wall writes:
> I think decent formatting would make it clearer:
>
> for@a; @b
> -> $x is rw; y {
>$x = $y[5];
> }
But this isn't very scalable:
for@a; @b;
@c; @d;
> > A ^ prefix visually interferes a lot more
>
> I know it clutters up things a bit, that's my very argument; that
> ^[ ] clutters up things even *more*. especially, with use of arrays:
>
> @array[1,2,3] ^[+=] @array[4,5,6];
>
> bleah.
>
> @array[1,2,3] ^+= @array[4,5,6];
>
> Not much of a i
Here is more to think about. No freaking out, this is just for
mulling...
If we, for the moment, assume the use of «op» for hypers, that
obviously raises the _possibility_ of using some other Unicode/UTF-8
characters for other "very special" tasks. I'm not actually advocating
most of these (
On Thu, Oct 31, 2002 at 01:36:20PM -0600, Me wrote:
> > > 1) Need a definite syntax for hypers
> > > ^[op] and <>
> > > have been most seriously proposed -- something that keeps a
> > > bracketed syntax, but solves ambiguity issues.
> >
> > hm. What was wrong with just '^' again?
>
> Right. I d
> > 1) Need a definite syntax for hypers
> > ^[op] and <>
> > have been most seriously proposed -- something that keeps a
> > bracketed syntax, but solves ambiguity issues.
>
> hm. What was wrong with just '^' again?
Right. I didn't have a problem with ^ in the first place.
But...
A ^ prefix
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 11:13:28 -0800
> From: Ed Peschko <[EMAIL PROTECTED]>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Michael Lazarro wrote:
>
> > 1) Need a definite syntax for hypers
>
> temp sub infix:^[] is force_hash_to_intersect ;
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
Michael Lazarro wrote:
> 1) Need a definite syntax for hypers
>^[op] and <>
> have been most seriously proposed -- something that keeps a
> bracketed syntax, but solves ambiguity issues.
hm. What was wrong with just '^' again? Reading the threads, it seems to have
gotten lost in the sh
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 31 Oct 2002 10:11:00 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
>
> And if you really want to drool at all the neat glyphs that the
> wonderful, magical worl
Larry Wall:
# Perl 6 is written in Unicode.
Great. That's a wonderful policy. But it *shouldn't influence routine
coding in any way*. I have no problem with user-defined Unicode
operators. I have a *huge* problem with built-in Unicode operators, and
a gargantuan problem with built-in Unicode o
Me writes:
> > > > > union:
> > > > > intersection :
> > > >
> > > > %a ^is strict_keys;
> > > > %b ^is no_strict_keys;
> >
> > in the resulting hash only ( and all ) keys of %a will be present.
> > because %b *admits* unknown keys but %a does not.
>
> Yes, but the general case
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When you're doing +, it's obvi
And if you really want to drool at all the neat glyphs that the
wonderful, magical world of math has given us, check out:
http://www.unicode.org/charts/PDF/U2A00.pdf
now *theres* some brackets!
MikeL
Michael Lazzaro writes:
> OK, by my count -- after editing to reflect Larry's notes -- only a few
> issues remain before the ops list can be completed.
>
>
>
> 1) Need a definitive syntax for hypers,
> ^[op] and «op»
> have been most seriously proposed -- something that k
> Thats ugly, IMO.
>
> Now this is going to sound wild (probably) and I have not thought too much
> about it and there are probably others who can see the pitfalls quicker
> then me. But could () be available for hyper operators ?
>
> I will sit back now and watch the firewaorks, as I wont
Larry Wall writes:
> On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
> : %a ^[op]= @b # hash v array
> : @a ^[op]= %b # array v hash
>
> What would those mean? Are you thinking only of hashes with numeric keys?
>
> Larry
>
>
>
no but hash can have property that tells how to
Larry Wall writes:
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When
Me writes:
> > > union:
> > > intersection :
> >
> > How would this work for hashes with differing properties?
> >
> > %a ^is strict_keys;
> > %b ^is no_strict_keys;
> >
> > What would happen?
>
in the resulting hash only ( and all ) keys of %a will be present.
because %b *admits*
Austin Hastings writes:
> > but I am not shure ...
>
> "sure"
>
thanks . sorry that I write so badly . I'll try to be better .
> (Unless you do this on purpose :-)
>
> Cheers,
>
> =Austin
>
> __
> Do you Yahoo!?
> HotJobs - Searc
Austin Hastings writes:
>
> --- [EMAIL PROTECTED] wrote:
> > I agree. But I think that we can get away here with just hash
> > properties , just like hash behaviour in is controlled by
> > properties .
> >
> > e.g.
> > union:
> >
> > (%a,%b) ^is no_strict_keys ;
> > (%a %b) ^is de
On Thu, 31 Oct 2002, Markus Laire wrote:
: I don't think there should be any upper limit for operator-lengths.
There will never be any official limits. Perl is not about arbitrary
limits. But I will tell you that I only added <=> to Perl 5 because
I knew there would never be a <=>= operator. We
On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote:
: To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still
Thanks, I didn't know it was that «easy» in vim. :-)
: typing an awful lot just to get a character. Surely the Perl operator
: Huffman encoding should take into account the le
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
: %a ^[op]= @b # hash v array
: @a ^[op]= %b # array v hash
What would those mean? Are you thinking only of hashes with numeric keys?
Larry
Here is an extensive FAQ for Unicode and UTF-8:
http://www.cl.cam.ac.uk/~mgk25/unicode.html
and here is a test file that will show you how many of the "most common
glyphs" (WGL4, via Microsoft) you are capable of displaying in your
current setup:
http://www.cl.cam.ac.uk/~mgk25/ucs/wgl
On Thu, 31 Oct 2002, Graham Barr wrote:
: On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
: > A pair of backticks could be used if the vector-equals distinction is
: > required:
: >
: > @a `+`= @b;
: > @a `+=` @b;
:
: Thats ugly, IMO.
:
: Now this is going to sound wild (p
On Thu, 31 Oct 2002, Me wrote:
: That's one reason why I suggested control of this sort
: of thing should be a property of the operation, not of
: the operands.
I think that by and large, the operator knows whether it wants to
do union or intersection. When you're doing «+», it's obviously
union
On 31 Oct 2002, brian wheeler wrote:
: I agree considering, this isn't APL and the problems people have had
: mailing examples (let alone creating them!).
Nevertheless, it has already been decreed that Perl 6 programs are
written in Unicode. That's not gonna change...
: I've got to admit all of
On Thu, 31 Oct 2002, Austin Hastings wrote:
: Damian Conway admits: "Everything in Perl6 is 'Junk'"
:
: Who can't see *this* coming on slashdot? :-)
Cool. Perl 6 "junk" gives new meaning to "Pathologically Eclectic Rubbish".
Larry
On Thu, 2002-10-31 at 04:02, Iain 'Spoon' Truskett wrote:
> * Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]:
>
> [...]
> > You could use the Character Map accessory to put
> > the character into the clipboard, or
> > press the alt and hold the alt key while typing 0171 (or 0187)
> > < alt+01
> -Original Message-
> From: Leopold Toetsch [mailto:lt@;toetsch.at]
>
> WRT your comment: "should we use a List * here", I slightly vote for
> yes. In the long run we could use List as the basic store for registers
> and stacks as well.
> List would only need a small extension to manage ar
> > union:
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> What would happen?
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ra
On Wednesday, October 30, 2002, at 01:52 PM, Michael Lazzaro wrote:
Applications/Utilities/"Key Caps" (Again, OSX) which shows you where
they all are.
The «» quotes, for example, are option-\ and shift-option-\
Oh, well, I guess those aren't *too* far out of the way...
David
--
David Wheele
--- [EMAIL PROTECTED] wrote:
> I agree. But I think that we can get away here with just hash
> properties , just like hash behaviour in is controlled by
> properties .
>
> e.g.
> union:
>
> (%a,%b) ^is no_strict_keys ;
> (%a %b) ^is default_value ( 0 ) ;
> %a ^[+] %b
>
> intersection :
>
--- [EMAIL PROTECTED] wrote:
> Yesterday Aaron Crane wrote:
>
> > Jonathan Scott Duff writes:
> >
> > > @a `+ @b
> >
> > In my experience, many people actually don't get the backtick
> > character at all.
>
> Yes. I think that might be a good reason _for_ using backtick in
> vector
> operator
--- Iain 'Spoon' Truskett <[EMAIL PROTECTED]> wrote:
> * Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]:
>
> [...]
> > You could use the Character Map accessory to put
> > the character into the clipboard, or
> > press the alt and hold the alt key while typing 0171 (or 0187)
> > < alt+0171
>
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
> > Possibly we might even extend the notion of hash to any "junk".
> >
> > %hash = 1 | 2 | 3;
>
> So you're suggestion that a "normal" hash is a junction of pairs???
Damian Conway admits: "Everything in Perl6 is 'Junk'"
Who can'
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> >>?& ?| ?^ - [maybe] C-like bool
> operations
> >>?&= ?|= ?^= - (result is always just 1 or
> 0)
> >> [?&][?|][?^] - (hyperversions)
> >> [?&]= [?
--- "Dyck, David" <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Austin Hastings [mailto:austin_hastings@;yahoo.com]
> >
> > How do you write a < in a Windows based environment? (Other than by
> > copying them from Larry's emails or loading MSWord to do
> > insert->symbol)
>
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
> Yesterday Aaron Crane wrote:
>
> > Jonathan Scott Duff writes:
> >
> > > @a `+ @b
> >
> > In my experience, many people actually don't get the backtick
> > character at all.
>
> Yes. I think that might be a good reason _for_
Yesterday Aaron Crane wrote:
> Jonathan Scott Duff writes:
>
> > @a `+ @b
>
> In my experience, many people actually don't get the backtick
> character at all.
Yes. I think that might be a good reason _for_ using backtick in vector
operators:
* Backticks aren't used in any other operators
Me writes:
> > > %a ^:union[op] %b
> > >
> > > %a :foo[op]:bar %b
> >
> > I think that any operators over 10 characters should
> > be banished, and replaced with functions.
>
I agree. But I think that we can get away here with just hash
properties , just like hash behaviour in is
Michael Lazzaro writes:
> OK, by my count -- after editing to reflect Larry's notes -- only a few
> issues remain before the ops list can be completed.
>
>
>
> 1) Need a definitive syntax for hypers,
> ^[op] and «op»
> have been most seriously proposed -- something that k
The packfile contains for string constants the STRING internal field
"flags". This is used for various *internal* purposes, e.g. defining
that a string is external or COWed.
So a badly (i.e. non NULL) set flags field could seriously damage
parrots operation WRT strings.
IMHO, this field doesn't
Uri Guttman writes:
>
> %hash1.values [+]= %hash2{%hash1.keys} ;
>
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the m
* Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]:
[...]
> You could use the Character Map accessory to put
> the character into the clipboard, or
> press the alt and hold the alt key while typing 0171 (or 0187)
> < alt+0171
> > alt+0187
To be honest, as easy as it is to type ^a^v<< or ^k<<,[
On 31 Oct 2002 at 0:40, John Williams wrote:
> On Wed, 30 Oct 2002, Me wrote:
>
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should be banished, and
> replaced with functions.
I don't think there should be any upper limit for operator-
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should
> be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using
1 - 100 of 105 matches
Mail list logo