RE: Mutating methods
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
> : Larry Wall wrote:
> : > multi sub *scramble (String $s) returns String {...}
> : [...]
> : > Or you can just call it directly as a function:
> : > scramble("hello")
> :
> : Can you also call scramble as a class method?
> :
> : class String is extended {
> : method scramble { ..etc... }
> : }
> :
> : String.scramble("hello")
>
> Not unless you write a class method that takes an extra argument.
> Otherwise you're passing a class where it expects a string, and a
> string where it expects nothing. However, much like in Perl 5 you
> can always force which class's method to call with
>
> "hello".String::scramble();
But it would work as a "class multi", right?
class String is extended {
multi scramble(String $s) {...}
}
"hello".scramble();
String::scramble("hello"); # Way overspecified for a multi...
=Austin
RE: Mutating methods
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> : So, will "mutatingness" be a context we'll be able to inquire on
> : in the implementation of a called routine?
>
> Probably not, but it's vaguely possible you could somehow get a
> reference to what is being assigned to, if available, and check to see
> if $dest =:= $src (where =:= tests to see if two refs point to the
> same object). But in general I think most "want" testing is just a
> way of making code run slow, because it forces tests to be done at run
> time that should be done at compile time or dispatch time. It's better
> for the optimizer if you can give it enough type hints and signature
> hints to decide things earlier than the body of the sub or method.
>
> : Or, could we provide a specialized distinct implementation
> : for mutating that would get called if .=X() is used?
>
> That is much more likely. In general if you don't define both an
> and an = then Perl can autogenerate or emulate the missing
> one for you.
>
> Now in the specific case of . and .= we don't exactly have a normal
> binary operator, because the right side is not an expression.
$tis.=««sad pity pity sad sad pity true»;
$s .= ($useMbcs ? wlength : length);
(Side note: although that expression isn't valid, since the wlength
and length methods aren't qualified, it *should* be, since a human could
infer it rather easily. Can we make that DWIM? (One way would be
for the parser to convert that into if-else form if it appeared
ambiguous.))
> So we may have to provide a way of marking a normal method as a
> mutator. Possibly we end up with
>
> method =sort (Array @ary) returns Array {...} # inplace
> method sort (Array @ary) returns Array {...} # cloning
>
> That works nicely with the .= vs . distinction, visually speaking.
Why not just put a property on the calling context, and allow either:
# Run-time handling
method sort(Array @a) { if ($CALLER.mutating) {...} ...}
or
# Properties should be after names
method sort:mutating(Array @a) {...}
or
# But this is consistent with operators
method mutating:sort(Array @a) {...}
>
> On the other hand, you might want to do the same with multi subs:
>
> multi sub =sort (Array @ary) returns Array {...} # inplace
> multi sub sort (Array @ary) returns Array {...} # cloning
>
> and then it gets a little more problematic syntactically because
> multis are called like subroutines:
>
> =sort(@array);
>
> We would have to allow an initial = at the beginning of a term. So far
> I've resisted doing that because I don't want
>
> @obj.meth=foo();
>
> to become ambiguous, in case I decide to make the parentheses optional
> on method calls with arguments. If I did decide that, and we have
> terms beginning with =, it would not be clear whether the above meant
>
> @obj.meth(=foo());
>
> or
>
> @obj.meth=(foo());
Or @obj.meth = foo();
(As much as I despise those who don't use spaces around the assignment
operator, I'm willing to defend their "right" to the practice...)
> The = prefix notation also doesn't work very well for talking about the
> name of a routine:
>
> &=sort
>
> That looks an awful lot like a junctive assignment operator...
But it would be obvious from context that it was/n't:
$foo = &=sort;
bar(&=sort);
$baz &=sort;
> From a C++-ish perspective, the right thing to do is to differentiate
> not by the name but by the declared mutability of the invocant:
>
> multi sub sort (Array @ary is rw) returns Array {...} # inplace
> multi sub sort (Array @ary) returns Array {...} # cloning
>
> Or I suppose a case could be made for something that specifically
> declares you're returning one of the arguments:
>
> multi sub sort (Array @ary is rw) returns @ary {...} # inplace
>
> After all, it's possible to write a method that mutates its invocant
> but *doesn't* return it like a well-behaved mutator should. You don't
> always call a mutator in a void context--sometimes you want
> to be able to stack mutators:
>
> @array.=sort.=uniq;
>
> So you have to be able to return the mutant as well as mutate it in place.
In the case of mutators, won't the return always be the first argument?
So couldn't we just say:
multi sub sort(Array @ary is rw is mutated) returns Array {...}
multi sub sort(Array @ary) returns Array {...}
(and can't we infer the "returns Array" when "is mutated" is provided?)
> On the other hand, I'm deeply suspicious of a return signature that
> mentions a specific variable. What if the body says to return something
> else? Is that just ignored? Do we check it to see if it's the same
> item?
No. You might well say:
$string.=length;
And convert from one subtype to another. I think the mutation indicator
is a hint to the optimizer, and a crutch for the implementor, in cases
where it's possibl
Re: Mutating methods
On Fri, 12 Mar 2004 10.51, Damian Conway wrote: > There are also cases where something like: > > $a ||= $b; > > or: > > $a += $b; > > changes the type of value in $a. Should we flag those too? Currently we do > warn on the second one if $a can't be cleanly coerced to numeric. Would > that be enough for C too, perhaps? That triggered a thought about unary operators. What about: $a !=;# i.e., $a = ! $a; Obviously that particular example is a syntax error, but perhaps a more verbose "self:" version of same would not be. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
RE: Mutating methods
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
>
> Larry wrote:
>
> > On the other hand, I suspect most people will end up declaring it
> >
> > int method
> > self:rotate (int $a is rw) {...}
> >
> > in any event, and reserve the =rotate for .=rotate, which can never put
> > the = on the left margin, even if we let ourselves have whitespace
> > before POD directives. So maybe we just require self: for the
> declaration,
> > and forget about = there.
>
> Yes please!
>
> > It interacts badly with global names anyway.
> > Is it "*=sort" or "=*sort"? With "*self:sort" it's more obvious.
>
> Agreed. I'd *very* much prefer to see "reflexive" methods like this
declared
> C. From a readability stand-point, if for no other
reason.
>
Boo, hiss.
Two things:
1- I'd rather use "inplace" than self.
2- I'd rather it be AFTER, than BEFORE, the name, because
method sort
method sort:inplace
reads, and more importantly SORTS, better than
method inplace:sort
method sort
To wit:
method :infix:<=>(Array, Array) returns Scalar
method :infix:==(Array, Array) returns Boolean
method :infix:!=(Array, Array) returns Boolean
method :infix:===(Array, Array) returns Boolean
method :infix:!==(Array, Array) returns Boolean
method :infix:x(Array) returns Array
method :infix:x:inplace(Array is rw)
### Note: How to handle [undef]? return-undef, or PHP-like push?
method :postfix:[](Array is rw, ?Scalar) returns Scalar
### Inplace-only?
method clear(Array is rw) returns Boolean
method compact(Array) returns Array
method compact:inplace(Array is rw)
### Inplace-only?
method delete(Array is rw, Int) returns WHAT, exactly?
method difference(Array, Array) returns Array #A-B
method differences(Array, Array) returns Array #(A-B) + (B-A)
method exists(Array, Scalar) returns Boolean
method flatten(Array) returns Array
method flatten:inplace(Array is rw) returns Array
method grep(Array, Code) returns Array
method includes(Array, Scalar) returns Boolean
method index(Array, Scalar) returns Int
method intersect(Array, Array)
method is_empty(Array) return Boolean
method join(Array, String)
method length(Array)
method map(Array, Code) returns Array
method pack(Array, String) returns String
method reverse(Array) returns Array
method reverse:inplace(Array is rw)
method rindex(Array) returns Int
### Boy are these likely to be wrong!
method sort(Array, ?Code) returns Array
method sort:inplace(Array is rw, ?Code)
### Inplace-only?
method splice(Array is rw, ?Int, ?Int, ?Array)
method union(Array, Array) returns Array
method unique(Array) returns Array
method unique:inplace(Array is rw)
### Inplace-only?
multi method fill(Array is rw, Scalar, Int, Int)
multi method fill(Array is rw, Scalar, Int)
multi method fill(Array is rw, Scalar, Array)
### Inplace-only?
multi method pop(Array is rw, ?Int) returns Array
multi method pop(Array is rw) returns Scalar
### Inplace-only?
multi method unshift(Array is rw, Scalar) returns Array
multi method unshift(Array is rw, Array) returns Array
### Inplace-only?
multi method push(Array is rw, Array) returns Array
multi method push(Array is rw, Scalar)
### Inplace-only?
multi method shift(Array is rw, Int) returns Array
multi method shift(Array is rw) returns Scalar
multi sub each(Array) returns Iterator # HOW does this work?
(Note also that :...fix sorts better than in-, post-, and pre-. I'd like to
suggest changing
them, since it costs nothing and results in a mild improvement in automation
behavior.)
> > Another interesting question, if the "postfix:.=foo" mess is defined
> > with as self:foo, should infix:+= be defined as self:+ instead?
> > In other words, should the = syntax really be a metasyntax like
> > hyperoperators, where you never actually have to define a C<»+«>
> > operator, but the hyperoperator is always autogenerated from ordinary
> > C<+>? So basically any infix:= gets remapped to self:.
>
> I think that would be cleaner.
Alternatively, is there a valid reason to *need* to define your own
hyperoperator?
That is, can you code C< @a +« $x > better than C< @a.map {return $_ + $x}
>? I suspect that it's possible to do so, particularly for such simple cases
as assignment. (Hint: Persistent objects, database, one SQL statement per
assignment.)
So perhaps I should ask for an :infix:=« operator override?
> > On the other hand, it also means that
> > someone can say silly things like:
> >
> > $a cmp= $b
> > $a ~~= $b
> >
> > I suppose we could simply disallow meta-= on n
Re: Mutating methods
Austin Hastings writes: > > > > -Original Message- > > From: Larry Wall [mailto:[EMAIL PROTECTED] > > On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote: > > : So, will "mutatingness" be a context we'll be able to inquire on > > : in the implementation of a called routine? > > > > Probably not, but it's vaguely possible you could somehow get a > > reference to what is being assigned to, if available, and check to see > > if $dest =:= $src (where =:= tests to see if two refs point to the > > same object). But in general I think most "want" testing is just a > > way of making code run slow, because it forces tests to be done at run > > time that should be done at compile time or dispatch time. It's better > > for the optimizer if you can give it enough type hints and signature > > hints to decide things earlier than the body of the sub or method. > > > > : Or, could we provide a specialized distinct implementation > > : for mutating that would get called if .=X() is used? > > > > That is much more likely. In general if you don't define both an > > and an = then Perl can autogenerate or emulate the missing > > one for you. > > > > Now in the specific case of . and .= we don't exactly have a normal > > binary operator, because the right side is not an expression. > > $tis.=ÂÂsad pity pity sad sad pity trueÂ; > > $s .= ($useMbcs ? wlength : length); > > (Side note: although that expression isn't valid, since the wlength > and length methods aren't qualified, it *should* be, since a human could > infer it rather easily. Well, for a slightly more complex expression, a human would have some trouble. This is very likely to be laziness, and we can do without it. There is certainly a way to do this if it is absolutely necessary: my $method = ($useMbcs ?? 'wlength' :: 'length'); $s.=$method; > > On the other hand, I'm deeply suspicious of a return signature that > > mentions a specific variable. What if the body says to return something > > else? Is that just ignored? Do we check it to see if it's the same > > item? > > No. You might well say: > >$string.=length; > > And convert from one subtype to another. I think the mutation indicator > is a hint to the optimizer, and a crutch for the implementor, in cases > where it's possible to squeeze more performance out of skipping the > assignment phase. (In particular, where an inefficient assignment operator > exists.) The last thing we need is another idiom that gets destroyed for "efficiency" reasons. Once people hear that that is "fast", they'll start writing: $string.=length; Instead of what they would usually write, the much cleaner: my $len = $string.length; Even though the latter is only 0.05% slower. Speed has corrupted many programmers. > > Question: Can all this noise be eliminated by paying more attention to > the construction of the assignment operator? > > That is, do we have an example where $a .= meth is going to perform poorly, > and that performance is NOT because of the $a = $a.meth assignment? (And > that cannot be fixed by declaring the invocant 'is rw'.) The performance issue is never because of the assignment. Assignment is basically free: it's just copying a pointer. It's usually because of the construction. Constructing a 10,000 element array's going to be expensive, so you'd rather sort in place. Luke
Re: Mutating methods
"Larry Wall" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Unfortunately we can't just use topicalization to say > > my Cat $tom = .new() > > because most people won't expect simple assignment to break their > current topic. > > So another option is to replace = with something that I set the > topic for the right side. If we used .= for that, then you'd have > to write > [...] > > Another approach would be to have some kind of "microtopic" that > represented the left side of an ordinary assignment. Suppose for > the sake of argument that the microtopic is ^. Then you could write > > @array = ^.sort; > > and a constructor would be > > my Kanga $roo = ^.new() > > But that introduces a new concept that doesn't really generalize well. > So forget that. Why are we mixing the concepts of assignment and topicalization -- especially in a way that doesn't generalize. Why can't we invent a "topicalization" operator, analogous to the old binding operator, that simply sets its LHS as the topic of its RHS: and then have an assigning version of that operator. For example, lets use the "section" Unicode symbol: "§" to locally set the current topic within an expression. Now we could say: $x = ( $foo § .a + .b + .c ) to mean $x = $foo.a + $foo.b + $foo.c The assigning version of the operator could be $x §= .foo; my Dog $dog §= .new; Dave.
Re: Mutating methods
On Fri, Mar 12, 2004 at 03:47:22AM -0500, Austin Hastings wrote: > > -Original Message- > > From: Larry Wall [mailto:[EMAIL PROTECTED] > > > > Now in the specific case of . and .= we don't exactly have a normal > > binary operator, because the right side is not an expression. > > $tis.=««sad pity pity sad sad pity true»; > > $s .= ($useMbcs ? wlength : length); > > (Side note: although that expression isn't valid, since the wlength > and length methods aren't qualified, it *should* be, since a human could > infer it rather easily. Can we make that DWIM? (One way would be > for the parser to convert that into if-else form if it appeared > ambiguous.)) So ... how smart will perl6 be? $o .= (foo,bar,baz); $o .= (expr_returning_method); Since human expectations vary I don't think I want these. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Mutating methods
On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote: : That triggered a thought about unary operators. What about: : : $a !=;# i.e., $a = ! $a; Well, an argument could be made that the corresponding syntax is really: != $a; But you have to read the A = B ==> A = A B transformation differently. Something more like A = B ==> = A B where turns out to be the first actual term, which when A is specified is A, and otherwise B. In other words, dropping the A out gives you both the binary and unary forms: A = B ==> = A B = B ==> =B That could actually be pretty handy for += $a # coerce yourself to numeric ~= $a # coerce yourself to string ?= $a # coerce yourself to boolean On the other hand, if we did that generally, we'd also get operators like: \= $a # turn $a into a reference to itself Yow. : Obviously that particular example is a syntax error, but perhaps a more : verbose "self:" version of same would not be. Well, it's only a syntax error because we say it's a syntax error. But I do think prefix unarys tend to be more readable than postfix. But, yes, method calls are essentially unary postfix operators. In the OO worldview it's perfectly valid to tell an object to do something to itself. In the functional worldview, of course, keeping any kind of state is viewed with deep suspicion. So really, it's just a matter of whether there's a standard syntax for "negate yourself". I don't think there is a large call for it, since most objects don't think of themselves as booleans. But if an object did want to support that behavior, saying $a.self:!(); would certainly be "self" evident, as it were. It might even come for free with the Boolean role. But then there's the good question of whether to allow the unary op: != $a; Some good questions only have bad answers. This might be one of them. Larry
Re: Mutating methods
On 3/12/04 12:43 PM, Larry Wall wrote: > Some good questions only have bad answers. This might be one of them. I have been watching this thread with increasing unease, asking myself exactly what the potential benefit is of this proposed feature and syntax. I'm all for saving some typing, but yeesh. The only case that seems even remotely onerous is this one: my My::Big::Class::Name $obj = My::Big::Class::Name.new(); vs. my My::Big::Class::Name $obj .= new() but I'm willing to eat that if I never have to see the other crazy "="-based syntax proposals this thread has spawned :) -John
Re: Mutating methods
On Fri, Mar 12, 2004 at 09:19:46AM -0800, Dave Whipp wrote:
: Why are we mixing the concepts of assignment and topicalization --
: especially in a way that doesn't generalize. Why can't we invent a
: "topicalization" operator, analogous to the old binding operator, that
: simply sets its LHS as the topic of its RHS: and then have an assigning
: version of that operator.
Hmm, yes, other than the usual arguments against inventing *any* new
operator...
: For example, lets use the "section" Unicode symbol: "Â" to locally set the
: current topic within an expression. Now we could say:
:
: $x = ( $foo  .a + .b + .c )
:
: to mean
:
: $x = $foo.a + $foo.b + $foo.c
I expect the first thing a Nihongo-jin would do is to change it from
the section sign  to the ã "wa" particle that already means "the
preceding is the topic for the following".
$x = ( $foo ã .a + .b + .c )
So maybe the ASCII workaround is just "wa". :-) * .5
$x = ( $foo wa .a + .b + .c )
(Yes, Simon, I know that that Japanese only allows wa in the top-level
sentence position, not embedded in subexpressions. ^_^ Perhaps we
should use ga instead...)
Some will argue that since English doesn't have a grammatical
postfix topicalizer like Japanese, we should stick with something
like more English-like:
$x = (.a + .b + .c given $foo)
But that doesn't give us the corresponding assignment op. Interestingly,
modifier "if" and "unless" do in fact have corresponding assignment ops,
namely &&= and ||=.
Or we could use a syntax that is already allowed:
$x = {.a + .b + .c}($foo)
But that doesn't give us a simple topic-in-front form either...
: The assigning version of the operator could be
:
: $x Â= .foo;
: my Dog $dog Â= .new;
Though I confess I find it hard to imagine persuading people to write:
my Dog $dog wa= .new;
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".
For the sake of argument, let's call our theoretical new operator "wa".
Taking a clue from Japanese, it's perhaps a mistake to think of "wa"
as a binary operator. In Japanese, it's a postpositional particle,
which is to say, a postfix operator. You can, in fact, just say:
Neko wa.
which means something like "consider the cat". On the other hand,
as a natural language Japanese doesn't have to specify the scope of
topicalization, while Perl has to. So it's not clear whether we
should define wa such that
my Dog $dog wa= .new;
is really an assignment operator, or whether it actually
parses more like a postpositional:
(my Dog $dog).wa = .new;
In the latter case, you could use the wa postposition anywhere you
could use the expression before it, because it would set up the
expectation that the next thing is an operator rather than a term.
So you could usefully say something like
$modthingie wa %= .modulus;
or tell a subscript to default to the array as its topic:
@array wa .[.min .. .max]
That would of course read better with a single character postfix:
@arrayÂ[.min .. .max]
It's really a pity that question mark is already so overloaded with
boolean connotations, because
$dog? .bark
would really be the best postfix operator in ASCII for this.
People would probably end up writing
my Dog $spot ?= .new;
as an idiom. And
@array?[.min .. .max]
would be the way to get a topicalized subscript. If "wa" were a binary
operator as originally proposed, then you'd have to write that:
@array ? $_[.min .. .max]
or
@array ? .[.min .. .max]
since it's setting up expectation for a term rather than an operator.
On the other hand, if it's a binary operator of a particular precedence,
then the scoping of "wa" is clear. It's not so clear if mark the term
with a postfix. Unless the rule is simply that it governs for the
rest of the entire statement. In which case we'd have people writing
$foo? (
...
)
when they should probably be saying
given $foo {
...
}
But maybe the rule is that it governs the rest of the surrounding
paren scope, much like a "my" declaration does in a block, or like
a list operator eats all the commas to its right.
Not sure I want to explain that though...I certainly haven't explained
it well here. It is certainly a fact that most Perl and C programmers
are more comfortable with infix operators than postfix.
But this is gonna be a weird binary operator, if operator it is.
Its purpose is not just to evaluate the left argument but to bind
it as a temporary topic and then call the right side with that
temporary topic.
Arguably, we already have exactly this operator. It's called "dot".
Ignore for the moment that we've said that .() calls a sub. What
if binary . were our mini-topicalizer?
$topic . (.a + .b + .c)
Re: Mutating methods
Larry Wall wrote:
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".
my Dog $dog given= .new;
Where 'given' is 'wa'.
Unfortunately, it's backwards compared to the statement modifiers Perl
already has. That suggests
=.new given my Dog $dog;
but that requires the unary equals you apparently don't like *and* puts
the less important bit on the LHS.
Bah. Just use 'wa' and make the world learn Japanese. :^P
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Mutating methods
"Oh, it's got lots of Japanese in it, I'd better read it..." :)
[EMAIL PROTECTED] (Larry Wall) writes:
> Some will argue that since English doesn't have a grammatical
> postfix topicalizer like Japanese, we should stick with something
> like more English-like:
>
> $x = (.a + .b + .c given $foo)
I think I'm missing something here. We have "given" as a perfectly good
topicaliser. Now, I remember harping on a while ago about generalizing the
idea of some control structures returning values, such as $x = if $a { $b }
else { $c };
Now if we do generalise that, we get
$x = given $foo { .a + .b + .c };
which gives us the topic-in-front form, the "given" which is the standard way
of declaring the topic, and it's all nice.
> my Dog $dog wa= .new;
Urgh. This reads like you're topicalising a $dog, assigning to it and
acting on it all at the same time. Too many particles!
my Dog $inu wa ga o new desu; # ? :)
> So you could usefully say something like
>
> $modthingie wa %= .modulus;
Hrm.
given($modthingie) %= .modulus;
might work, but it relies on a few pieces of underlying magic, none of which I
believe to be over-the-top in themselves but taken together may leave a bad
taste:
control structures return a value, as above
given takes an optional block, purely setting the topic if no block
the topic persists throughout a statement
> if operator it is.
I don't think it's an operator so much as a function. It sets the
topic and, depending on how things turn out, returns either void or
the topic again.
--
teco < /dev/audio
- Ignatios Souvatzis
RE: Mutating methods
Please bare with me, I do follow this list, but sporadically. What it all boils down to, obviously, is that we, as lazy programmers, want to have to type less, but still leave the code make sense when read. So to me, that should automatically throw out stuff such as C<$x = ( $foo § .a + .b + .c )>. Even if you know exactly what it means, you still can't help by think "huh?" when you read it. So, do we want to be able to topicalize only the current expression (all code up to a ;, }, etc)? Or should multiple topicalizations be allowed? If someone did want to do multiple topicalization, should they maybe consider that they are stuffing too much code into one line? So, without further ado, here's a long list of proposals (replace topic with another more appropriate word maybe. 1. Expression descriptions (sort of like, options for expressions.. maybe leaves room for other neat tricks too). Although, I don't know if this would be possible in perl6. topic $foo: $x = .a + .b + .c 2. An operator with lowest precedence? All other operators have higher precedence. $foo topic $x = .a + .b + .c 3. A wildcard morph.. "match me to all dots missing a topic" $x = $foo* .a + .b + .c -- This brings me to another "idea" I have.. although I have a feeling you guys have already thought of it. Instead of ... $x = $a + $b + $c + $d; How about ... $x = +«$a $b $c $d»
Latin-1-characters
And I do think people would rebel at using Latin-1 for that one. I get enough grief for Â...Â. :-) I can imagine that these cause some trouble with people using a charset other than ISO-8859-1 (Latin-1) that works well with 8 bit, like Greek, Arabic, Cyrillic and Hebrew. For these guys Unicode is not so attractive, because it kind of doubles the size of their files, so I would assume that they tend to do a lot of stuff with their koi-8 or with some ISO-8859-x not containing the desired character. For ÂÂ it might not be such a problem, because <<>> would work instead. Maybe this issue could (will?) be addressed by declaring the charset in the source and using something like (or better than) \u00AB for stuff that this charset does not have, using a charset-conversion to unicode while parsing the source. This looks somewhat cleaner to me than just pretending a source file written in ISO-8859-7 (Greek) were ISO-8859-1 (Latin-1), relying on the assumption that the two characters we use above 0x80 happen to be in the same positions 0xab and 0xbb. Sorry if that is an old story... Best regards, Karl
