Rob Kinyon wrote:
> xOn 5/31/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
>> Rob Kinyon wrote:
>> > I would love to see a document (one per editor) that describes the
>> > Unicode characters in use and how to make them. The Set implementation
>> > in Pugs uses (at last count) 20 different Unicode cha
xOn 5/31/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
> Rob Kinyon wrote:
> > I would love to see a document (one per editor) that describes the
> > Unicode characters in use and how to make them. The Set implementation
> > in Pugs uses (at last count) 20 different Unicode characters as
> > operators.
Rob Kinyon wrote:
I would love to see a document (one per editor) that describes the
Unicode characters in use and how to make them. The Set implementation
in Pugs uses (at last count) 20 different Unicode characters as
operators.
I have updated the unicode quickref, and started a Perlmonks dis
On Fri, May 27, 2005 at 10:29:39AM -0400, Rob Kinyon wrote:
> I would love to see a document (one per editor) that describes the
> Unicode characters in use and how to make them. The Set implementation
> in Pugs uses (at last count) 20 different Unicode characters as
> operators.
Good idea. A mode
I would love to see a document (one per editor) that describes the
Unicode characters in use and how to make them. The Set implementation
in Pugs uses (at last count) 20 different Unicode characters as
operators.
While I'm sure these documents exist on the web somewhere, since P6 is
the first time
On Nov 07, Dan Sugalski wrote:
> Lacking a decent C++ compiler isn't necessarily a strike against
> VMS--to be a strike against, there'd actually have to *be* a decent
> C++ compiler...
Doesn't VMS have a /bin/false?
- Kurt
At 1:27 PM -0800 11/6/02, Brad Hughes wrote:
Flaviu Turean wrote:
[...]
5. if you want to wait for the computing platforms before programming in
p6, then there is quite a wait ahead. how about platforms which will never
catch up? VMS, anyone?
Not to start an OS war thread or anything, but why d
Flaviu Turean wrote:
[...]
5. if you want to wait for the computing platforms before programming in
p6, then there is quite a wait ahead. how about platforms which will never
catch up? VMS, anyone?
Not to start an OS war thread or anything, but why do people still have
this mistaken impression o
The first message had many of the following characters viewable in my
telnet window, but the repost introduced a 0xC2 prefix to the 0xA7 character.
I have this feeling that many people would vote against posting all these
funny characters, as is does make reading the perl6 mailing lists difficult
Michael Lazzaro proposed:
It's up to Larry, and he knows where we're all coming from. Unless
anyone has any _new_ observations, I propose we pause the debate until a
decision is reached?
I second the motion!
Damian
Scott Duff wrote:
I'm all for one or two unicode operators if they're chosen properly
(and I trust Larry to do that since he's done a stellar job so far),
but what's the mechanism to generate unicode operators if you don't
have access to a unicode-aware editor/termina
As one of the instigators of this thread, I submit that we've probably
argued about the Unicode stuff enough. The basic issues are now known,
and it's known that there's no general agreement on any of this stuff,
nor will there ever be. To wit:
-- Extended glyphs might be extremely useful in
one more data point from a person who lived, travelled and used computers
in a few countries (Romania, France, Germany, Belgium, UK, Canada, US,
Holland, Italy). paraphrasing:
rule 1: if it's not on my keyboard, it doesn't exist;
rune 2: if it's not on everybody's keyboard, it doesn't exist.
lon
On Tue 05 Nov, Smylers wrote:
> Richard Proctor wrote:
>
> > I am sitting at a computer that is operating in native Latin-1 and is
> > quite happy - there is no likelyhood that UTF* is ever likely to reach
> > it.
> >
> > ... Therefore the only addition characters that could be used, that
> > wil
Richard Proctor wrote:
> I am sitting at a computer that is operating in native Latin-1 and is
> quite happy - there is no likelyhood that UTF* is ever likely to reach
> it.
>
> ... Therefore the only addition characters that could be used, that
> will work under UTF8 and Latin-1 and Windows ...
Dan Kogai wrote:
> We already have source filters in perl5 and I'm pretty much sure
> someone will just invent yet another 'use operators => "ascii";' kind
> of stuff in perl6.
I think that's backwards to have operators being funny characters by
default but requiring explicit declaration to use w
I'm all for one or two unicode operators if they're chosen properly
(and I trust Larry to do that since he's done a stellar job so far),
but what's the mechanism to generate unicode operators if you don't
have access to a unicode-aware editor/terminal/font/etc.? IS the
Thanks, I've been hoping for someone to post that list. Taking it one
step further, we can assume that the only chars that can be used are
those which:
-- don't have an obvious meaning that needs to be reserved
-- appear decently on all platforms
-- are distinct and recognizable in the tiny fon
This UTF discussion has got silly.
I am sitting at a computer that is operating in native Latin-1 and is
quite happy - there is no likelyhood that UTF* is ever likely to reach it.
The Gillemets are coming through fine, but most of the other heiroglyphs need
a lot to be desired.
Lets consider the
enough.
(B
(B> It will certainly be possible to write APL in Perl, but if you do,
(B> you'll get what you deserve.
(B
(BAnd even APL has j. Methinks the question is now whether you make APL
(Bout of j or j out of APL.
(B
$BCF(B the $B!i(B with Too Many Symbols to Deal With
(
20 matches
Mail list logo
