"Walter" <walter@digitalmars.com> wrote in message news:bqlc2t$f0p$2@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bqlasv$d7e$1@digitaldaemon.com...
> > I really see no reason why we should not be able to take any combination
> of
> > characters that Unicode classifies as symbols, and make an operator out
of
> > it.  The designers of D cannot possibly predict all the operators people
> are
> > going to need or want.
>
> Some problems:
> 1) the precedence level of those operators.

Yah that's a biggie.  But I'd be ok with them defaulting to the lowest precedence and my being forced to use parenthesis.

> 2) what this implies is user-definable tokens, which is a big problem with
a
> language that has as a design goal the ability to tokenize it without needing to do parse or semantic analysis.

So require whitespace between operator tokens.  It's easy to distinguish the
boundary between brackets and symbols, or alphanumeric and symbols.
Maybe limit the user-defined operators to no more than two symbols.

Sean

Win95 is dying, if not dead, for development purposes.

You should look forward, it won't be long before all operating systems and all applications support unicode fully.

Unless you think we're all gonna give up on this unicode nonsense in the near future, and go back to ascii.  ;)

It is a feature that doesn't have to be 100% implemented right away, and it is a feature that you are not forced to use.

Sean

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bqlept$j09$1@digitaldaemon.com...
> Mark Brudnak wrote:
>
> > When reading the D spec I noticed that it supports UNICODE UTF-8,
UTF-16,
> > UTF-32 source code formats. I propose that D extend its available set of operators (and maintain the current set) and draw from the unicode extensions for additional operators.  For example:
> >
> > LOGICAL OPERATORS
> > ==================
> > ? (unicode 2264)     may be used instead of     <=
> > ? (unicode 2265)     may be used instead of     >=
> > ? (unicode 2260)     may be used instead of     !=
> > ? (unicode 225F)     may be used instead of     ==
> > ? (unicode 2227)     may be used instead of     &&
> > ? (unicode 2228)     may be used instead of     ||
> >
>
> My email client shows '?' for all your suggestions. I expect most current code editors will do the same, since most programming languages use ASCII encoding for their source code.
>
> It would be quite some task to figure out what another programmer meant when he wrote:
>
> x = ((a ? b) ? c ? d ) ? e;
>
> Some operating systems (i.e. Win9x) don't even have support for printing unicode text on the screen, unless the used characters happen to also be available in the current code page. So it would be close to impossible to write a proper Unicode code editor on those OSs.
>
> And then, of course, there's the problem of entering such operators. My
> keyboard doesn't have any keys for (unicode 2264), (unicode 2265),... .
>
> It's a great idea, but currently I fear it is not practical.
>
> Hauke
>

In article <bqjndj$138p$1@digitaldaemon.com>, Mark Brudnak wrote:
> The largest difficulty with such a scheme is that our keyboards are not UNICODE friendly.  This I see as a problem for the editor and operating system and not so much for the D language itself.

This is also a problem that the language designer cannot fix by fixing the language. It continues to be a problem as long as QWERTY is the only universally available keyboard or as long as some of the current major operating systems do not offer a universally available easy way to input those unicode characters that are commonly used in mathematics but rarely seen on the computer screen.

-Antti

> Win95 is dying, if not dead, for development purposes.

Win95 is close to dead: about 2% of our customers. But we still have 30% customers using Win98 or WinME.

And I'm sure there are lots of Unix systems that would also have their problems with this - having been invented when ASCII ruled the world and Unicode didn't even exist.

Hauke

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bqljrj$q74$1@digitaldaemon.com...
> Mark J. Brudnak wrote:
>
> > It is bulky, but it would allow the definition of arbitrary operators in ASCII!  As was said earlier, UNICODE is the way to go, it has a defined symbol for the exterior product :^).
>
> You shall have a big, no, really HUGE parser handling these...
>
No, the parser would have to detect three tokens <[,  identifier, ]>.   It would have to take care of right/left matching.  'identifier' could be any valid D identifier like 'foo', 'bar'.  For example:

moo  =  foo <[ goo ]> zoo ;

This statement parses to the following tokens ;
moo
=
foo
<[
goo
]>
zoo
;

The compiler then knows that this is equivalent to:

moo  = foo.goo(zoo) ;


> Because the parsing manner is not generic and you need to set operator precedence by constructing a big... mess!
>

> or have all these operators have the same precedence?
>
They would be higher than assignment. Otherwise be made explicit with parenthesies.

> or even make it an error to rely on precedence of these operators like lint does?
>
> Another idea: 'blabla' should be enough for the ascii infix notation.
>
> -eye
>

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bqlunf$1ag4$2@digitaldaemon.com...
> > Win95 is dying, if not dead, for development purposes.
>
> Win95 is close to dead: about 2% of our customers. But we still have 30% customers using Win98 or WinME.
>
> And I'm sure there are lots of Unix systems that would also have their problems with this - having been invented when ASCII ruled the world and Unicode didn't even exist.

UNICODE support files for Win95 -> Me

Microsoft Layer for Unicode on Windows 95/95/ME Systems (MSLU)
    version 1.0  (http://tinyurl.com/qynq)

The question at hand is: is D going to be a language of the future, for all languages, all over the globe, or will it be a conservative backward looking effort?

Roald

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bqlo7i$111q$1@digitaldaemon.com...
> That really doesn't matter.  That's what Character Map or BabelMap are
for!
>
Yes, this will work however it is not optimal.  Too much keyboard - mouse switching is difficult.  The thing that will make this work is the editor. I use VIM but am not familiar with its macro or shortcut features.  EMACS must have similar features.  In either of these editors (or others....LEDS....DIDE...) there will be a hassle/benefit tradeoff to the macro approach.  The tipping point will be (I think) when the following happens:

1) The symbols are rendered in the editor (I can see the typeface, unlike my
original post :^) ).
2) A symbol can be entered from a QWERTY keyboard using an escape/control
key plus 3-5 other key strokes.  this would be editor-specific.

Mark.


> Besides you'd likely be able to cut and paste them either from the header
or
> the documentation.
>
Too much hassle.

> If someone makes some code that uses wierd unicode operators, you don't
have
> to use it (or you can wrap it in ugly function call syntax).
>
It makes sense to reserve all UNICODE "ARROWS" and "MATH OPERATORS" as symbols that cannot be used in identifiers.  We should then choose a handful to serve as valid operators to start out with.

> Sean
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:bql9s5$bkg$1@digitaldaemon.com...
> > These ideas have merit. Something useful ought to be done with unicode!
> The
> > lack of a decent unicode keyboard is a problem, though, as it will be
hard
> > for anyone to type in the unicode operators.
>
>

So someone can make a killing selling D Programmers' Keyboards!!  ;)

Sean

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbssvc9.i3r.jsykari@pulu.hut.fi...
> In article <bqjndj$138p$1@digitaldaemon.com>, Mark Brudnak wrote:
> > The largest difficulty with such a scheme is that our keyboards are not UNICODE friendly.  This I see as a problem for the editor and operating system and not so much for the D language itself.
>
> This is also a problem that the language designer cannot fix by fixing the language. It continues to be a problem as long as QWERTY is the only universally available keyboard or as long as some of the current major operating systems do not offer a universally available easy way to input those unicode characters that are commonly used in mathematics but rarely seen on the computer screen.
>
> -Antti

Roald Ribe wrote:
>>Win95 is close to dead: about 2% of our customers. But we still have 30%
>>customers using Win98 or WinME.
>>
>>And I'm sure there are lots of Unix systems that would also have their
>>problems with this - having been invented when ASCII ruled the world and
>>Unicode didn't even exist.
> 
> 
> UNICODE support files for Win95 -> Me
> 
> Microsoft Layer for Unicode on Windows 95/95/ME Systems (MSLU)
>     version 1.0  (http://tinyurl.com/qynq)
> 
> The question at hand is: is D going to be a language of the future,
> for all languages, all over the globe, or will it be a conservative
> backward looking effort?

The MSLU is just a layer above the normal ANSI API. It converts all Unicode strings to ANSI before passing it to functions and converts the results back to Unicode afterwards.

That means that Unicode characters that cannot be represented in the current (ANSI) code page will just be replaced with '?', or whatever the conversion routines use in such a case.

Hauke

Den Wed, 03 Dec 2003 23:34:55 -0800 skrev Sean L. Palmer:

> So someone can make a killing selling D Programmers' Keyboards!!  ;)

Remember APL? Let's not go there again. :-)

I agree that unicode operators could be useful in maths applications but other than that the advantages are pretty limited.

Java has support for Unicode symbols, and that can be a mess unless you encode all non-ascii symbols using the \u notation, which makes the code pretty hard to read.

I'm currently implementing a BASIC interpreter with full Unicode support. It's not a serious project though. :-)

Regards

Elias