Here's something a bit lighter than what we are discussing in other
threads - a nice, friendly syntax issue. :-)

Exponent notation
-----------------

For decades programming languages have used an 'E notation' to indicate
"times 10 to the power of" as in

1e3 1 times 10 to the power of 3
4.5e-2 4.5 times 10 to the power of -2

I think it goes back as far as Fortran and maybe even further into early
assembly languages but is it the best way?

I came up with (not implemented yet) something else. IMO it's better but
see what you think. I would express the above two numbers as

10^3 10 to the power of 3
4.5x10^-2 4.5 times 10 to the power of -2

(Yes, that's a lower-case x,)

Two advantages (AISI):

1. It looks closer to what a mathematician would write.

2. It includes the base so bases other than 10 would be possible, if
required, but the presence of the base is no impediment as even if it's
always 10 it helps make the number look more natural.

Power operator
--------------

The reason for bringing this up now is that in another thread we got on
to discussing a power operator. I was using ** such that "A squared"
would be

A ** 2

However, I am not sure that looks very consistent with the above
notation so I currently have "A squared" as

A ^ 2

That said, I am not going to use x as a multiplication sign so it's not
fully compatible.

What do you think would be best as a power operator? Or should power be
calculated by a function as in C?

Spaced out
----------

One thing I should mention that may be a bit controversial is that in
keeping with other operators space matters.

10^3

is a literal integer meaning 1000 whereas

10 ^ 3

is an expression which would evaluate to 1000. Space must be on both
sides of ^ or neither. Both of

10^ 3
10 ^3

would be invalid.

That's it. Two (or is it three?) issues. Feel free to comment on or
criticise any of them. I can take it!

--
James Harris

On 08/11/2021 19:46, James Harris wrote:

> What do you think would be best as a power operator? Or should power be
> calculated by a function as in C?

Don't copy C.

It's pow() function works for one type at a time. You will need multiple
versions for different types, just like you have to with abs: abs()
labs(), llabs(), fabs(), fabs(). There are no versions of pow() for ints
that I'm aware of.

If you like 'pow', just use that with function-like syntax, but make it
overloaded like '+' and '*'.

For a symbolic operator, either ** or ^ is fine.

On 2021-11-08 20:46, James Harris wrote:

> For decades programming languages have used an 'E notation' to indicate
> "times 10 to the power of" as in
>
>   1e3      1 times 10 to the power of 3
>   4.5e-2   4.5 times 10 to the power of -2
>
> I think it goes back as far as Fortran and maybe even further into early
> assembly languages but is it the best way?

FORTRAN-IV did not have the first. Ada 83 had both.

> I came up with (not implemented yet) something else. IMO it's better but
> see what you think. I would express the above two numbers as
>
>   10^3         10 to the power of 3
>   4.5x10^-2    4.5 times 10 to the power of -2
>
> (Yes, that's a lower-case x,)

You can use the Unicode symbol ⋅ instead (U+22C5). There exists ⨯
(U+2A2F) too, but that is vector product.

> Two advantages (AISI):
>
> 1. It looks closer to what a mathematician would write.

In this case you must orient rather on physicists and chemists.

> 2. It includes the base so bases other than 10 would be possible, if
> required, but the presence of the base is no impediment as even if it's
> always 10 it helps make the number look more natural.

Just apply the base to the exponent as Ada does:

2#111#e7

means 5 * 2**7. That is why it is E and not 10 in Ada.

> One thing I should mention that may be a bit controversial is that in
> keeping with other operators space matters.
>
>   10^3
>
> is a literal integer meaning 1000 whereas
>
>   10 ^ 3

That would be an argument against using ^ for both. Note that the same
issue apply to unary - and +. This the reason why

+10

is not a literal in Ada, it is an expression.

Note also how this is connected to the approach to the types of the
literals. You need silly rules like below:

> is an expression which would evaluate to 1000. Space must be on both
> sides of ^ or neither. Both of
>
>   10^ 3
>   10 ^3
>
> would be invalid.

because you could not consistently fold constant expressions making all
cases equal. Ada has no such problem, e.g.

-32768

is perfectly OK for a 16-bit 2's complement integer regardless the fact
that the literal 32768 is out of the range.

Exponentiation would have the same problem as -, though much more
rarely, of course.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2021 20:26, Dmitry A. Kazakov wrote:
> On 2021-11-08 20:46, James Harris wrote:

....

>>    10^3         10 to the power of 3
>>    4.5x10^-2    4.5 times 10 to the power of -2
>>
>> (Yes, that's a lower-case x,)
>
> You can use the Unicode symbol ⋅ instead (U+22C5). There exists ⨯
> (U+2A2F) too, but that is vector product.

Too much like APL!

>
>> Two advantages (AISI):
>>
>> 1. It looks closer to what a mathematician would write.
>
> In this case you must orient rather on physicists and chemists.

LOL! Why is that?

>
>> 2. It includes the base so bases other than 10 would be possible, if
>> required, but the presence of the base is no impediment as even if
>> it's always 10 it helps make the number look more natural.
>
> Just apply the base to the exponent as Ada does:
>
>    2#111#e7
>
> means 5 * 2**7. That is why it is E and not 10 in Ada.

I avoided mentioning numbers with different bases because it was too
much to show at once. Besides, it looked potentially confusing to have a
number base and an exponent base. But since you bring it up my notation
for that binary number is

2'111'x2^7

>
>> One thing I should mention that may be a bit controversial is that in
>> keeping with other operators space matters.
>>
>>    10^3
>>
>> is a literal integer meaning 1000 whereas
>>
>>    10 ^ 3
>
> That would be an argument against using ^ for both.

Opinion noted. It sounds as though you see no problem with having

10^3
10 ** 3

and that may make life simpler in some ways.

> Note that the same
> issue apply to unary - and +. This the reason why
>
>   +10
>
> is not a literal in Ada, it is an expression.

What's the problem?

FWIW I wanted to be able to write explicitly unsigned integer literals
and so use + as follows.

10 weak signed integer of value 10
-10 weak signed integer of value -10
+10 weak unsigned integer (of value 10)

>
> Note also how this is connected to the approach to the types of the
> literals. You need silly rules like below:
>
>> is an expression which would evaluate to 1000. Space must be on both
>> sides of ^ or neither. Both of
>>
>>    10^ 3
>>    10 ^3
>>
>> would be invalid.
>
> because you could not consistently fold constant expressions making all
> cases equal. Ada has no such problem, e.g.
>
>    -32768
>
> is perfectly OK for a 16-bit 2's complement integer regardless the fact
> that the literal 32768 is out of the range.
>
> Exponentiation would have the same problem as -, though much more
> rarely, of course.
>

Again, that sounds interesting but it appears to defy logic. What does
it mean?

--
James Harris

On 08/11/2021 21:04, Bart wrote:
> On 08/11/2021 19:46, James Harris wrote:
>
>> What do you think would be best as a power operator? Or should power
>> be calculated by a function as in C?
>
> Don't copy C.

I too think an operator would be nice.

>
> It's pow() function works for one type at a time. You will need multiple
> versions for different types, just like you have to with abs: abs()
> labs(), llabs(), fabs(), fabs().

Or if you live in this century, you use <tgmath.h> and it's all just
fabs(), pow(), etc., for any floating point types.

> There are no versions of pow() for ints
> that I'm aware of.

Not in the standard library, no. It has always struck me as an odd
omission (though I don't believe I have needed integer powers in my own
code, except for powers of 2).

>
> If you like 'pow', just use that with function-like syntax, but make it
> overloaded like '+' and '*'.

Yes, as it is in C (and C++). But go the whole way and cover integer
types as well as floating point types.

>
> For a symbolic operator, either ** or ^ is fine.
>

I think ** is the more common choice, especially if the language also
wants an operator for xor.

On 08/11/2021 20:52, James Harris wrote:
> On 08/11/2021 20:26, Dmitry A. Kazakov wrote:

>> Just apply the base to the exponent as Ada does:
>>
>>     2#111#e7
>>
>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>
> I avoided mentioning numbers with different bases because it was too
> much to show at once. Besides, it looked potentially confusing to have a
> number base and an exponent base. But since you bring it up my notation
> for that binary number is
>
>   2'111'x2^7

What /is/ the number? Is it 7 * 2**7 or 5 x 2**7? Having two 7s is
confusing!

Assuming it is the former, then the number is 896. (BTW my Casio uses ^
for 'to the power of'.)

I would write that entirely in base 2 as the single literal:

2x111e111

This yields 896.0, a float. But I can emulate your example:

2x111*2**7

in this case yielding an integer 896

Once again, don't copy C in this regard, where this:

0x100p10

is the literal 262144.0. This was a surprise to my, since when I write:

0x100p10

I get:

4722366482869645200000.0

Note that my literal is 100% hex, so 0x100p10 means:

256 * 16 ** 16

In C, 0x100p10 means:

256 * 2 * 10

So it's using 3 different bases: hex for the 0x100 part, base 2 (what
you raise to the power), and base 10 for the exponent!

On 08/11/2021 21:26, Dmitry A. Kazakov wrote:

> Just apply the base to the exponent as Ada does:
>
>    2#111#e7
>
> means 5 * 2**7. That is why it is E and not 10 in Ada.
>
(Surely you mean 7 * 2**7 ?)

Ada's system for non-decimal numbers has always struck me as flexible,
but possibly the ugliest and most difficult to read and write method I
have ever seen.

How often does anyone need a base other than 2, 10, or 16 ? If you are
into computer palaeontology, perhaps you also want octal - but that's
stretching things (I believe most cases of C octal constants, such as
0123, are mistakes - the programmer probably mean 123).

I have a hard time seeing how it would be possible to get something more
convenient and unambiguous than 123.6e5, 0xbeef, 0b1101. Other bases
don't turn up in real code, nor do floating point in anything other than
decimal. You'll want a digit separator, however - underscore is
probably the best choice.

(I'm omitting C's octals and hexadecimal floating point notations, and I
don't think the type suffixes are a good solution.)

On 2021-11-08 21:52, James Harris wrote:
> On 08/11/2021 20:26, Dmitry A. Kazakov wrote:
>> On 2021-11-08 20:46, James Harris wrote:

>> In this case you must orient rather on physicists and chemists.
>
> LOL! Why is that?

Who else would ever use such numbers? (:-)

>>> 2. It includes the base so bases other than 10 would be possible, if
>>> required, but the presence of the base is no impediment as even if
>>> it's always 10 it helps make the number look more natural.
>>
>> Just apply the base to the exponent as Ada does:
>>
>>     2#111#e7
>>
>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>
> I avoided mentioning numbers with different bases because it was too
> much to show at once. Besides, it looked potentially confusing to have a
> number base and an exponent base. But since you bring it up my notation
> for that binary number is
>
>   2'111'x2^7

The point is that it does not make much sense to have the exponent
different from the base. The numeric model suggests that the exponent
shifts the mantissa by digits:

2#111#e2 = 2#11100#e0

>> Note that the same issue apply to unary - and +. This the reason why
>>
>>    +10

>> is not a literal in Ada, it is an expression.
>
> What's the problem?

You stated it yourself, the problem is with the blanks inside the literals:

+ // Children, let me tell you a wonderful story
//
// ...
//
// And they lived happily ever after.
10

> FWIW I wanted to be able to write explicitly unsigned integer literals
> and so use + as follows.
>
>   10   weak signed integer of value 10
>   -10  weak signed integer of value -10
>   +10  weak unsigned integer (of value 10)

A normal reader would expect +10 be signed because you specified that
damned sign!

But how would you explain a non-medicated person why

a-10

must be illegal?

> Again, that sounds interesting but it appears to defy logic. What does
> it mean?

It is quite logical to me that

-32768

and

- 32768

mean exactly same and the second would not suddenly overflow.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2021 21:25, David Brown wrote:
> On 08/11/2021 21:04, Bart wrote:
>> On 08/11/2021 19:46, James Harris wrote:
>>
>>> What do you think would be best as a power operator? Or should power
>>> be calculated by a function as in C?
>>
>> Don't copy C.
>
> I too think an operator would be nice.
>
>>
>> It's pow() function works for one type at a time. You will need multiple
>> versions for different types, just like you have to with abs: abs()
>> labs(), llabs(), fabs(), fabs().
>
> Or if you live in this century, you use <tgmath.h> and it's all just
> fabs(), pow(), etc., for any floating point types.

If it's only for floats, how many are there? There's only float and
double unless you're interested in complex.

tgmath.h is anyway not universal. tcc doesn't have it. MSVC warns its
version is not compatible with C99 (possibly due to not have _Generic).
(You have to use ctgmath.h, for C++.)

So it's still messy, and not an approach to be copied.

On 2021-11-08 22:27, Bart wrote:
> On 08/11/2021 20:52, James Harris wrote:
>> On 08/11/2021 20:26, Dmitry A. Kazakov wrote:
>
>>> Just apply the base to the exponent as Ada does:
>>>
>>>     2#111#e7
>>>
>>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>>
>> I avoided mentioning numbers with different bases because it was too
>> much to show at once. Besides, it looked potentially confusing to have
>> a number base and an exponent base. But since you bring it up my
>> notation for that binary number is
>>
>>    2'111'x2^7
>
> What /is/ the number? Is it 7 * 2**7 or 5 x 2**7? Having two 7s is
> confusing!

7 * 2**7. 5 was a typo error.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2021-11-08 22:37, David Brown wrote:
> On 08/11/2021 21:26, Dmitry A. Kazakov wrote:
>
>> Just apply the base to the exponent as Ada does:
>>
>>    2#111#e7
>>
>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>>
> (Surely you mean 7 * 2**7 ?)

Yes.

> Ada's system for non-decimal numbers has always struck me as flexible,
> but possibly the ugliest and most difficult to read and write method I
> have ever seen.
>
> How often does anyone need a base other than 2, 10, or 16 ? If you are
> into computer palaeontology, perhaps you also want octal - but that's
> stretching things (I believe most cases of C octal constants, such as
> 0123, are mistakes - the programmer probably mean 123).
>
> I have a hard time seeing how it would be possible to get something more
> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.

And how would by do:

16#0.FF03_8A90_FE1E#E-5

p instead of E looks totally out of place.

> Other bases
> don't turn up in real code, nor do floating point in anything other than
> decimal.

Maybe, but it is simpler to have them for the regularity sake.

> You'll want a digit separator, however - underscore is
> probably the best choice.

Yes, like in Ada.

> (I'm omitting C's octals and hexadecimal floating point notations, and I
> don't think the type suffixes are a good solution.)

A Unicode alternative would be using the mathematical notation for the base:

1101₂

Exponents would be superscript as James suggested:

0.FF03_8A90_FE1E₁ ₆16⁵

Not very readable in a fixed font.

P.S. I actually used such stuff in the UI, e.g. to annotate axes in
graphs and for measurement units. You really want to see m/s² rather
than m/(s^2) or whatever.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2021 22:56, Bart wrote:
> On 08/11/2021 21:25, David Brown wrote:
>> On 08/11/2021 21:04, Bart wrote:
>>> On 08/11/2021 19:46, James Harris wrote:
>>>
>>>> What do you think would be best as a power operator? Or should power
>>>> be calculated by a function as in C?
>>>
>>> Don't copy C.
>>
>> I too think an operator would be nice.
>>
>>>
>>> It's pow() function works for one type at a time. You will need multiple
>>> versions for different types, just like you have to with abs: abs()
>>> labs(), llabs(), fabs(), fabs().
>>
>> Or if you live in this century, you use <tgmath.h> and it's all just
>> fabs(), pow(), etc., for any floating point types.
>
> If it's only for floats, how many are there? There's only float and
> double unless you're interested in complex.

float, double, long double, float _Complex, double _Complex, long double
_Complex. The complex types are there, whether you are interested in
them or not.

(I prefer C++'s handling of complex numbers - it makes more sense to
have them as library classes than built-in language types.)

>
> tgmath.h is anyway not universal. tcc doesn't have it. MSVC warns its
> version is not compatible with C99 (possibly due to not have _Generic).
> (You have to use ctgmath.h, for C++.)

I have little interest in half-baked sort-of-C compilers. MSVC has
traditionally had terrible C support - perhaps because they want users
to think C is bad and choose lock-in C# instead. I have heard that the
more recent versions of MSVC are better, but have not tried them myself.

tcc is a toy - or, at best, a niche tool aimed at minimal size rather
than properly supporting C standards. tgmath.h is part of C99 - a
standard that is two decades old, and which has been superseded twice!
A toolchain that doesn't support it can't call itself C.

(<tgmath.h> precedes _Generic by over a decade. One of the motivations
for _Generic was to allow a <tgmath.h> implementation without needing
compiler extensions, but compilers had <tgmath.h> long before _Generic.)

And no, you don't need to use <ctgmath.h> in C++. In every C++
toolchain known to man, you can use <tgmath.h>. You can alternatively
use <ctgmath> - there is no ".h" in the C++ standard headers.

However, the normal C++ method is to include <cmath> and use overloaded
std::pow - the powf and powl (and similarly for fabs and all the others)
are only included for convenience of compatibility.

>
> So it's still messy, and not an approach to be copied.
>

Don't copy the implementation details from C - copy the user-level
usage. Have "pow" (and "abs", and the rest) as functions that can take
any arithmetic type and adapt to that type. It doesn't matter if this
is done by _Generic, compiler extensions, overloaded functions, function
templates, or whatever. (It should not, however, be done with built-in
functions or operators - these are library functions in any
well-designed language.)

On 08/11/2021 23:18, Dmitry A. Kazakov wrote:
> On 2021-11-08 22:37, David Brown wrote:
>> On 08/11/2021 21:26, Dmitry A. Kazakov wrote:
>>
>>> Just apply the base to the exponent as Ada does:
>>>
>>>     2#111#e7
>>>
>>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>>>
>> (Surely you mean 7 * 2**7 ?)
>
> Yes.
>
>> Ada's system for non-decimal numbers has always struck me as flexible,
>> but possibly the ugliest and most difficult to read and write method I
>> have ever seen.
>>
>> How often does anyone need a base other than 2, 10, or 16 ?  If you are
>> into computer palaeontology, perhaps you also want octal - but that's
>> stretching things (I believe most cases of C octal constants, such as
>> 0123, are mistakes - the programmer probably mean 123).
>>
>> I have a hard time seeing how it would be possible to get something more
>> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.
>
> And how would by do:
>
>    16#0.FF03_8A90_FE1E#E-5
>
> p instead of E looks totally out of place.

When would you ever need it? Who has /ever/ had need of writing a
hexadecimal fraction?

In C, you could have

(double) 0xff03'8a90'fe1e / 0x1'0000'0000'0000 / 0x10'0000

Yes, I'd write such a monstrosity using a normal hexadecimal number that
is then scaled. How I would write the scaling - dividing by separate
hex numbers, or by a (1ul << (48 + 20)), or something else, would depend
on the context. And I can't imagine any context where such a thing
would exist.

>
>> Other bases
>> don't turn up in real code, nor do floating point in anything other than
>> decimal.
>
> Maybe, but it is simpler to have them for the regularity sake.
>

Not if it means the common cases of binary and hex integers are so
hideous to work with. Have an extra mess to allow base 13 floating
point if you want, but don't drag binary and hex into it.

>> You'll want a digit separator, however - underscore is
>> probably the best choice.
>
> Yes, like in Ada.

Yes, I know. C++ could not use underscore, since that had another
meaning, so they picked ' (as used in a few countries). C is following
in the up-coming C23 standard.

>
>> (I'm omitting C's octals and hexadecimal floating point notations, and I
>> don't think the type suffixes are a good solution.)
>
> A Unicode alternative would be using the mathematical notation for the
> base:
>
>    1101₂

That would work, except that almost no one could type it. (Even on
*nix, few people have a compose key enabled, and few of them know that ₂
is compose + underscore + 2.)

>
> Exponents would be superscript as James suggested:
>
>    0.FF03_8A90_FE1E₁ ₆16⁵
>
> Not very readable in a fixed font.

Or writeable.

>
> P.S. I actually used such stuff in the UI, e.g. to annotate axes in
> graphs and for measurement units. You really want to see m/s² rather
> than m/(s^2) or whatever.
>

Unicode can be fine for text strings - I agree that ms⁻² or m/s² is
nice. But it is not a good choice for key parts of a language.

On 08/11/2021 22:43, David Brown wrote:

> templates, or whatever. (It should not, however, be done with built-in
> functions or operators - these are library functions in any
> well-designed language.)

Why?

+ and * aren't usually library functions, what's special about **?

These operations are fundamental. My Casio calculator has dedicated
buttons for Abs, **, sqrt, square, log, sin and so on.

And what would you be missing out on if they /were/ built-in?

Anyone can add versions implemented via user-functions if they really
want; vice-versa is a little harder.

On 2021-11-08 23:56, David Brown wrote:
> On 08/11/2021 23:18, Dmitry A. Kazakov wrote:
>> On 2021-11-08 22:37, David Brown wrote:
>>> On 08/11/2021 21:26, Dmitry A. Kazakov wrote:
>>>
>>>> Just apply the base to the exponent as Ada does:
>>>>
>>>>     2#111#e7
>>>>
>>>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>>>>
>>> (Surely you mean 7 * 2**7 ?)
>>
>> Yes.
>>
>>> Ada's system for non-decimal numbers has always struck me as flexible,
>>> but possibly the ugliest and most difficult to read and write method I
>>> have ever seen.
>>>
>>> How often does anyone need a base other than 2, 10, or 16 ?  If you are
>>> into computer palaeontology, perhaps you also want octal - but that's
>>> stretching things (I believe most cases of C octal constants, such as
>>> 0123, are mistakes - the programmer probably mean 123).
>>>
>>> I have a hard time seeing how it would be possible to get something more
>>> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.
>>
>> And how would by do:
>>
>>    16#0.FF03_8A90_FE1E#E-5
>>
>> p instead of E looks totally out of place.
>
> When would you ever need it? Who has /ever/ had need of writing a
> hexadecimal fraction?

Rarely. One case I had was tabulating floating-point constants that need
to be exact. IEEE 754 would be binary, but I remember, some
floating-point formats used hexadecimal mantissa.

>>> Other bases
>>> don't turn up in real code, nor do floating point in anything other than
>>> decimal.
>>
>> Maybe, but it is simpler to have them for the regularity sake.
>
> Not if it means the common cases of binary and hex integers are so
> hideous to work with. Have an extra mess to allow base 13 floating
> point if you want, but don't drag binary and hex into it.

The beauty is in the eye of beholder. I find 0xFE hideous and illogical.

>> A Unicode alternative would be using the mathematical notation for the
>> base:
>>
>>    1101₂
>
> That would work, except that almost no one could type it. (Even on
> *nix, few people have a compose key enabled, and few of them know that ₂
> is compose + underscore + 2.)

Yes. I never managed to learn that trick. I open some Unicode HTTP page
or Windows Character Map and copy paste from there.

> Unicode can be fine for text strings - I agree that ms⁻² or m/s² is
> nice. But it is not a good choice for key parts of a language.

Yes. I am against Unicode in the programming language even in the string
literals.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2021 21:39, Dmitry A. Kazakov wrote:
> On 2021-11-08 21:52, James Harris wrote:

>>> In this case you must orient rather on physicists and chemists.
>>
>> LOL! Why is that?
>
> Who else would ever use such numbers? (:-)

:-)

....

> But how would you explain a non-medicated person why
>
>    a-10
>
> must be illegal?

If it's meant to be the name of an identifier it would presumably be
undeclared so the compiler would report it as such.

If, on the other hand, it's meant to be a subtraction but lacks required
whitespace the compiler could still report it. In fact, it would be easy
enough for the compiler to provide apropos hints to people coming from
other languages.

>
>> Again, that sounds interesting but it appears to defy logic. What does
>> it mean?
>
> It is quite logical to me that
>
>    -32768
>
> and
>
>    - 32768
>
> mean exactly same and the second would not suddenly overflow.
>

Didn't you say they were int 16s in which such a number would be invalid?

--
James Harris

On 08/11/2021 22:18, Dmitry A. Kazakov wrote:
> On 2021-11-08 22:37, David Brown wrote:

....

>> I have a hard time seeing how it would be possible to get something more
>> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.
>
> And how would by do:
>
>    16#0.FF03_8A90_FE1E#E-5

FWIW my version of that would be similar:

16'0.FF03_8A90_FE1E'x16^-5

....

> A Unicode alternative would be using the mathematical notation for the
> base:
>
>    1101₂
>
> Exponents would be superscript as James suggested:
>
>    0.FF03_8A90_FE1E₁ ₆16⁵

I suggested an 'up arrow' but not a literal superscript. IMO all code
should be in universal old ASCII.

--
James Harris

On 2021-11-09 09:14, James Harris wrote:
> On 08/11/2021 21:39, Dmitry A. Kazakov wrote:
>> On 2021-11-08 21:52, James Harris wrote:
>
>> But how would you explain a non-medicated person why
>>
>>     a-10
>>
>> must be illegal?
>
> If it's meant to be the name of an identifier it would presumably be
> undeclared so the compiler would report it as such.
>
> If, on the other hand, it's meant to be a subtraction but lacks required
> whitespace the compiler could still report it. In fact, it would be easy
> enough for the compiler to provide apropos hints to people coming from
> other languages.

What kind of hints? I see two compelling alternatives:

1. Sorry guys, I could not do it right.

2. Piss off, moron!

(:-))

>>> Again, that sounds interesting but it appears to defy logic. What
>>> does it mean?
>>
>> It is quite logical to me that
>>
>>     -32768
>>
>> and
>>
>>     - 32768
>>
>> mean exactly same and the second would not suddenly overflow.
>
> Didn't you say they were int 16s in which such a number would be invalid?

But it would be valid, that is the whole point!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 08/11/2021 21:37, David Brown wrote:
> On 08/11/2021 21:26, Dmitry A. Kazakov wrote:

....

> How often does anyone need a base other than 2, 10, or 16 ?

You mean you don't write out many gene sequences? ;-)

> If you are
> into computer palaeontology, perhaps you also want octal - but that's
> stretching things (I believe most cases of C octal constants, such as
> 0123, are mistakes - the programmer probably mean 123).

That problem wasn't in BCPL which allowed, AIUI, any of

#O100
#o100
#100

but the problem was introduced in B which had the rule: "An octal
constant is the same as a decimal constant except that it begins with a
zero".

It's curious as to how popular octal was back then that languages made
it the easiest to type.

>
> I have a hard time seeing how it would be possible to get something more
> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.

If you are talking about C having those I am surprised to see the 0b
notation. When was it introduced?

It took me a long time and many iterations to come up with a good
notation for numbers in bases other than decimal (a case of lots of work
to make something that looks simple) but I am pleased with the result.
Your two non-decimals would be

0xbeef --> 16'beef'
0b1101 --> 2'1101'

IMO the result is logical, flexible and readable but YMMV. And, yes, it
uses underscore for digit separation.

> Other bases
> don't turn up in real code, nor do floating point in anything other than
> decimal. You'll want a digit separator, however - underscore is
> probably the best choice.
>
> (I'm omitting C's octals and hexadecimal floating point notations, and I
> don't think the type suffixes are a good solution.)

Agreed.

--
James Harris

On 09/11/2021 09:00, Dmitry A. Kazakov wrote:
> On 2021-11-09 09:14, James Harris wrote:
>> On 08/11/2021 21:39, Dmitry A. Kazakov wrote:
>>> On 2021-11-08 21:52, James Harris wrote:
>>
>>> But how would you explain a non-medicated person why
>>>
>>>     a-10
>>>
>>> must be illegal?
>>
>> If it's meant to be the name of an identifier it would presumably be
>> undeclared so the compiler would report it as such.
>>
>> If, on the other hand, it's meant to be a subtraction but lacks
>> required whitespace the compiler could still report it. In fact, it
>> would be easy enough for the compiler to provide apropos hints to
>> people coming from other languages.
>
> What kind of hints?

A standard error message followed by a hint for people coming from other
languages. For example, the report might be

Syntax error: invalid character ('-') in name
If you mean minus then remember to include space before and after

--
James Harris

On 09/11/2021 07:47, Dmitry A. Kazakov wrote:
> On 2021-11-08 23:56, David Brown wrote:
>> On 08/11/2021 23:18, Dmitry A. Kazakov wrote:
>>> On 2021-11-08 22:37, David Brown wrote:

....

>>>> Other bases
>>>> don't turn up in real code, nor do floating point in anything other
>>>> than
>>>> decimal.
>>>
>>> Maybe, but it is simpler to have them for the regularity sake.
>>
>> Not if it means the common cases of binary and hex integers are so
>> hideous to work with.  Have an extra mess to allow base 13 floating
>> point if you want, but don't drag binary and hex into it.
>
> The beauty is in the eye of beholder. I find 0xFE hideous and illogical.

You do? In Ada that's 16#FE#, isn't it, which surely looks worse.

....

> Yes. I am against Unicode in the programming language even in the string
> literals.

Definitely!

--
James Harris

On 09/11/2021 00:52, Bart wrote:
> On 08/11/2021 22:43, David Brown wrote:
>
>> templates, or whatever.  (It should not, however, be done with built-in
>> functions or operators - these are library functions in any
>> well-designed language.)
>
> Why?
>
> + and * aren't usually library functions, what's special about **?
>

"pow" could be an operator - that's not unreasonable. I really meant
the others maths functions.

> These operations are fundamental. My Casio calculator has dedicated
> buttons for Abs, **, sqrt, square, log, sin and so on.

We are discussing programming languages, not calculators.

>
> And what would you be missing out on if they /were/ built-in?
>
> Anyone can add versions implemented via user-functions if they really
> want; vice-versa is a little harder.
>
>

There are many reasons to choose to implement all the various
mathematical functions as library functions (preferably a language
standard library):

It keeps the language itself smaller, making it easier to document,
implement, use, and update.

It makes it easier to have alternative implementations of the functions
for different needs.

It makes it easier to add new functions.

It means you can have separate namespaces and not pollute the global
namespace with rarely-used keywords.

It makes it vastly easier to have different people implementing the
language, and mathematical functions.

Remember, your language is an oddity. It is a /personal/ language - it
makes no difference to you whether a feature is in the language, the
library, or the user code, because it is all part of the same soup.
That is not the case for most languages.

We are not living in the 1960's, trying to re-invent BASIC - nor in the
1970's re-inventing C.

A language for modern times needs namespaces, libraries or modules, a
way of defining simple functions that gives the compiler full insight
(like inline functions) to avoid function call overheads and to allow
extra knowledge, and a way of using a single function declaration with
multiple types, using either generic definitions or specialised definitions.

These are, I think, required features for a useful modern language. If
you don't have those, you might as well not bother (unless the language
is /very/ niche).

And once you have them, putting abs, log, sin, and anything else into a
library is easy.

You might even want to make operators fully programmable, and then
"power" can be an operator defined in the library.

On 08/11/2021 21:37, David Brown wrote:
> On 08/11/2021 21:26, Dmitry A. Kazakov wrote:
>
>> Just apply the base to the exponent as Ada does:
>>
>>    2#111#e7
>>
>> means 5 * 2**7. That is why it is E and not 10 in Ada.
>>
> (Surely you mean 7 * 2**7 ?)
>
> Ada's system for non-decimal numbers has always struck me as flexible,
> but possibly the ugliest and most difficult to read and write method I
> have ever seen.
>
> How often does anyone need a base other than 2, 10, or 16 ?

You can have it for fun, or just for completeness:

println 0x100
println 2x100
println 4x100
println 5x100
println 6x100
println 7x100
println 8x100
println 9x100
println 10x100
println 11x100
println 12x100
println 13x100
println 14x100
println 15x100
println 16x100
println

println 0x100.1
println 2x100.1
println 4x100.1
println 5x100.1
println 6x100.1
println 7x100.1
println 8x100.1
println 9x100.1
println 10x100.1
println 11x100.1
println 12x100.1
println 13x100.1
println 14x100.1
println 15x100.1
println 16x100.1
println

static [2:]ichar bases = ("x2","x3","x4","x5","x6","x7","x8",
"x9","x10","x11","x12","x13","x14","x15","x16")
const n = u64.max

for i in bases.bounds do
fprintln "# in base # is #", n, i:"2", n:bases[i]
od

The above prints 100 interpreted as bases 2 to 16 (16 appears twice as
0x and 16x), then 100.1 in the same bases. Finally it displays the same
number in bases 2 to 16. Output is:

256
4 16
25
36
49
64
81
100
121
144
169
196
225
256

256.062500
4.500000
16.250000
25.200000
36.166667
49.142857
64.125000
81.111111
100.100000
121.090909
144.083333
169.076923
196.071429
225.066667
256.062500

18446744073709551615 in base 2 is
1111111111111111111111111111111111111111111111111111111111111111
18446744073709551615 in base 3 is 11112220022122120101211020120210210211220
18446744073709551615 in base 4 is 33333333333333333333333333333333
18446744073709551615 in base 5 is 2214220303114400424121122430
18446744073709551615 in base 6 is 3520522010102100444244423
18446744073709551615 in base 7 is 45012021522523134134601
18446744073709551615 in base 8 is 1777777777777777777777
18446744073709551615 in base 9 is 145808576354216723756
18446744073709551615 in base 10 is 18446744073709551615
18446744073709551615 in base 11 is 335500516A429071284
18446744073709551615 in base 12 is 839365134A2A240713
18446744073709551615 in base 13 is 219505A9511A867B72
18446744073709551615 in base 14 is 8681049ADB03DB171
18446744073709551615 in base 15 is 2C1D56B648C6CD110
18446744073709551615 in base 16 is FFFFFFFFFFFFFFFF

(I can't display floats in any base, because I for those I have a
dependency on C's sprintf.)

> If you are
> into computer palaeontology, perhaps you also want octal - but that's
> stretching things (I believe most cases of C octal constants, such as
> 0123, are mistakes - the programmer probably mean 123).
>
> I have a hard time seeing how it would be possible to get something more
> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101. Other bases
> don't turn up in real code,

I use base 1'000'000'000 in one of my libraries. But it doesn't have
language support!

On 09/11/2021 11:36, Bart wrote:
> On 08/11/2021 21:37, David Brown wrote:

....

>> I have a hard time seeing how it would be possible to get something more
>> convenient and unambiguous than 123.6e5, 0xbeef, 0b1101.  Other bases
>> don't turn up in real code,
>
> I use base 1'000'000'000 in one of my libraries. But it doesn't have
> language support!
>

And you would want to write constants in that base...?!

--
James Harris

On 09/11/2021 11:05, David Brown wrote:
> On 09/11/2021 00:52, Bart wrote:
>> On 08/11/2021 22:43, David Brown wrote:
>>
>>> templates, or whatever.  (It should not, however, be done with built-in
>>> functions or operators - these are library functions in any
>>> well-designed language.)
>>
>> Why?
>>
>> + and * aren't usually library functions, what's special about **?
>>
>
> "pow" could be an operator - that's not unreasonable. I really meant
> the others maths functions.
>
>> These operations are fundamental. My Casio calculator has dedicated
>> buttons for Abs, **, sqrt, square, log, sin and so on.
>
> We are discussing programming languages, not calculators.

You're missing the point of the calculator: there are limited number of
dedicated buttons, but they decided Abs etc were fundamental enough to
have their own button.

Similar to how I decided they were fundamental enough to be
dedicated built-in operators.

>
>>
>> And what would you be missing out on if they /were/ built-in?
>>
>> Anyone can add versions implemented via user-functions if they really
>> want; vice-versa is a little harder.
>>
>>
>
> There are many reasons to choose to implement all the various
> mathematical functions as library functions (preferably a language
> standard library):
>
> It keeps the language itself smaller, making it easier to document,
> implement, use, and update.

Why is that important, considering that adding those built-ins amounts
to a few 10s of KB, but typical implementations run to 10s or 100s of MB?

Since the language needs those functions, it still needs to add them but
now needs headers, templates, generics, ... a whole raft of machinery.

And for the user? They have to muck around doing stuff like this:

#include <tgmath.h> // for fabs
#include <stdlib.b> // for abs, labs, llabs

Then need to decide exactly which alternate to apply, and then, if a
type T changes from int to long int, change 100 instances of abs to labs.

I think I'll stick with my approach, thanks.

> A language for modern times needs namespaces, libraries or modules,

Namespaces: check

Libraries: check (even if rather meagre ATM)

Modules: check

> a
> way of defining simple functions that gives the compiler full insight
> (like inline functions) to avoid function call overheads and to allow
> extra knowledge,

Whole program compilation: check (but not taking advantage yet)

> and a way of using a single function declaration with
> multiple types, using either generic definitions or specialised definitions.

Generics: [pause to switch to my dynamic language] check

> These are, I think, required features for a useful modern language. If
> you don't have those, you might as well not bother (unless the language
> is /very/ niche).
>
> And once you have them, putting abs, log, sin, and anything else into a
> library is easy.

With the library again! I've had abs, log, sin etc as builtins since the
early 80s. That was when I had to implement float arithmetic in
software. Now that /was/ a library, but used to transparently support
A+B*C in the language, just like I do now with sin etc.

Since my compilers have always had poor optimisers, the advantage of a
built-in is that it makes it easier to generate inline code, rather than
have to try and inline a function. Which would anyway take extra resources.

So if I now do:

real x, y
y := abs(x)

The IR is:

push x r64
abs r64
pop y r64

And the x64 code is:

mov xmm4, R.x # R.x R.y are xmm registers
andpd xmm4, [...]
mov R.y, xmm54

(This could be optimised better to two instructions)

> You might even want to make operators fully programmable, and then
> "power" can be an operator defined in the library.

And again! You've been coding in C too long. I bet that if C had had
'pow' as a built-in operator from the start, then you would have a
different view now.