[perl6/specs] 7ed178: [S03] note that $x div $y == floor($x/$y) does not...

2012-04-09 Thread GitHub
paths: M S03-operators.pod Log Message: --- [S03] note that $x div $y == floor($x/$y) does not always hold

[perl6/specs] 7a4e19: Very draft-y, very early S24 - testing

2010-12-30 Thread noreply
: A S24-testing.pod Log Message: --- Very draft-y, very early S24 - testing It is mostly meant as an encouragement for others to fill out the gaps. If you want to do so, and don't have commit access yes, please tell me your github ID.

**{x,y} quantifier

2007-07-01 Thread Amir E. Aharoni
(I'm just studying the intricacies of Perl 6, so please correct me if i say something stupid or if this has already been discussed before.) I was looking for the Perl 6 equivalent of aaa =~ /a{1,3}/ and finally found that it's aaa ~~ /a**{1 .. 3}/ This looked rather weird, so i asked on IRC

Re: **{x,y} quantifier

2007-07-01 Thread Luke Palmer
On 7/1/07, Amir E. Aharoni [EMAIL PROTECTED] wrote: I got the reply that it is similar to exponentiation of variables in math: a ** 5 == a * a * a * a * a == a It makes sense after it is explained and i do like the rationalization of the range as a list-like range, instead of the comma,

Re: **{x,y} quantifier

2007-07-01 Thread Amir E. Aharoni
please correct me if i say something stupid or if this has already been discussed before.) Another important loss if we were to go with 1..3 would be the ability to have runtime-dependent ranges; e.g.: / ($ntimes) x**{$ntimes} / That's exactly what i meant by something stupid. Thanks

Re: **{x,y} quantifier

2007-07-01 Thread Luke Palmer
On 7/1/07, Amir E. Aharoni [EMAIL PROTECTED] wrote: please correct me if i say something stupid or if this has already been discussed before.) Another important loss if we were to go with 1..3 would be the ability to have runtime-dependent ranges; e.g.: / ($ntimes) x**{$ntimes} /

Named captures (was: **{x,y} quantifier)

2007-07-01 Thread Amir E. Aharoni
On 01/07/07, Luke Palmer [EMAIL PROTECTED] wrote: On 7/1/07, Amir E. Aharoni [EMAIL PROTECTED] wrote: please correct me if i say something stupid or if this has already been discussed before.) Another important loss if we were to go with 1..3 would be the ability to have

Re: Named captures (was: **{x,y} quantifier)

2007-07-01 Thread Luke Palmer
On 7/1/07, Amir E. Aharoni [EMAIL PROTECTED] wrote: On 01/07/07, Luke Palmer [EMAIL PROTECTED] wrote: / $ntimes := (\d+) x**{$ntimes} / The examples of := usage in S05 seem to have notation such as this: $ntimes := (\d+) Yes, that is correct. I've been away from the Perl 6

Re: Y not

2007-02-21 Thread Thomas Wittek
Damian Conway schrieb: If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be improved: Say more

Re: Y not

2007-02-21 Thread Luke Palmer
On 2/21/07, Thomas Wittek [EMAIL PROTECTED] wrote: Damian Conway schrieb: If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Fully agree here and I think that there are still even more places,

Re: Y not

2007-02-21 Thread Mark A. Biggar
Thomas Wittek wrote: Damian Conway schrieb: If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be

Y not

2007-02-21 Thread Jonathan Lang
Luke Palmer wrote: % as the mod operator is a good example of what you describe. There's no need for mod to be a symbolic operator: when you read 5 % 3 you say 5 mod 3. Why would we not write 5 mod 3: it is just as obvious what and how we are doing this operation. And % is uncommon enough that

Re: Y not

2007-02-21 Thread Uri Guttman
DC == Damian Conway [EMAIL PROTECTED] writes: DC On 21/02/07, Damian Conway [EMAIL PROTECTED] wrote: [Off-list] DC Apparently not. DC Just pretend I'm not here. DC ;-) we can't pretend as we can sense your mad scientist brain across the big waters. there ain't enough aluminum foil

Y not

2007-02-20 Thread Larry Wall
I think the ¥ and Y operators are going to have to change to something else. The current Y has at least four strikes against it: * It's an ASCII version of a cute Unicode picture, but other than that, the picture it doesn't remind you of zip at all, especially in the Y form

Re: Y not

2007-02-20 Thread chromatic
On Tuesday 20 February 2007 12:42, Larry Wall wrote: 'Course, if someone goes ahead and adds the Y combinator, one must naturally begin to wonder what the YY combinator would be...  :-) Obviously it generates a function so anonymous that it can't even refer to itself. I call it the depressed

Re: Y not

2007-02-20 Thread Thomas Wittek
Larry Wall schrieb: I think the ¥ and Y operators are going to have to change to something else. Very probably I missed something as I'm only a distant observer of the Perl6 development: Why not just call it zip?! There is a function called zip, wouldn't it be possible to create an operator

Re: Y not

2007-02-20 Thread Jonathan Lang
Thomas Wittek wrote: Larry Wall schrieb: I think the ¥ and Y operators are going to have to change to something else. Very probably I missed something as I'm only a distant observer of the Perl6 development: Why not just call it zip?! There is a function called zip, wouldn't it be possible

Re: Y not

2007-02-20 Thread Larry Wall
On Wed, Feb 21, 2007 at 12:49:20AM +0100, Thomas Wittek wrote: : Larry Wall schrieb: : I think the ¥ and Y operators are going to have to change to something else. : : Very probably I missed something as I'm only a distant observer of the : Perl6 development: Why not just call it zip

Re: Y not

2007-02-20 Thread Joe Gottman
Larry Wall wrote: Hmm, but then what corresponds to XX? I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c - zip operator ZZ(@a; @b; @c) - zip function @a XX @b XX @c - cross operator

Re: Y not

2007-02-20 Thread Damian Conway
On 21/02/07, Damian Conway [EMAIL PROTECTED] wrote: [Off-list] Apparently not. Just pretend I'm not here. ;-) Damian

Re: Y not

2007-02-20 Thread Jonathan Lang
Damian Conway wrote: I'd be more inclined to go the other way and say that you can transform any list infix form to the corresponding function form: @a ZZ @b ZZ @c - zip operator ZZ(@a; @b; @c) - zip function @a XX @b XX @c - cross operator XX(@a; @b; @c) - cross

Re: Y [was: Re: new sigil]

2005-10-21 Thread Rutger Vos
Speaking of which the advantage of, say, « over is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Do

Re: Y [was: Re: new sigil]

2005-10-21 Thread Michele Dondi
On Thu, 20 Oct 2005, Rutger Vos wrote: _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Do you even need to ask? It's

Re: Y [was: Re: new sigil]

2005-10-21 Thread Mark Reed
Speaking of which, the advantage of, say, « over is that the former is _one_ character. But Y, compared to ¥, is one character only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? I can't

Y [was: Re: new sigil]

2005-10-20 Thread Michele Dondi
On Thu, 20 Oct 2005, Juerd wrote: All non-ASCII operators have ASCII equivalents: ¥ Y « » Speaking of which the advantage of, say, « over is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-31 Thread John BEPPU
[ date ] 2001/03/30 | Friday | 11:16 PM [ author ] John Porter [EMAIL PROTECTED] Russ Allbery wrote: gcc and the literature both use "pure"; I'd recommend that. John Porter wrote: I like pure too, but I'm afraid the nuance of it will be completely lost on non-Functional programmers. not

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-31 Thread Russ Allbery
Frank Tobin [EMAIL PROTECTED] writes: Just because one programming paradigm happens to name it "pure" doesn't mean that name should be carried over to other paradigms. In a functional-programming context, sure, "pure" might be a good name. But in a non-functional context, the name has

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-31 Thread Paul Johnson
On Sat, Mar 31, 2001 at 02:01:39PM -0600, Frank Tobin wrote: John BEPPU, at 12:50 -0700 on Sat, 31 Mar 2001, wrote: I like pure too, but I'm afraid the nuance of it will be completely lost on non-Functional programmers. not to worry... If anything, it might educate them. I

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-31 Thread John Porter
Frank Tobin wrote: While the term "pure", surely can be deemed "correct" in the context of functional programming, it cannot in standard Perl programming. considering context in which most Perl is written, "pure" has no meaning, and hence I wouldn't consider it "correct". No, "pure

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-31 Thread John Porter
Russ Allbery wrote: It looks like I was misremembering; I remember a proposal for a "pure" attribute in gcc, but it looks like the attribute used for functions with no memory references and no side effects is "const" (a la C++). I think "pure" was proposed for the somewhat relaxed version

RE: pitching names for the attribute for a function with no memor y or side effects

2001-03-30 Thread Dan Sugalski
At 03:30 PM 3/30/2001 -0600, Garrett Goebel wrote: From: John Porter [mailto:[EMAIL PROTECTED]] Dan Sugalski wrote: :contained. Or possibly :irrelevant, since generally speaking most people won't use it and the optimizer will have to infer whether it's safe to not execute the

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-30 Thread Russ Allbery
Dan Sugalski [EMAIL PROTECTED] writes: Doesn't have the right ring to it, unfortunately. It's not really immutable, it just has no side-effects. gcc and the literature both use "pure"; I'd recommend that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/

Re: pitching names for the attribute for a function with no memor y or side effects

2001-03-30 Thread John Porter
Russ Allbery wrote: gcc and the literature both use "pure"; I'd recommend that. Excellent! So I wasn't pulling it out of... thin air. :-) I like pure too, but I'm afraid the nuance of it will be completely lost on non-Functional programmers. -- John Porter Like music? Then you're gonna