Re: Updated XPath spec

On Sun, Dec 20, 2020 at 1:51 PM Christian Grün <cg@basex.org> wrote:

> While I’m aware that Cobol and Fortran are still around, and won’t die in
> foreseeable future, I didn't know something like Fortran 2018 exists.
> Crazy! I’m looking forward to coding XQuery in 2050 (if life permits).
>
> The more I think about it, the more I like the idea of having Unicode
> alternatives in the language. In contrast to cryptic syntactic sugar,
> mathematical operators are easy to read. And it’s a shame that the
> potential of Unicode is mostly wasted for emojis today. Of course, it’s
> easy to list reasons why ASCII characters should be preferred in a
> particular project. But the same applies to all sorts of language features,
> such as paths vs. FLWOR expressions, the use of higher-order functions,
> etc. When it comes to larger projects, you need code conventions anyway, so
> it will be up to the project lead to decide how the code in a particular
> code base should look like.
>

I think that one of the main issues here is that we would be using a single
symbol for any such operator and that is quite error-prone, the same way
when a lot of single character variable names are used and thus it becomes
very likely to accidentally replace the wanted, correct variable-name by
another one.


>
> As I mentioned, I’d just be careful to introduce alternative operators
> that look too similar to existing ASCII characters, but have a different
> meaning. With a small font, it may e.g. be difficult to differentiate ⋖
> and <.
>
> @Dimitre, I was surprised to hear that Consolas does not support
> mathematical operators.* I guess it’s because the font is already 13
> years old?* Luckily, we have countless alternatives today.
>

Consolas still supports 5 of the 20 symbols proposed in
https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#id-math-symbols
: ≠, ≤, ≥, ∩,  and  ≡

It does support other useful symbols as subscript and superscript digits, *Δ
(*delta) , ∏ (product) , Σ (sum), *√ (*square root) , ∫ (integral), *¬* (
negation), ∧ (conjunction),  ∨ (disjunction), ┴ bottom. So, these are 29
useful symbols that aren't mentioned in Appendix B3. Maybe there are much
more such useful and unmentioned symbols.

None of these were included in the new Appendix B3, so it would be hasty
and incorrect to pronounce that Consolas "does not support mathematical
operators" ... "because the font is already 13 years old" just by comparing
its support for math symbols to the one proposed in Appendix B3.

This also highlights the problem that regardless of how many math symbols
are included in the new language, the decision which exactly symbols to
include will be subjective and there will always be some not-included
symbols that are considered useful by a certain group of people.

When all major standard fonts support all useful math symbols, and there is
a special Math keyboard sold, then I might consider using these in code.

Thanks,
Dimitre


>
>
>
>
> Dimitre Novatchev <dnovatchev@gmail.com> schrieb am So., 20. Dez. 2020,
> 22:10:
>
>>
>>
>> On Sun, Dec 20, 2020 at 12:35 PM Michael Kay <mike@saxonica.com> wrote:
>>
>>> >There must be a reason why Fortran, a most math-oriented language, uses
>>> the 2-letter comparisons vs. the mathematical symbols.
>>>
>>> Of course there is! Fortran was designed 66 years ago for a character
>>> set of just 46 characters. The world has moved on.
>>>
>>>
>>
>> I expected such a reaction :)
>>
>> Please, note that this is the case even in Fortran 2018, people chose not
>> to use such symbols -- even in a most maths-related language. It is
>> unlikely that they missed such an opportunity by accident.
>>
>>
>>
>>> (Interestingly, I've noticed that the latest version of IntelliJ uses
>>> symbols like ≤ when displaying a Java program, though it doesn't appear to
>>> accept them for data entry. I'm not proposing that we require such symbols
>>> - it will still be possible to write any expression using ASCII characters
>>> alone; but I think there are increasing opportunities to make code more
>>> legible by permitting them. But it's only an idea.)
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>
>> Thanks,
>> Dimitre
>>
>