Re: Updated XPath spec

On Sat, Dec 19, 2020 at 1:19 AM Michael Kay <mike@saxonica.com> wrote:

>
>
> On 19 Dec 2020, at 08:22, Christian Grün <cg@basex.org> wrote:
>
> I think that ≠ should better be used as alias for !=, not „ne”; otherwise,
> the representations can easily be mixed up (in particular, if you use a
> font with ligatures). Same for eq, le, ge, lt, gt.
>
>
> This is partly motivated by the availability of suitable symbols and
> partly by the fact that "ne" is (or should be) a much more reasonable thing
> to want to do than "!=".
>
>
In fact even modern programming languages do use   lt , le , ne , gt ,  ge

See for example:
http://userweb.eng.gla.ac.uk/peter.smart/com/com/f77-logi.htm . There must
be a reason why Fortran, a most math-oriented language, uses the 2-letter
comparisons vs. the mathematical symbols.

Why should the programmer spend a minute or so in order to find an obscure
symbol, or have to memorize "magic codes" to enter via the keyboard, when
they just need two keypresses for any of the comparisons?

And not all wanted symbols are supported by most fonts.    Even a font such
as Consolas, which is one of the most widely used font for code (
https://www.fileformat.info/info/unicode/font/consolas/grid.htm)  doesn't
support ∈  ( \u2208 ). In fact, *Consolas doesn't support 14 out of the 20
mathematical operator symbols* that are listed in
https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#id-math-symbols


Given that  many people will have difficulties reading code that contains
uncommon symbols for ordinary fonts,  why would anyone risk to make their
code more unreadable?

Having said that, I wouldn't mind if an IDE, such as Oxygen, provides a
tool that visualizes the math operations like comparisons, equivalence,
implication, negation, set membership,inclusion (proper and improper),
difference, union, intersection,  sum, square root etc, by translating
these into the appropriate Math (Unicode) symbols -- just for viewing, and
translating them back to their ASCII equivalents when saving edited code.

Thanks,
Dimitre




> Michael Kay
>
>

Received on Sunday, 20 December 2020 18:55:04 UTC