Bill Baxter wrote:
On Thu, Oct 23, 2008 at 7:27 AM, Andrei Alexandrescu
<[EMAIL PROTECTED]> wrote:
Please vote up before the haters take it down, and discuss:
http://www.reddit.com/r/programming/comments/78rjk/allowing_unicode_operators_in_d_similarly_to/
(My comment cross posted here from reddit)
I think the right way to do it is not to make everything Unicode. All
the pressure on the existing symbols would be dramatically relieved by
the addition of just a handful of new symbols.
The truth is keyboards aren't very good for inputting Unicode. That
isn't likely to change. Yes they've dealt with the problem in Asian
languages by using IMEs but in my opinion IMEs are horrible to use.
Some people seem to argue it's a waste to go to Unicode only for a few
symbols. If you're going to go Unicode, you should go whole hog. I'd
argue the exact opposite. If you're going to go Unicode, it should be
done in moderation. Use as little Unicode as necessary and no more.
As for how to input unicode -- Microsoft Word solved that problem ages
ago, assuming we're talking about small numbers of special characters.
It's called AutoCorrect. You just register your unicode symbol as a
misspelling for "(X)" or something unique like that and then every
time you type "(X)" a funky unicode character instantly replaces those
chars.
Yeh, not many editors support such a feature. But it's very easy to
implement. And with that one generic mechanism, your editor is ready
to support input of Unicode chars in any language just by adding the
right definitions.
--bb
I am not entirely sure that 30 or (x amount) of new operators would be a
good thing anyway. How hard is it to say m3 = m1.crossProduct(m2) ? vs
m3 = m1 X m2 ? and how often will that happen? It's also going to make
the language more difficult to learn and understand.
If set memebrship test operator and a few others are introduced, then
really to be "complete" all the set operators must be added, and
implemented.
Futhermore, the introduction of set operators should really mean that
you can use them on something by default, that means implementing sets
that presumably are usable, quick, and are worth using, otherwise peope
will roll thier own (all the time) in many different ways.
Unicode symbol 'x' may look better, but is it really more readable? I
think it is -- a bit, and it may be cool, but I don't think it's one of
the things that is going to make developing software siginficantly easier.
Why unicode anyway? In the same way that editor support is required to
actually type them in, why not let the editor render them. So instead of
symbol 'x' in the source code, say:
m3 = m1 cross_product m2
as an infix notatation in a similar way to the (uniary) sizeof operator.
While cross_product is a bit long and unwieldy any editor capable can
replace the rendition of that keyword with a symbol for it. But in
editors that don't it means that it still can be typed in and/or
displayed easily.
Another option includes providing cross_product as an 'alias' and 'X'
aswell.
Which then leads on to the introduction of a facility to add arbitary
operators, which could be interesting becuase you can supply any
operator you see fit for the domains that you use that require it. --
This provide exactly the right solution though as all the additions
would be 'non standard' and I can see books in the future recommending
people not use unicode operators, becuase editors don't have support for
them.
If D is to be used on a wide variety of platforms, which would be
desirable if it is to gain traction, then editor support barriers like
this could impeede it's progress.
