Re: Updated XPath spec

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.

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.

Dimitre Novatchev <> schrieb am So., 20. Dez. 2020,

> On Sun, Dec 20, 2020 at 12:35 PM Michael Kay <> 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

Received on Sunday, 20 December 2020 21:51:25 UTC