Re: new sigil
Juerd wrote:
> I do not see why $ and @ couldn't be both a sigil and an infix
> operator, and the same goes for whatever ASCII equivalent ¢ gets.
>
> ^ and | are available for sigil use. (All the closing brackets are too,
> but that would be very confusing because we tend to visually parse those
> in pairs.)
>
> Using the an infix operator's symbol as a sigil is not weird, not wrong,
> not confusing and mostly: not a new idea.
Indeed. Somehow I think this makes some sense:
sub Bool eqv (|T $x, |T $y) { ... }
Thanks,
/Autrijus/
Re: Slightly OT: zip() for Perl5?
Does TYE's Algorithm::Loops's mapcar() provide the basic functionality of what you're looking for? Rob On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote: > Is there a CPAN module which provides the functionality of ¥/zip() for > Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard > to write, of course, just wondering if it's been done . . . > > > >
Re: Zip more than two arrays?
On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote:
> Hm. This brings up another point, which may have been addressed . . .
>
> The Python function and Ruby array method zip() both accept any number of
> arrays to interleave:
>
> >>> zip([1,2,3],[4,5,6],[7,8,9])
> [(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>
> irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9])
> => [[1, 4, 7], [2, 5, 8], [3, 6, 9]]
>
> How would you write the above in Perl6, given that ¥/Y is an infix operator?
Ah, ¥ is not a binary infix operator. Instead, it is what Damian
calls "list-associative". Another such operator is junctive ^, for if
it were binary, it would be an xor, not a one.
As far as the syntax goes, well, we'll have to make some up.
sub listfix:<¥> (Array [EMAIL PROTECTED]) {...}
sub infix:<¥> is assoc('list') (Array [EMAIL PROTECTED]) {...}
Or something like that.
However, if I get my wish of having zip return tuples, then it can be
left-associative. But since it interleaves instead, making it left-
or right-associative gives strange, incorrect results.
Luke
Zip more than two arrays?
Hm. This brings up another point, which may have been addressed . . . The Python function and Ruby array method zip() both accept any number of arrays to interleave: >>> zip([1,2,3],[4,5,6],[7,8,9]) [(1, 4, 7), (2, 5, 8), (3, 6, 9)] irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9]) => [[1, 4, 7], [2, 5, 8], [3, 6, 9]] How would you write the above in Perl6, given that ¥/Y is an infix operator? On 2005-10-21 5:32 PM, "Mark Reed" <[EMAIL PROTECTED]> wrote: > Is there a CPAN module which provides the functionality of ¥/zip() for > Perl5?
Slightly OT: zip() for Perl5?
Is there a CPAN module which provides the functionality of ¥/zip() for Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard to write, of course, just wondering if it's been done . . .
Re: new sigil
On 10/21/05, Dave Whipp <[EMAIL PROTECTED]> wrote: > Luke Palmer wrote: > > And in those kinds of corporate environments, you're not going to be > > working with any code but code written in-house. Which means that > > nobody is going to be using Latin-1, and everyone will be using the > > ASCII synonyms. What's the problem? > > My experience is that this isn't true: we use lots of external code, but > I still need to file requests with IT to get system-settings changed. Oh good, reduce the number of fears I have of working in a tightly controlled corporate environment by one... bringing it to 499. Luke
Fwd: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Feh - I really need to get on gmail's case for providing a keystroke for "Reply to All". Rob -- Forwarded message -- From: Nate Wiger <[EMAIL PROTECTED]> Date: Oct 21, 2005 2:38 PM Subject: Re: $1 change issues [was Re: syntax for accessing multiple versions of a module] To: Rob Kinyon <[EMAIL PROTECTED]> Rob- >>BTW, C and PHP both use -> "still". > > That's because PHP is a Perl templating engine that got too big for > its britches. (http://www.devshed.com/c/a/PHP/An-Introduction-to-PHP/) Hah, that's a funny way to look at it. Although, PHP forked back in 1997, reading the article. There's alot of stuff it does differently nowadays, some better, some worse. >>Anyways, you can listen or not listen to those of us from real, large, >>corporate environments. I'm just trying to temper the enthusiasm for >>many of the real improvements in Perl 6 with some of the real costs - >>which are largely being ignored as "no big deal". > > I think YOU forget that nearly everyone else on this list, including > @Larry, has worked in large corporate environments. My understanding > of the response has been "Yes, there might be issues. They are all > solveable with a little elbow grease." And, frankly, you can run every > P5 program under Perl6. I'm not seeing what the problem is. Fair enough. Maybe I'm just a whiner. That's possible. But, I'm on the cusp of a major new outing, namely [snip]. The point is, I don't like the idea of having to relearn a ton of stuff midway thru the 5+ year product cycle of [snip]. So I'll probably end up choosing a different language for the team to use, which is too bad. -Nate P.S. I didn't post this to the list, because you didn't
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 2005-10-21 1:54 PM, "Nate Wiger" <[EMAIL PROTECTED]> wrote: > BTW, C and PHP both use -> "still". C++ is probably more relevant than C, but since it inherited the syntax, same diff. But in their case the underlying form is still a dot; A->B is just syntactic sugar for (*A).B. The distinction involved doesn't really exist in Perl, so it only needed one form, and $Larry decided to go with dot for concatenation and the arrow for dereferencing. Then enough other languages made the opposite choice that a rethink was warranted. PHP was just copying Perl5, so it doesn't count. :) > I really do understand that - really. But I think things are getting a > bit overboard. The Latin-1 sigil is another discussion that nobody wants > to admit is a legit problem, despite numerous legitimate issues. Even > being able to type in the syntax itself is going to be problematic! It's more a case of having had the discussion over and over again already, I think. Nothing came up in this thread that hadn't been said before. The design team is aware of the issues - really. They simply have decided that the trade-off in legibility worth it. > Anyways, you can listen or not listen to those of us from real, large, > corporate environments. I'm just trying to temper the enthusiasm for > many of the real improvements in Perl 6 with some of the real costs - > which are largely being ignored as "no big deal". Again, I don't think it's "no big deal" so much as "already acknowledged and stipulated." For instance, we already have non-ASCII operators, so the introduction of ¢ doesn't introduce any new issues of the sort being discussed. > I'm a big Perl advocate, but I guess I'm just not sure if I'm gonna be a > big Perl 6 advocate yet. There's alot of downsides and real business risk. I don't think there are "a lot of downsides". There is definitely a risk, as with any new technology, and I'm largely adopting a wait-and-see attitude myself, but I don't see any huge negatives anywhere. What are these downsides? >From a practical standpoint, it will be a while before I have to worry about Perl6 professionally, because we're not going to want to use it until it's been around long enough to have some kinks worked out.
Re: new sigil
TSa skribis 2005-10-21 18:54 (+0200): > My 2¢ is that we should reap ^ from the one junction and promote it to > become the 'runtime type information carrier' sigil---like the wings > on the feet of Hermes/Mercury :) It is not necessary (or sane, but that's an opinion) to reap it from the junction, because that's in infix/op position, while sigils are in prefix/term position. In Perl 5: - % is a sigil and an infix operator - * is a sigil and an infix operator - & is a sigil and an infix operator I do not see why $ and @ couldn't be both a sigil and an infix operator, and the same goes for whatever ASCII equivalent ¢ gets. ^ and | are available for sigil use. (All the closing brackets are too, but that would be very confusing because we tend to visually parse those in pairs.) Using the an infix operator's symbol as a sigil is not weird, not wrong, not confusing and mostly: not a new idea. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Luke Palmer wrote:
Every regex engine in every language uses $1 or \1. This includes Java,
JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
other languages seem ok with this, because it's a widely-used convention.
Perl 6's patterns are _not_ regexes anymore. But I doubt that we
won't be imitated, because the new regexes are way better than the old
ones. Breaking cruft for a reason and all that.
Ok, I'll wait on this one. I've said my piece. Maybe they'll go back and
update awk and sed after Perl 6 comes out. (Ok now I'm just being
sarcastic, sorry. :-)
The fact that we use . instead of -> (like every other language on
the planet)?
You're using my argument for me - thanks. See above.
Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
Perl 6 from some non-Perl 5 language is going to be more comfortable
with dot.
No, no, you misread that completely. Basically, you're saying to use the
"." for objects because "everyone else does". I'm using the same
supporting argument ("everyone else does") for why to start with $1.
BTW, C and PHP both use -> "still".
It sounds like you want a backwards-compatible change. From the
outset we knew that this wasn't our goal. Perl 5 is full to the brim
with syntax, and there's pretty much nowhere we can add anything, and
there's tons of cruft that we had to get rid of.
Consider Perl 6 to be a derivative, not an extension, of Perl 5.
I really do understand that - really. But I think things are getting a
bit overboard. The Latin-1 sigil is another discussion that nobody wants
to admit is a legit problem, despite numerous legitimate issues. Even
being able to type in the syntax itself is going to be problematic!
Anyways, you can listen or not listen to those of us from real, large,
corporate environments. I'm just trying to temper the enthusiasm for
many of the real improvements in Perl 6 with some of the real costs -
which are largely being ignored as "no big deal".
I'm a big Perl advocate, but I guess I'm just not sure if I'm gonna be a
big Perl 6 advocate yet. There's alot of downsides and real business risk.
-Nate
Re: new sigil
HaloO,
Brent 'Dax' Royal-Gordon wrote:
Steve Peters <[EMAIL PROTECTED]> wrote:
~ seems to be available for a sigil, if my reading of S02 is correct, and
the cent sign is replacing :: in all cases. If not (that is $::foo is
still the global variable named foo) then * may also be available.
Sigils can't conflict with unary operators (like, say, the
stringification and flattening operators, ~ and *) and ideally
shouldn't conflict with binary ops either (although % breaks this
rule).
My 2¢ is that we should reap ^ from the one junction and promote it to
become the 'runtime type information carrier' sigil---like the wings
on the feet of Hermes/Mercury :)
And we should find an alternative to binary % which isn't very well
defined in it's abstract meaning---but I find that the 0/0 connotation
that it spawns in my infinitly twisted brain matches nicely with infinite
precision nums and I get the identities:
Undef ::= 0/0;
One ::= Any/Any # actually $x = any(1..Inf) && 1 == $x/$x
Inf ::= Inf/Inf # the other Undef :)
Type ::= All # the concept that is shared by all instances
# and represented by the one meta representative
and of course some mixed cases like
0 ::= 0/Any
Inf ::= Any/0
The none junction hasn't one single char infix creator either. Also the
all junction is in partial conflict with the & sigil. OTOH, many fear
that junctive auto-threading enters their functions. And the junctions
have got very well picked short names.
In other words a comparison like
if $x != $x { ... }
should *never* hit the nada operator. While
if &x != &x { ... }
could depending on the evaluation of the code &x refers to.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: new sigil
Luke Palmer wrote: As I mentioned earlier, most programmers in a corporate environment >> have limited access to system settings. And in those kinds of corporate environments, you're not going to be working with any code but code written in-house. Which means that nobody is going to be using Latin-1, and everyone will be using the ASCII synonyms. What's the problem? My experience is that this isn't true: we use lots of external code, but I still need to file requests with IT to get system-settings changed. That said, I have no objection to Latin-1 sigils. So it's only your argument that's bogus, not the conclusion ;-).
JSON support
There is now rudimentary support for converting parrot objects to
JSON strings.
11:56 JSON?
11:56 well, JSON is Javascript Object Notation, at
http://www.crockford.com/JSON/
From the SYNPOSIS:
+ # generate a JSON representation of a PMC.
+ $S0 = _json( $P0 )
+
+ # generate a PMC from a JSON representation:
+ $P1 = _json_to_pmc( "[1,2,3]" )
+ #$P1 is now a array-like container PMC with three Integer elements.
+
+ .end
+ .include 'library/JSON.imc'
Some notes:
Specific type information is lost. Expect a does-like behavior: if
you're one of the 30 different PMC array types, you're an array in JSON.
It's (mostly) reversible: you can marshall the PMC to a generic JSON,
then unmarshall it back to a similar PMC. (You can also trade these
JSON strings with anything else that speaks JSON.) This is a contrast
to free/thaw, which are parrot only, but capture enough information
to reproduce the specific PMC faithfully. {{ Except for the part
where _json_to_pmc isn't done yet, of course. }}
From the TODO:
+=item Hashed subentries are not entirely pretty yet.
+
+=item Pending a more comprehensive test suite from Roger Browne
+
+=item String Escaping
+
+=item implement _jsan_to_pmc
Sample:
.sub test :main
$P1 = new .Boolean
$P1 = 0
$P2 = new .Float
$P2 = 1.234
$S3 = "hello"
$P5 = new .Hash
$P5["a"]= 1
$P5["b"]= "two"
$P5["c"]= 3.14
$P4 = new .Array
$P4 = 4
$P4[0] = $P1
$P4[1] = $P2
$P4[2] = $S3
$P4[3] = $P5
$S0 = _json( $P4, 1 )
print $S0
.end
.include 'library/JSON.imc'
--
[
false,
1.234,
"hello",
{
"a" : 1,
"b" : "two",
"c" : 3.14
}
]
Re: new sigil
On Thu, 20 Oct 2005 16:52:04 -0600, Thom Boyer wrote (in part): Thom> On 10/20/05, Juerd <[EMAIL PROTECTED]> wrote: >> 2. How can it be typed with X character composition, vim's digraphs >> and major international keyboards? For X11 composition, where getting into compose state is up to your X environment: /c In my case (for a more concrete example), that's "/c". --s.
Re: new sigil
On Fri, Oct 21, 2005 at 05:27:53PM +0200, Schneelocke wrote: > On 21/10/05, Steve Peters <[EMAIL PROTECTED]> wrote: > > I honestly don't know or care what flavor of vi I using, since it usually > > changes depending on what *nix flavor I'm working on. I also don't think > > that > > it should make a difference what editor I'm using with a programming > > language. > > Others seem to think differently. C'est la vie. > > It won't make a difference. Even if you're in an environment where you > can neither type nor copy'n'paste the cent sign, you can still use the > ASCII version of the sigil. Sure, it's going to be one extra > keystroke, but that's not really a big issue - and even less so when > you consider that you probably won't be using the class sigil as often > as the others, anyway. > > The amount of typing that was required for your emails in this thread > so far probably exceeds the amount of extry typing you'll have to do > to use the ASCII version of the sigil for your entire life already. :) For me, all that you have written above is correct. That still does not fix that potential advocacy and documentation issues that are created by this. Someone who is new to Perl 6 after its released may not know the difference. That's the problem. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On 21/10/05, Steve Peters <[EMAIL PROTECTED]> wrote: > I honestly don't know or care what flavor of vi I using, since it usually > changes depending on what *nix flavor I'm working on. I also don't think that > it should make a difference what editor I'm using with a programming language. > Others seem to think differently. C'est la vie. It won't make a difference. Even if you're in an environment where you can neither type nor copy'n'paste the cent sign, you can still use the ASCII version of the sigil. Sure, it's going to be one extra keystroke, but that's not really a big issue - and even less so when you consider that you probably won't be using the class sigil as often as the others, anyway. The amount of typing that was required for your emails in this thread so far probably exceeds the amount of extry typing you'll have to do to use the ASCII version of the sigil for your entire life already. :) > Steve Peters > [EMAIL PROTECTED] -- schnee
Re: new sigil
On Fri, Oct 21, 2005 at 10:30:40AM -0400, Rob Kinyon wrote: > > > So, you are proposing that the Perl of the Unicode era be limited to > > > ASCII because a 15 year old editor cannot handle the charset? That's > > > like suggesting that operating systems should all be bootable from a > > > single floppy because not everyone has access to a CD drive. > > > > I saying that, since my up-to-date version of vi on my up-to-date OpenBSD > > can't type, much less even allow me to paste in, a Latin-1 character, this > > is an issue. > > You're still using the base vi vs. vim?!? I didn't know people did > that when it wasn't 3am on Sunday when trying to fix a borked /etc ... > Huh! I honestly don't know or care what flavor of vi I using, since it usually changes depending on what *nix flavor I'm working on. I also don't think that it should make a difference what editor I'm using with a programming language. Others seem to think differently. C'est la vie. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On 10/20/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> Larry Wall skribis 2005-10-20 7:56 (-0700):
> > the new sigil is the cent sign, so ::T is now written ¢T instead.
>
> 1. What does it look like? I've never used a cent sign, and have seen
> several.
It looks like a lowercase c with a vertical line through it -- though the
vertical line is often slanted forward, so it looks like a c overtyped with
a slash ("/").
2. How can it be typed with X character composition, vim's digraphs and
> major international keyboards?
For vim, use CTRL-K C t
I can't address the other contexts.
=thom
"A painting in a museum hears more ridiculous opinions than anything else in
the world."
Edmond de Goncourt
Re: new sigil
Steve Peters skribis 2005-10-21 9:10 (-0500): > I saying that, since my up-to-date version of vi on my up-to-date OpenBSD > can't type, much less even allow me to paste in, a Latin-1 character, this > is an issue. You should report this bug. Hopefully, it will then be fixed before Perl 6 is released. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: syntax for accessing multiple versions of a module
On Thu, Oct 20, 2005 at 09:14:15PM -0400, John Adams wrote: > From: Luke Palmer <[EMAIL PROTECTED]> > > > But $1 in Perl 5 wasn't the same as $1 in a shell script. > > I'm all for breaking things that need breaking, which is why I > keep my mouth shut most of the time--either I see the reason or > I suspect (that is, take on faith, which is okay by me) there's > a reason I don't see or fully understand. I'm just not seeing a > compelling reason for this one, and a pretty good reason not to do it: I can state the compelling reason for this one -- it's way too confusing when $1, $2, $3, etc. correspond to $/[0], $/[1], $/[2], etc. In many discussions of capturing semantics earlier in the year, nearly everyone using $1, $2, $3 in examples, documentation, and discussion was having trouble with off-by-one errors. This includes the language designers, and even those who were advocating staying with $1, $2, $3. Once we switched to using $0, $1, $2, etc., nearly all of the confusion and mistakes disappeared. > I'm not aware offhand of any other place where $0 is used in > regex matching, and several of the languages which you point out > are zero-based in other places are not zero-based in regex matching. Yes, but none of those other regex matching languages do nested captures either. In particular, a rule like: /:w ( (\w+) = (\d+) ; )+ / no longer captures to $1, $2, $3, or even to $0, $1, $2. It now creates an array in $/[0] (aka $0), and each element of that array contains a [0] and [1] index representing the second and third set of parentheses in the rule. That is "a=4; b=2; c=8;" ~~ /:w ( (\w+) = (\d+) ; )+ / results in $/[0][0][0] == 'a' $/[0][0][1] == '4' $/[0][1][0] == 'b' $/[0][1][1] == '2' $/[0][2][0] == 'c' $/[0][2][1] == '8' Trying to make *all* of these indexes 1-based leads to chaos (especially wrt array assignment), and saying that top level parens in a rule are named $1, $2, $3, ... while nested parens are named [0], [1], [2], ... just throws everything and everyone off. It's *much* easier when everything is zero-based, even for those who are used to using $1, $2, $3 in regular expressions. Pm
RE: [OT] new sigil
On Thu, 20 Oct 2005, Steve Peters wrote:
> Again, I'd prefer not to be fired. Everything you have written above is
> not an option for the majority of the programmers out there. Also, not
> to helpful if you write your programs in TSO on an IBM mainframe.
In general true, but the cent sign was always part of EBCDIC and even
existed on the old card punch machines. It is these newfangled braces
and brackets that are not available on the 3270 terminal. Of course
you don't need them for PL/I. And BCPL uses $( and $) instead of {
and }, which makes it so much easier to type than these new Pascal and
C languages. Well, Pascal also allowed (* and *) for braces; can't
remember what it used for brackets.
Anyways, just pointing out that this is not a new discussion. :)
Cheers,
-Jan
Re: new sigil
> > So, you are proposing that the Perl of the Unicode era be limited to > > ASCII because a 15 year old editor cannot handle the charset? That's > > like suggesting that operating systems should all be bootable from a > > single floppy because not everyone has access to a CD drive. > > I saying that, since my up-to-date version of vi on my up-to-date OpenBSD > can't type, much less even allow me to paste in, a Latin-1 character, this > is an issue. You're still using the base vi vs. vim?!? I didn't know people did that when it wasn't 3am on Sunday when trying to fix a borked /etc ... Huh! Rob
Re: new sigil
On 2005-10-21 10:10 AM, "Steve Peters" <[EMAIL PROTECTED]> wrote: > I saying that, since my up-to-date version of vi on my up-to-date OpenBSD > can't type, much less even allow me to paste in, a Latin-1 character, this > is an issue. If you're using stock vi rather than vim or elvis or at least nvi, "up-to-date" doesn't apply. :) But the pasting problem has more to do with your windowing and terminal environment, and I'd be surprised if there weren't a simple tweak that would make it work for you.
Class::Role, Class::Roles, and run-time role composition for Perl5
The Class::Role and Class::Roles modules on CPAN implement a form of compile-time Perl6 role composition for Perl5. Neither supports run-time role composition, as-in: http://dev.perl.org/perl6/doc/design/syn/S12.html#Roles The does operator returns the object so you can nest mixins: $fido does Sentry does Tricks does TailChasing does Scratch; Unlike the compile-time role composition, each of these layers on a new mixin with a new level of inheritance, creating a new anonymous class for dear old Fido, so that a .chase method from TailChasing hides a .chase method from Sentry. To help with DBI v2 I need a Perl5 implementation of roles that supports run-time role composition. I figure it just needs to generate a new class with @ISA set to ref($random_object), link-in the methods, then rebless $random_object into it. Plus a cache to avoid setting up a new class if it's already generated one for ref($random_object)+$role_name. I'd work on it myself but I'm busier than usual at the moment[1] and I don't know which of Class::Role or Class::Roles I should add it to. If no one volunteers I'll have a go in a week or three. Tim. [1] Our second child will be arriving 'any day'.
Re: Y [was: "Re: new sigil"]
> 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 speak for anyone else, but personally I prefer ¥ because I don't like infix operators that look like identifiers. It's idiosyncratic, admittedly, but I dislike Pascal's "mod" and Perl5's "x" for the same reason. Even with the ability to use Unicode names, ¥ can't be an identifier, because it's not a letter, it's a currency symbol. Now that we've opened up the Pandora's box of Unicode, we have lots more letters, but also lots more non-letters, and I'd rather see the latter used for operators. Just my 2¢. :)
Re: Y [was: "Re: new sigil"]
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 because it *looks cool* :) Does it? Guillemets _do_ look kool, but I don't by the argument for the Yen symbol... Michele -- Is e+pi a rational or irrational number? Yes, it is. - Robert Israel in sci.math, "Re: A Number Problem"
Re: new sigil
On Fri, Oct 21, 2005 at 09:35:12AM -0400, Rob Kinyon wrote: > On 10/21/05, Steve Peters <[EMAIL PROTECTED]> wrote: > > On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote: > > > Steve Peters skribis 2005-10-21 6:07 (-0500): > > > > Older versions of Eclipse are not able to enter these characters. > > > > That's > > > > where the copy and paste comes in. > > > > > > That's where upgrades come in. > > > > > That's where lots of money to update to the next version of WSAD becomes the > > limiting factor. > > So, you are proposing that the Perl of the Unicode era be limited to > ASCII because a 15 year old editor cannot handle the charset? That's > like suggesting that operating systems should all be bootable from a > single floppy because not everyone has access to a CD drive. I saying that, since my up-to-date version of vi on my up-to-date OpenBSD can't type, much less even allow me to paste in, a Latin-1 character, this is an issue.
Re: new sigil
> For me AltGr + C gives Copyright-symbol "(c)". For me too, but AltGr + shift + E gives ¢. /Stefan Lidman
Re: new sigil
- Original Message - From: "Steve Peters" <[EMAIL PROTECTED]> To: "Luke Palmer" <[EMAIL PROTECTED]> Cc: Sent: Friday, October 21, 2005 4:21 AM Subject: Re: new sigil But I may have to support your code. That's the issue. Isn't perl6 assuming the source file is in UTF-8 unless explicitly specified differently? Also it's quite interesting how often was Latin-1 and UTF-8 used in the discussion interchangeably; "every source is Latin-1" is marginally better than "every source is ASCII", but we can do better. As for keyboard layouts: I don't think there is Yen sign on US keyboard either. I also use Slovak layout, which does not have backtick (only grave accent) and all sigils but % are written with AltGr. So what. I got used to it. On the other hand, there is ¤ sign. (That's U+00A4 Currency Sign -- hey, it looks like little o. If ¢ is maimed c for class, then ¤ may be o for object. Or universal-unspecified-i-dont-care-sigil.) braňo P.S. this e-mail should be sent in UTF-8.
YAMM (Yet Another MetaModel)
I'd like to propose a new metamodel that (I hope) will meet all the specs @Larry has stated thus far. This metamodel is in two parts. Part the first: There is a single object given to P6 called Factory. (No, Steve, there are no turtles.) Factory has two behaviors, no state, and no classes. The behaviors are: * create() - this will create a blank object with no behaviors or state. * set_behavior( $object, $name, $behavior) - this will assign $behavior to $object callable by $name. Part the second: A set of keywords will be used to generate objects. That set of keywords would include class and role. These objects do not have classes - they are -things- in their own right. (Still no turtles, Steve.) class and role, for instance, would be given the behaviors: * new() - the "constructor". This wraps Factory.create() and Factory.set_behavior() appropriately. It's unclear whether each item new() creates should have the methods within them or aliases to the class's methods. * eat() - this would support composition through "has" * clone() - maybe? Plus, whatever other behaviors is necessary. The keyword "is" would be handled by adding in state (which is just a behavior wrapping some data) to handle method redispatching to another object (the parent class). Yes, this is very prototype-ish. But, the metamodel that Steve's been working on is moving in that direction. Everything is an object already. Let's just clear some of the cobwebs and provide a truly clean interface. Rob
Re: Y [was: "Re: new sigil"]
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 you even need to ask? It's because it *looks cool* :) We need *more* of these. I can't wait until the day when I can finally code in overloaded Tagalog or Gujarati: http://www.iam.uni-bonn.de/~alt/html/unicode_23.html
Re: new sigil
On 10/21/05, Steve Peters <[EMAIL PROTECTED]> wrote: > On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote: > > Steve Peters skribis 2005-10-21 6:07 (-0500): > > > Older versions of Eclipse are not able to enter these characters. That's > > > where the copy and paste comes in. > > > > That's where upgrades come in. > > > That's where lots of money to update to the next version of WSAD becomes the > limiting factor. So, you are proposing that the Perl of the Unicode era be limited to ASCII because a 15 year old editor cannot handle the charset? That's like suggesting that operating systems should all be bootable from a single floppy because not everyone has access to a CD drive. Rob
Re: new sigil
On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote: > Steve Peters skribis 2005-10-21 6:07 (-0500): > > Older versions of Eclipse are not able to enter these characters. That's > > where the copy and paste comes in. > > That's where upgrades come in. > That's where lots of money to update to the next version of WSAD becomes the limiting factor. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On 21/10/05, Steve Peters <[EMAIL PROTECTED]> wrote: > On Fri, Oct 21, 2005 at 09:42:00AM +0100, Carl Franks wrote: > > Where did you get ALT-155 from? > > > > I've just checked the windows Character Map, and ¢ (cent) is ALT-0162 > > ( If it's not in your startmenu, do start -> run -> charmap ) > > Actually, both work. That's where the issus with the documentation starts. Strange, in any windows app on my machine, ALT-155 prints "o" with a diagonal line through it (bottom left to upper right). cent: ¢ not: ø I wonder if it's a font issue? Carl
Re: new sigil
Steve Peters skribis 2005-10-21 6:07 (-0500): > Older versions of Eclipse are not able to enter these characters. That's > where the copy and paste comes in. That's where upgrades come in. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
Brent 'Dax' Royal-Gordon skribis 2005-10-20 21:42 (-0700):
> @ Array sigil Array sigil
> $ Scalar sigilScalar sigil
> % Hash sigil Hash sigil, modulo
In non-term, it's not a sigil. There cannot be two subsequent terms.
This is why it makes no sense to want sigils to be free in infix/op
position, and why % and ^ would work well (without ambiguity) as sigils.
> ^ (Not sure) one() junction
^ is available in prefix/term
> ( Open paren Subroutine call
open paren: grouping. The paren is the glyph, not its function.
Also, for the subcall to work, it's not all possible infix/op, but only
postix with no whitespace in between. Same for other .[] where [] is any
set of brackets, and the dot is implied.
> { Block Hash index
Block/hash
> < quote words Less than
Also, hash subscript.
> There are very few unary operators available, and none (besides the
> user-defined backticks operator) unused in both term and operator
> context.
But that isn't necessary. It's not as if % used in two ways is new, and
was already overstepping a boundary. It's perfectly normal to have one
glyph do very different things according to how/where it's used.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [perl #37434] [PATCH] number formatting (was: ARM Parrot benchmarks / Parrot on ARM platform)
At 04:58 14/10/2005 -0700, you wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #37434] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37434 > Simon Vogl wrote: [ ... ] Here are some relevant snippets auf Parrot on ARM (see also http://use.perl.org/~koobla/journal/ ) > [EMAIL PROTECTED]:/var/tmp/parrot-0.3.0# ./parrot -t t/pmc/perlint_40.pasm > 0 new P0, 35 - P0=PMCNULL, > 3 new P1, 35 - P1=PMCNULL, > 6 set N0, 4000.04 - N0=0.00, > 9 set P0, 123 - P0=PerlInt=PMC(0x348ea0 Num:0 Int:0), > 12 multiply P1, P0, N0 - P1=PerlInt=PMC(0x348e88 Num:0 Int:0), > P0=PerlInt=PMC(0x348ea0 Num:123 Int:123), N0=4000.04 > 17 print P1 - P1=PerlNum=PMC(0x348e88 Num:492005 Int:492004) > 19 print "\n" > -492004.92 There are 2 problems. The trace dump truncates numbers and more importantly PerlNum.get_string() is very likely failing due to our 'signbit' hack that exists merely for the darn -0.0 negative zero. I think it's time to rewrite this code once again. Attached is a patch that should correct above error type. Unfortunately it causes different errors (of course +- 0.0) in t/pmc/complex.t. But it might very well be that the expected output of the test is bogus. The code in src/spf_render.c is also rather weird. At line 663 a STRING is created just to be converted back to a cstring in the next statement. This is probably not the most efficient way to strdup the format string ;-) Commenents & testers very welcome, With MinGW (gcc 3.4.2 on MSWin32) : $ perl t/harness t/pmc/perlnum.t t/pmc/perlnum...NOK 47 # Failed test (t/pmc/perlnum.t at line 961) # got: '0 # 0.00 # ' # expected: '0 # -0.00 # ' t/pmc/perlnum...NOK 55# Looks like you failed 1 test of 55. t/pmc/perlnum...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 47, 55 Failed 2/55 tests, 96.36% okay Failed Test Status Wstat Total Fail Failed List of Failed Temporarily, I reactivate the old code in perlnum.pmc François leo
Determining number of return values expected
>From within a PIR sub or method, how can I detect how many return values the caller is expecting? I'm wondering how to implement a method that will return an error code if its caller is prepared to receive one, otherwise it will raise an exception. Anyone have any suggestions? Regards, Roger Browne
Re: syntax for accessing multiple versions of a module
-Original Message- From: "Patrick R. Michaud" <[EMAIL PROTECTED]> >I can state the compelling reason for this one -- it's way too confusing when $1, $2, $3, etc. correspond to $/[0], $/[1], $/[2], etc. >In many discussions of capturing semantics earlier in the year, nearly everyone using $1, $2, $3 in examples, documentation, and discussion was having trouble with off-by-one errors. This includes the language designers, and even those who were advocating staying with $1, $2, $3. Once we switched to using $0, $1, $2, etc., nearly all of the confusion and mistakes disappeared. Okay, this I buy. There's a cost to it, but it's worth it.
Re: new sigil
On Fri, Oct 21, 2005 at 09:42:00AM +0100, Carl Franks wrote: > Where did you get ALT-155 from? > > I've just checked the windows Character Map, and ¢ (cent) is ALT-0162 > ( If it's not in your startmenu, do start -> run -> charmap ) Actually, both work. That's where the issus with the documentation starts. > > It displays in Eclipse (3.1.1) whether the Text File Encoding is set to > Cp1252 (default) or UTF-8 or ISO-8859-1 Older versions of Eclipse are not able to enter these characters. That's where the copy and paste comes in. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On Fri, Oct 21, 2005 at 11:03:07AM +0200, Bra??o Tichý wrote: > > - Original Message - > From: "Steve Peters" <[EMAIL PROTECTED]> > To: "Luke Palmer" <[EMAIL PROTECTED]> > Cc: > Sent: Friday, October 21, 2005 4:21 AM > Subject: Re: new sigil > > > > > >But I may have to support your code. That's the issue. > > > > Isn't perl6 assuming the source file is in UTF-8 unless explicitly > specified differently? My point is that there is a difference between the source file being in Unicode and depending on characters outside of ASCII. If someone wants to code using whatever Unicode characters they want, that's fine. Not every computer or editor can do Unicode out of the box. The issue starts when people are required to write code outside of ASCII and that is not available. > > Also it's quite interesting how often was Latin-1 and UTF-8 used in the > discussion interchangeably; > "every source is Latin-1" is marginally better than "every source is > ASCII", but we can do better. > > As for keyboard layouts: I don't think there is Yen sign on US keyboard > either. And that is as much of an issue. > bra??o > > P.S. this e-mail should be sent in UTF-8. And I see your name as "bra??o" :)
Re: [perl #37477] [PATCH] Configure - improved lex & yacc probing
On Wed, Oct 19, 2005 at 03:02:22AM -0700, Joshua Hoblitt wrote: > Any objections? Nobody objected. Applied as r9527. Cheers, -J -- pgp3ZJMbp1I7f.pgp Description: PGP signature
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 20 Oct 2005, Luke Palmer wrote: Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. (Also, I did like the arrow notation, but) how cool would be @cool=grep ->cool, @misc; # if compared to @cool=grep .cool, @misc; # ? Michele -- Jack Burton: This is Jack Burton in the Pork Chop Express, and I'm talkin' to whoever's out there. - Big Trouble in Little China (1986)
Re: new sigil
Where did you get ALT-155 from? I've just checked the windows Character Map, and ¢ (cent) is ALT-0162 ( If it's not in your startmenu, do start -> run -> charmap ) It displays in Eclipse (3.1.1) whether the Text File Encoding is set to Cp1252 (default) or UTF-8 or ISO-8859-1 Cheers, Carl
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/21/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote: > > > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to > > > Perl 6 from some non-Perl 5 language is going to be more comfortable > > > with dot. > > > > Unless it was Smalltalk, C++, Haskell etc. > > > > I really wish people wouldn't use the argument that . is used for method > > calls everywhere. It's not. I guess I was saying that of the infix characters we had available to choose, dot is the only one anybody uses. All the others are dotless, so our attempts would be pointless, period. Luke
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> wrote: > On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote: > > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to > > Perl 6 from some non-Perl 5 language is going to be more comfortable > > with dot. > > Unless it was Smalltalk, C++, Haskell etc. > > I really wish people wouldn't use the argument that . is used for method > calls everywhere. It's not. Well, you know, for this kind of argument I would generally agree with you. But I think in this case, I won't. The reasoning is a little shakey, but I think it still works. Smalltalk uses whitespace, therefore making it *the* fundamental syntactic operation (like function application in Haskell). Since our fundamental operation is not method call, it doesn't count. C++ uses dot half the time. Haskell doesn't really have methods. They're just functions. We aren't taking that conceptual route, so Haskell doesn't count either. Dot is probably the most semantically consistent character of modern programming languages, second only to perhaps parentheses. Luke
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote: > On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > > Luke Palmer wrote: > > > The fact that we use . instead of -> (like every other language on > > > the planet)? > > > > You're using my argument for me - thanks. See above. > > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to > Perl 6 from some non-Perl 5 language is going to be more comfortable > with dot. Unless it was Smalltalk, C++, Haskell etc. I really wish people wouldn't use the argument that . is used for method calls everywhere. It's not. Surely we have a much better argument in what we used -> for instead? > > > [1] Which will be, what, eight hours for a Perl 5 programmer? Have > > > you ever spent a month trying to learn, oh, say, Haskell? Because > > > people do that, too. > > > > There are more components to this that just the learning time for one > > person. There are project teams, sustaining engineering for existing > > projects, etc. And that's not even counting management tape. Real-world, > > profitable computing is a big, ugly, nasty beast. Basically that would mean that any team would never be able to change language, right? So there would be no difference if we wanted them to change to Perl 5, Perl 6 or Haskell, so it doesn't seem very useful to argue about this. -- Benjamin Smith <[EMAIL PROTECTED], [EMAIL PROTECTED]>
Re: new sigil
Darren Duncan wrote: In this case, I support the use of any international currency symbol for use as Perl sigils and/or operators as appropriate. Eg, we already use $ (dollar; unicode=0024; utf8=24) and ¥ (yen; unicode=00A5; utf8=C2A5), and I suggest that the next best one to exploit is ¤ (euro; unicode=20AC; utf8=E282AC), and the next best is £ (pound; unicode=00A3; utf8=C2A3). In my experience, the ¢ (cent; unicode=00A3; utf8=C2A3) is no harder to type than either of those. I haven't read this list for quite a long time, but do we already have the yen sign as a sigil? In Japan, there has been a big confusion between backslashes and yen signs over two decades. The code point 0x5c is a backslash in ASCII but it is the yen sign in JISX0201. When I display ASCII Perl program with my Japanese Windows' notepad, it shows all the backslashes as yen signs. Japanese Perl books sometimes tell: "If you cannot find a backslash on your keyboard, use the yen sign". Thus we usually think yen = ascii 005c, my eyes are optimized to unify a backslash and a yen sign in program codes, my finger is optimized to hit the yen key when my brain thinks of a backslash. It's already merged into my reflection :P Yes, I know. Careful configuration of your editor should allow you to distinguish ASCII 0x5c from JISX0201 0x5c. But in Japan, only a very keen coding-system/character-set wizard can do that. Don't you have similar confusions with the pound sign in ISO-646 British version? > the next best is £ (pound; unicode=00A3; utf8=C2A3) Isn't that 0x23 in UK? I imagine that someday all the comment lines cause syntax errors in UK... Sorry if this is an already discussed and solved issue. -- Kaoru Maeda [EMAIL PROTECTED]
Re: [perl #37434] [PATCH] number formatting (was: ARM Parrot benchmarks / Parrot on ARM platform)
At 04:58 14/10/2005 -0700, you wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #37434] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37434 > Simon Vogl wrote: [ ... ] Here are some relevant snippets auf Parrot on ARM (see also http://use.perl.org/~koobla/journal/ ) > [EMAIL PROTECTED]:/var/tmp/parrot-0.3.0# ./parrot -t t/pmc/perlint_40.pasm > 0 new P0, 35 - P0=PMCNULL, > 3 new P1, 35 - P1=PMCNULL, > 6 set N0, 4000.04 - N0=0.00, > 9 set P0, 123 - P0=PerlInt=PMC(0x348ea0 Num:0 Int:0), > 12 multiply P1, P0, N0 - P1=PerlInt=PMC(0x348e88 Num:0 Int:0), > P0=PerlInt=PMC(0x348ea0 Num:123 Int:123), N0=4000.04 > 17 print P1 - P1=PerlNum=PMC(0x348e88 Num:492005 Int:492004) > 19 print "\n" > -492004.92 There are 2 problems. The trace dump truncates numbers and more importantly PerlNum.get_string() is very likely failing due to our 'signbit' hack that exists merely for the darn -0.0 negative zero. I think it's time to rewrite this code once again. Attached is a patch that should correct above error type. Unfortunately it causes different errors (of course +- 0.0) in t/pmc/complex.t. But it might very well be that the expected output of the test is bogus. The code in src/spf_render.c is also rather weird. At line 663 a STRING is created just to be converted back to a cstring in the next statement. This is probably not the most efficient way to strdup the format string ;-) Commenents & testers very welcome, With MinGW (gcc 3.4.2 on MSWin32) : $ perl t/harness t/pmc/perlnum.t t/pmc/perlnum...NOK 47 # Failed test (t/pmc/perlnum.t at line 961) # got: '0 # 0.00 # ' # expected: '0 # -0.00 # ' t/pmc/perlnum...NOK 55# Looks like you failed 1 test of 55. t/pmc/perlnum...dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 47, 55 Failed 2/55 tests, 96.36% okay Failed Test Status Wstat Total Fail Failed List of Failed Temporarily, I reactivate the old code in perlnum.pmc François leo
