not operator operator..

Georg Wrede georg.wrede at nospam.org
Tue Apr 4 17:37:40 PDT 2006


Derek Parnell wrote:
> Regan Heath wrote:
>> Georg Wrede
>>> Anders F Björklund wrote:
>>>> S. Chancellor wrote:
>>>> 
>>>>> I didn't say I wanted to program in AppleScript. :P  I hate
>>>>> mixing symbols and words.  This is terrible.  I'd rather
>>>>> redefine all the equal set and comparison operators.  The
>>>>> whole point of the is-operator is equivalence, unfortunately
>>>>> there's no triple bar symbol.
>>>> 
>>>> Sure there is. ≡ in Unicode (\u2261), or === in plain ASCII.
>>>> It's just that it was removed from the language in DMD 0.126 ?
>>> 
>>> If D really _demands_ source code to be in UTF, then there is no
>>> excuse for avoiding single-character operators like "≡".
>> 
>> Except that they're not easily acessable on a common/standard
>> keyboard, right?
> 
> What? You mean you're *not* using the standard 473-key keyboard? How 
> strange !?

If somebody is able to produce "≡", then let him define it. All we need 
is some suitable syntax.

define ≡ opMyEqual;     // or something like this

I admit, this idea is not yet implementable as such: some operators may 
not be strictly binary, and other such issues. And I'm definitely not 
talking D 1.0 here. But still.

Such a character would of course only be used in that particular 
application, and thus probably be developed by a group of people who can 
tell each other how to produce this character. Or they can copy/paste it 
(just as I did, without even bothering to search for ways of actually 
typing it).

However, many very illustrative UTF characters do exist. Math, 
statistics, programming, logic, etc... could benefit from their use in 
source code.

And if they were user-defined-only (as opposed to ever becoming included 
in the actual D spec), issues of right or wrong usage should be on a par 
with issues around variable names. (I.e. any idiot can use variable 
names written in Thai or Russian characters, but it's still not too 
common, and never will be.)

---

I'm not really pursuing this issue as something First Priority, or 
Essential. It's more like, if we don't accept this, then what's the use 
of accepting any at all non-USASCII source code (outside of string 
literals)?



More information about the Digitalmars-d mailing list