On 12/11/2021 21:02, Bart wrote:
> But you're avoiding the question. It seems to be like you're just
> making excuses for a program that you're so used to, you accept it
> without question.
> If gcc had worked differently, taking the default output file name
> from the first input file (as does my bcc, lccwin, DMC, PellesC,
> MSVC, even tcc when on Windows), would it have caused you any grief?

Well, it's a minor point, but yes; as I would have had to
arrange to zap "fred.exe", "bart.exe", ... either on the spot or
overnight, or else have an accumulation of unwanted executables
[and several unwanted back-ups of them all]. As it is, I know that
"a.out" is garbage; if I want to preserve it, I rename it.

> Would you have had to waste time typing -oa.out to get your prefered
> output? I guess not.

OTOH, if you want /your/ behaviour, then write the following
one-line shell script and put it as an executable called "c" in your
"bin" directory [or whatever the equivalent is in your environment:

gcc "$1".c -o "$*"

then you can write commands such as "c hello" or "c fred bert.c -O3"
and so on, saving several characters per use. I expect you will
find /some/ reason why it doesn't work for you.

[...]
> I think you're just cross that A68G didn't make it to the first, easy
> hurdle of compiling 20,000 lines; [...].

Not in the least. When you find a real-life example that
requires 20000 lines of code with no structure at all, let me know.
I suspect that A68G will very happily manage to compile and run

INT a, b := 1, c := 2;
TO 20000 DO a := b + c OD

which is much better code [though still silly] than

INT a, b := 1, c := 2;
a := b + c;
a := b + c;
a := b + c;
... repeated thousands of times ...

Write daft programs, and you can expect daft results.

>>> After installing, then:
>>>    make hello
>>> didn't work. And with:
>>>    make hello.c
>>> it said "No rule to make target 'hello.c'"
>>      You are so resistant to reading instruction manuals that
> Oh, right. I thought you were suggesting 'make' as an alternate way
> to compile programs.

No, it's an alternate way of managing projects, so that you
can decide /once/ how to build, test and install your code, inc [eg]
manual entries, documentation, all necessary permissions, clean-up
and so on, and /then/ sit there typing "make" [not even "make hello"]
for everything to happen.

> It took me a few seconds to see if it was clever enough to see
> 'prog.c' and recognise that it should invoke a C compiler; why not?> But apparently it wasn't.

The C compiler can't create "hello.c" for you. But it knows
to invoke the C compiler in response to "make hello.o", which will
create and maintain "hello.o" /from/ "hello.c".

> OK, the .c extension is clearly not enough of a clue!

Of course not. You didn't need or want to make "hello.c",
and there are lots of other things you might possibly have wanted
to do with "hello.c" -- print it, remove it or back it up, count
the number of lines in it, create a cross-reference listing for
it, install it in an archive, .... Ten minutes spent reading
the documentation might have helped. See

https://en.wikipedia.org/wiki/Make_(software)

and the references therein.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bull

On 12/11/2021 20:03, David Brown wrote:
> On 12/11/2021 20:07, Bart wrote:

[Finally got curious to see what insults you had for me this time]

> The clang build in the msys2 package repository is configured to use
> msys libraries. The clang build distributed with MSVC is configured to
> use MSVC libraries. That should not be a big surprise to anyone who
> understands what a C compiler is and how it relates to libraries.

I got my clang here:

https://releases.llvm.org/download.html

(It's the second google hit for 'download clang windows'. The first is
about building from source.)

The first link on that page for a Win64 binary is:

https://github.com/llvm/llvm-project/releases/download/llvmorg-11.0.0/LLVM-11.0.0-win64.exe

Someone installing that will find that the bundled clang.exe needs msvc.

When someone has installed msvc and successfully synced it to clang,
then they may well find that there are issues with tgmath.h.

That is all that I reported:

"I've just now tried Clang. That is, Clang running on Windows, part of a
large LLVM installation, and with links into MSBUILD tools."

>> People who work on Unix tend to do the opposite: develop their tools to
>> be highly dependent on Unix. That's why you have all those add-ons for
>> Windows to try and emulate that environment.
>>
>> I'm surprised you don't get that.
>>
>
> I don't "get it", because it is simply bollocks. It's not even wrong,

It is exactly what I have observed.

Just look at how many open source programs require you to run
'./configure' as the first step (configure is a shell script for Linux).

Perhaps you've been immersed in Unix-like systems so long that you just
take the existence of these dependencies for granted. The only form of
Windows you've used are special versions that provide the special
environment you expect.

On 12/11/2021 20:17, Dmitry A. Kazakov wrote:
> On 2021-11-12 19:36, Bart wrote:
>> On 12/11/2021 18:04, Dmitry A. Kazakov wrote:
>>> On 2021-11-12 18:49, Bart wrote:
>>>
>>>> I specifically make tools to be as easy to use as compiling
>>>> hello-world.
>>>
>>> Good for you, but I am perfectly capable to typing "Hello World"
>>> without any compiler.
>>
>> You are misunderstanding again. Presumably, deliberately. Suppose you
>> could do this:
>>
>>     gcc hello.c -ohello.exe
>>
>> and then you could do this:
>>
>>     gcc python.c -opython.exe
>>
>> Then you can just run Python, yes?
>
> Nope. Python comes with a huge library of loadable and precompiled
> modules. Your example does not make sense.

I'm talking about the binaries that constitute that product. Bonus
content in the form of programs in the language is a separate matter.

Never mind, try this test. The last program I wrote in my script
language happened to be this one:

---------------------------------
function f(n) = {(n.even | n%2 | 3*n+1)}

count := 0
n := 989'345'275'647

while n<>1 do
n := f(n)
++count
od

println "Count =", count
---------------------------------

A Python version would be:

---------------------------------
def f(n):
if n & 1:
return 3*n+1
else:
return n//2

count=0
n=989_345_275_647

while n != 1:
n = f(n)
count+=1

print("Count =",count)
---------------------------------

I'm interested in running this to see what value of 'count' is produced.
But let's say there's a snag: the interpreter to run this program, which
is called 'c.q' only exists as source code.

What do to? Well in my case it's simple enough:

C:\qx>mm qq
Compiling qq.m---------- to qq.exe

C:\qx>qq c
Count = 1348

Compiling qq.exe took just over 0.1 seconds. On Windows. With one 0.5MB
dependency (mm.exe).

The challenge for you is this: starting only with the source codes of
CPython, try building from scratch in order to run the above program.

You only need enough of it working to run this example.

Let me know how long it took. Once you've done that, try the same
exercise on Windows.

If you find that too easy, try building the gcc tool-chain from source
first. In my case, building mm.exe will add 0.12 seconds (plus the time
to type the command!).

But just carry on sneering. I'll carry on using my nippy tools.

> GtkAda bindings are generated from C headers. But that is beyond the
> point, which is that Notepad++ is a better tool for "Hello World" than
> your compiler while both are unsuitable for real-life software developing.

I'm not sure what point you are trying to make.

That an application, in combination with suitable tools, can be as easy
and almost as quick to build as a hello-world program, does not mean the
application IS hello-world.

Maybe you think that in that case, it can't possibly be much more
sophisticated?

Then you're misinformed. (And have little experience of using compilers
processing 0.5M lines per second and generating 5MB of code per second.)

On 2021-11-14 22:58, Bart wrote:
> On 12/11/2021 20:17, Dmitry A. Kazakov wrote:
>> On 2021-11-12 19:36, Bart wrote:
>>> On 12/11/2021 18:04, Dmitry A. Kazakov wrote:
>>>> On 2021-11-12 18:49, Bart wrote:
>>>>
>>>>> I specifically make tools to be as easy to use as compiling
>>>>> hello-world.
>>>>
>>>> Good for you, but I am perfectly capable to typing "Hello World"
>>>> without any compiler.
>>>
>>> You are misunderstanding again. Presumably, deliberately. Suppose you
>>> could do this:
>>>
>>>     gcc hello.c -ohello.exe
>>>
>>> and then you could do this:
>>>
>>>     gcc python.c -opython.exe
>>>
>>> Then you can just run Python, yes?
>>
>> Nope. Python comes with a huge library of loadable and precompiled
>> modules. Your example does not make sense.
>
> I'm talking about the binaries that constitute that product. Bonus
> content in the form of programs in the language is a separate matter.

Stop embarrassing yourself. Install Python under Windows, go to the
installation folder and see what it entails.

>> GtkAda bindings are generated from C headers. But that is beyond the
>> point, which is that Notepad++ is a better tool for "Hello World" than
>> your compiler while both are unsuitable for real-life software
>> developing.
>
> I'm not sure what point you are trying to make.
>
> That an application, in combination with suitable tools, can be as easy
> and almost as quick to build as a hello-world program, does not mean the
> application IS hello-world.

I somehow missed your post illustrating deployment of a GTK-based project...

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

On 14/11/2021 22:25, Bart wrote:
> On 12/11/2021 20:03, David Brown wrote:
>> On 12/11/2021 20:07, Bart wrote:
>

>
>>> People who work on Unix tend to do the opposite: develop their tools to
>>> be highly dependent on Unix. That's why you have all those add-ons for
>>> Windows to try and emulate that environment.
>>>
>>> I'm surprised you don't get that.
>>>
>>
>> I don't "get it", because it is simply bollocks.  It's not even wrong,
>
> It is exactly what I have observed.
>

There are perhaps three rough groupings of PC software developers (with
a few outliers).

1. Those that think the world is Windows and x86 - specifically the
version of Windows they are using at the time, and the type of x86 they
are using at the time. Portability is irrelevant, you can assume "long"
is 32-bit, and so on. A fair part of this group also assumes users are
using English (maybe even specifically American), as well as making a
range of assumptions about the C or C++ that don't even hold within
their limited world of MSVC, Borland, etc., (such as assuming signed
integer arithmetic wraps).

Porting code by type 1 developers is nearly impossible - it is always
windows-only.

2. There are those that assume the world is *nix, and really don't care
about anyone else. Their code is typically portable to a wide range of
processors and OS's. Sometimes it is easily ported to Windows with
little more than a re-compile using something like mingw-64 to make a
Windows binary, sometimes it is too dependent on features missing from
Windows (such as "fork" calls, or file-system features, or X) and even
if a Windows port can be made, it will feel very alien. The original
developers are unlikely to help making Windows ports, but third-parties
can do so.

3. There are those that make their code cross-platform to start with, or
add it as support later on. Most start in the *nix world here.

On the whole, people from the Windows world write Windows-only software.
People from the *nix world are far more likely to write cross-platform
software, even if they started on *nix. Thus MSVC is Windows-only,
while gcc mainline development supports at least two Windows
environments (msys/mingw for making what everyone except perhaps you
would call "native" Windows binaries, and cygwin for when you want a
compatibility layer to fill in the bits of POSIX that MS left out).

Almost all of the development tools I use on Linux can also run on
Windows. I usually /prefer/ to run them on Linux, and they are
sometimes more efficient there (since Linux is more efficient for some
kinds of tasks), but they can be run on Windows. On the other hand, I
also use development tools that are Windows only and they do /not/ run
on Linux.

Really, you have the situation completely backwards.

> Just look at how many open source programs require you to run
> './configure' as the first step (configure is a shell script for Linux).

I use "./configure" on Linux perhaps a couple of times a year, maximum.
Usually I don't bother compiling from source - I need a good reason for
that. (It's nice that I can, but nicer that I don't have to.) I can't
remember the last time I used a configure script on Windows.

("configure" is not a shell script for Linux. Often a "configure"
script is generated by autotools, and is specifically made to work on a
huge range of systems, not just Linux, and often including Windows. But
it does rely on a small number of basic utilities.)

>
> Perhaps you've been immersed in Unix-like systems so long that you just
> take the existence of these dependencies for granted. The only form of
> Windows you've used are special versions that provide the special
> environment you expect.

Why do you insist on believing that, no matter how often I tell you
otherwise? Is there a point to discussing this if you are simply going
to deny everything others tell you, and call me a liar?

On 15/11/2021 08:02, Dmitry A. Kazakov wrote:
> On 2021-11-14 22:58, Bart wrote:

>> I'm talking about the binaries that constitute that product. Bonus
>> content in the form of programs in the language is a separate matter.
>
> Stop embarrassing yourself. Install Python under Windows, go to the
> installation folder and see what it entails.

Both Python and my product are byte-code interpreters capable of running
one of the corresponding programs I posted.

Python's binaries are a 0.1MB python.exe file and a 4.5MB python3.dll
file. But it relies on a vastly more complex support system to do the
simple task of running that program.

It's build system is complex too and differs dramatically between
Windows and Linux.

That is its choice.

Mine is a 0.4MB qq.exe file. Usually I incorporate my meagre libraries
to make a self-contained 0.65MB file.

That can run the program immediately with no other support.

That was MY choice.

You seem to abhor anyone trying to make anything smaller, faster, simpler.

Again, it makes me 0.12 seconds to build the interpreter to run that
program.

CPython can take minutes to hours. You obviously equate that with being
better.

>> That an application, in combination with suitable tools, can be as
>> easy and almost as quick to build as a hello-world program, does not
>> mean the application IS hello-world.
>
> I somehow missed your post illustrating deployment of a GTK-based
> project...

I simply wouldn't use it. What, a 55-DLL, 100MB dependency to go with a
100KB application?

WinAPI is as complicated as that, however it is part of my OS so no one
needs to go and source all the dependencies.

What was your challenge again? I think it was:

"You are free to illustrate easiness of using your tools on an example
of a GTK application targeted for Windows and Linux. Show one
release/deployment cycle."

I don't have many apps but here is a toy program that loads and displays
images, and allows some basic editing; I'm not sure what you mean by
release/deployment, but I run it in production as follows:

C:\demo>bmed # (script that invokes the following)
C:\demo>c:\qx\qq c:\m\bmedit.qa

(I then get a simple GUI window with a CLI. After typing 'load card2',
it displays:

https://github.com/sal55/langs/blob/master/demo.png
)

That bmedit.qa is a text file containing all the .q modules, in a form
the interpreter can run directly. It is created as follows:

C:\myapps>qq -qa bmedit
Writing bmedit.qa

The size of that file is 40KB. It uses libraries in the same language of
250KB, part of qq.exe.

This graphics app, which is 100% interpreted, dynamic bytecode, uses an
abstraction layer over WinAPI. That had been designed to be switchable
between WinAPI and whatever delights awaited me in Linux' X11, but I
never got round to that; I never had a suitable Linux64 machine. (But I
now I have in the form of WSL's Ubuntu...)

I did however do that for my console library, so that the same program
using cursor positioning, colour text etc worked on either OS.

So, what else do you want to know? I won't use GTK, but I have played
with SDL2, Cairo, OpenGL and Raylib as well as WinAPI.

On Mon, 08 Nov 2021 19:46:35 +0000, James Harris wrote:

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

;-)

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

No. For over half a century, Algol has used a distinct character, and it
has been in Unicode for quite some time: "⏨" (U+23E8) as in 1⏨3.

> 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,)

Why a lowercase x for multiplication, Unicode has × ?

For the expression of numbers, I believe nothing beats Unicode:
N_A = 6,02214076 ·10²³ mol⁻¹. (Why Unicode Consortium wastes time adding
silly emojis instead of making sure useful symbols like subscript capital
letter A are included, I don't know.)

/Lasse

On 15/11/2021 14:21, Lasse Hillerøe Petersen wrote:
> On Mon, 08 Nov 2021 19:46:35 +0000, James Harris wrote:
>
>> Here's something a bit lighter than what we are discussing in other
>> threads - a nice, friendly syntax issue. :-)
>
> ;-)
>
>> I think it goes back as far as Fortran and maybe even further into early
>> assembly languages but is it the best way?
>
> No. For over half a century, Algol has used a distinct character, and it
> has been in Unicode for quite some time: "⏨" (U+23E8) as in 1⏨3.

A few things to say to that:

* Not all powers are of 10. For example, if the number is in hex then
the base might be 16.

* Accessing Unicode characters can be a challenge - e.g. remembering
U+23E8, for example.

* Some Unicode characters look like each other, meaning that code which
used them could have a syntax error while looking perfect to a human
reader.

>
>> 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,)
>
> Why a lowercase x for multiplication, Unicode has × ?

Lower-case x is just a separator, here, similar to a scheme in which r
is a separator:

16rFE
2r1110

I chose x as the separator in this case purely because it allowed the
number to look more familiar.

>
> For the expression of numbers, I believe nothing beats Unicode:
> N_A = 6,02214076 ·10²³ mol⁻¹. (Why Unicode Consortium wastes time adding
> silly emojis instead of making sure useful symbols like subscript capital
> letter A are included, I don't know.)

Unicode is OK for typesetting, i.e. converting text which is already
correct into a form for human readership. But as above it can cause
problems when going from 'human' to text when that text has to be
processed meaningfully, as is especially true of program source.

I'd have your Avogadro's constant as

6.02214076x10^-23

which is not too bad, is it?!

--
James Harris

On Mon, 15 Nov 2021 21:52:57 +0000, James Harris wrote:

> On 15/11/2021 14:21, Lasse Hillerøe Petersen wrote:
>> On Mon, 08 Nov 2021 19:46:35 +0000, James Harris wrote:
>>
>>> Here's something a bit lighter than what we are discussing in other
>>> threads - a nice, friendly syntax issue. :-)
>>
>> ;-)
>>
>>> I think it goes back as far as Fortran and maybe even further into
>>> early assembly languages but is it the best way?
>>
>> No. For over half a century, Algol has used a distinct character, and
>> it has been in Unicode for quite some time: "⏨" (U+23E8) as in 1⏨3.
>
> A few things to say to that:
>
> * Not all powers are of 10. For example, if the number is in hex then
> the base might be 16.

All the more reason to use a normal notation with proper superscript.
1 KiB = 2¹° B = 4×16² B = 400₁₆

Of course, if you use for example the C notation of 0x prefix (not saying
it is a good idea) your "hexadecimal scientific notation" should _still_
use ⏨ - as 0x10 = 16. :-)

> * Accessing Unicode characters can be a challenge - e.g. remembering
> U+23E8, for example.

Have a character menu in the editor where you can pick them out, this is
not a character issue, but a user interface issue. Use the correct
symbols, that's why we have them! I find it strange that normal people
have _no_ problems using all sorts of weird emojis in text messages on
their smartphones, but to use well-defined, standard symbols in programs
is soooo haaaard.

> * Some Unicode characters look like each other, meaning that code which
> used them could have a syntax error while looking perfect to a human
> reader.

Says you, who just suggested to "abuse" the likeness of the lowercase x
to ×? :-)

> Unicode is OK for typesetting, i.e. converting text which is already
> correct into a form for human readership. But as above it can cause
> problems when going from 'human' to text when that text has to be
> processed meaningfully, as is especially true of program source.

That's utter 🐂💩!

> I'd have your Avogadro's constant as
>
> 6.02214076x10^-23
>
> which is not too bad, is it?!

In an 8-bit world of ISO-8859-1, I'd find it passable but unsatisfying.
But we live in the world where Unicode exists, has nearly all the symbols
you could ever want, and now seems to be set on a path to revert the
evolution of writing back to the hieroglyphs of ancient Egypt with
emojis. I do not advocate going APL - but in normal use, like
handwriting, a lot of symbols are routinely used, and it is time we
started adapting our computer usage to normality, after decades of
suffering from the limits of ASCII, ISO-646 or ISO-8859. * is an
asterisk, not a multiplication symbol.

/Lasse

On 15/11/2021 22:52, James Harris wrote:
> On 15/11/2021 14:21, Lasse Hillerøe Petersen wrote:

>>
>> For the expression of numbers, I believe nothing beats Unicode:
>> N_A = 6,02214076 ·10²³ mol⁻¹. (Why Unicode Consortium wastes time adding
>> silly emojis instead of making sure useful symbols like subscript capital
>> letter A are included, I don't know.)
>
> Unicode is OK for typesetting, i.e. converting text which is already
> correct into a form for human readership. But as above it can cause
> problems when going from 'human' to text when that text has to be
> processed meaningfully, as is especially true of program source.
>
> I'd have your Avogadro's constant as
>
>   6.02214076x10^-23
>
> which is not too bad, is it?!
>

Thunderbird helpfully renders that using superscript for the -23, making
it look significantly nicer than your traditional plain ASCII
representation, or even the Unicode version 10⁻²³ where the spacing is
not nice. Typographically, there is a significant difference between a
character designed to give a numerical power for normal-size letter or
number, such as x², and superscript numbers. The spacing for the
Unicode superscript characters is typically designed to fit the spacing
of normal sized characters. (It may vary be font, however.)

Unicode is very convenient and gives a nice and portable method for a
lot of characters. When combined with a decent keyboard layout (i.e.,
not plain US or UK, but something with dead keys) it makes it easy to
write text that is a significant step up from plain ASCII. You can
write names such as Hillerøe, words like naïve or fête with the correct
spelling, you can write π·r² with ease.

But it doesn't cover everything you need in typesetting, and trying to
push it too far gives results that will vary significantly in appearance
in different systems, spoiling the point. And while it's easy for Linux
(or other *nix) folk to pick a flexible keyboard layout and enable the
compose key, many other people are not so lucky. Requiring Unicode for
expressing numbers in a programming language seems a step in the wrong
direction, IMHO.

On 15/11/2021 11:45, Bart wrote:
> On 15/11/2021 08:02, Dmitry A. Kazakov wrote:

>> I somehow missed your post illustrating deployment of a GTK-based
>> project...
>

> I don't have many apps but here is a toy program that loads and displays
> images, and allows some basic editing; I'm not sure what you mean by
> release/deployment, but I run it in production as follows:
>
> C:\demo>bmed                     # (script that invokes the following)
> C:\demo>c:\qx\qq c:\m\bmedit.qa
>
> (I then get a simple GUI window with a CLI. After typing 'load card2',
> it displays:
>
>   https://github.com/sal55/langs/blob/master/demo.png
> )

This program has a dependency on a DLL that processes files like JPEG.
There is a decoder in this dynamic language, but it's too slow for
production use (eg. 1.2 seconds for the image in that demo).

I use one of two libraries:

* One based on stb_image.h (a 7000-line C library). This can be used
when built with my own 'bcc' C compiler into a DLL.

* Another using jpeg.m, a jpeg-only decoder in my language. This is
built with my 'mm' compiler into a DLL.

I'd taken my eye off DLLs, some files has been lost, and some things had
got messed up. But now the code for JPEG is processed with my own tools
only. Which is rather more satisfying.

On 09/11/2021 18:33, Bart wrote:

....

> what exactly is the problem
> with having SQRT, say, as a built-in function or operator in a language?

As in the "Common operators" thread, SQRT is or can defined as part of
the type of its operand. For example,

int a
float b
complex c

sqrt(a) <== invalid, no such function for type int
sqrt(b) <== invokes the float sqrt
sqrt(c) <== invokes the complex sqrt

where

type float
function sqrt
....

type complex
function sqrt
....

and type int has no sqrt function.

>
> Someone give me a convincing answer, and I will change my
> implementation, provided it doesn't involve reimplementing the whole of
> C++, and making my build-times 100 times slower.
>

I can sense you weakening. ;-)

--
James Harris

On 23/11/2021 18:05, James Harris wrote:
> On 09/11/2021 18:33, Bart wrote:
>
> ...
>
>> what exactly is the problem with having SQRT, say, as a built-in
>> function or operator in a language?
>
> As in the "Common operators" thread, SQRT is or can defined as part of
> the type of its operand. For example,
>
>   int a
>   float b
>   complex c
>
>   sqrt(a)  <== invalid, no such function for type int
>   sqrt(b)  <== invokes the float sqrt
>   sqrt(c)  <== invokes the complex sqrt
>
> where
>
>   type float
>     function sqrt
>       ....
>
>   type complex
>     function sqrt
>       ....
>
> and type int has no sqrt function.

SQRT isn't a great example, as it doesn't have a special version for
ints, but let's go with it.

Suppose we implement it via user=code, so we'd start off with these
versions:

function sqrt_f64(f64 x)f64 =
....
end

function sqrt_f32(f32 x)f32 =
....
end

First problem is what to put in place of ....: a loop to do it the hard
way, or a call to a library routine, or maybe inline assembly, so
needing that first item on my list.

Next is that we want to be able to write:

sqrt(x)

and not either sqrt_f32 or sqrt_f64, which means function overloading;
another item (on a previous list I think). This is not an easy feature,
esp. with multiple parameters.

Now it works, the problem is that it generates code that is a call to
sqrt_f32 or sqrt_64; function inlining is needed. So that sqrt(x) is
turned into whatever was the body of the function:

(a) Inline ASM (specifically, sqrt_ss/sqrt_sd x64 instructions)

(b) A call to a library routine

(c) An algorithm.

(a) would probably be OK, but (b) and (c) are going to be awkward to
turn into the same code as (a). (c) would also require a decent
optimiser. Actually, quite difficult /unless/ the compiler has special
knowledege of SQRT. But if it has, then why is it wasting its timing
going through the stages above?

The is a further problem, which is that when you write:

sqrt(9.0)

you really want that turned into the literal 3.0. That might be possible
when the body is (c), and you've implemented 'constexpr', which involves
interpreting the algorithm at compile-time time, in the hope it will
finish in reasonable time.

I can see that you just want to brush all this aside, things I consider
MAJOR language features and that are complex to implement.

With my simple approach, then sqrt(x) is trivially turned into a sqrt_sd
instruction for example, and sqrt(9.0) is turned into 3.0.

Yes it would be nice for a language to be able to do this for arbitrary
user-functions. And if it did, it would be tempting to think about
implementing most of the built-in functions the same way.

Except that it make the language many times harder to implement, and it
would run more slowly (for example needing to interpret user-code via
constexpr all over the place). You'd be implementing a poor version of C++.

On 16/11/2021 00:10, Lasse Hillerøe Petersen wrote:
> On Mon, 15 Nov 2021 21:52:57 +0000, James Harris wrote:
>> On 15/11/2021 14:21, Lasse Hillerøe Petersen wrote:
>>> On Mon, 08 Nov 2021 19:46:35 +0000, James Harris wrote:

....

>>> No. For over half a century, Algol has used a distinct character, and
>>> it has been in Unicode for quite some time: "⏨" (U+23E8) as in 1⏨3.
>>
>> A few things to say to that:
>>
>> * Not all powers are of 10. For example, if the number is in hex then
>> the base might be 16.
>
> All the more reason to use a normal notation with proper superscript.
> 1 KiB = 2¹° B = 4×16² B = 400₁₆

So you'd use "10" as a subscript character for ten, then "1" and "6" as
separate subscript characters for sixteen? Are you serious?

>
> Of course, if you use for example the C notation of 0x prefix (not saying
> it is a good idea) your "hexadecimal scientific notation" should _still_
> use ⏨ - as 0x10 = 16. :-)
>
>> * Accessing Unicode characters can be a challenge - e.g. remembering
>> U+23E8, for example.
>
> Have a character menu in the editor where you can pick them out,

So now programmers need special editors?

> this is
> not a character issue, but a user interface issue.

> Use the correct
> symbols, that's why we have them! I find it strange that normal people
> have _no_ problems using all sorts of weird emojis in text messages on
> their smartphones, but to use well-defined, standard symbols in programs
> is soooo haaaard.

Are you recommending ✕ or × for multiplication? Or should the compiler
accept both?

>
>> * Some Unicode characters look like each other, meaning that code which
>> used them could have a syntax error while looking perfect to a human
>> reader.
>
> Says you, who just suggested to "abuse" the likeness of the lowercase x
> to ×? :-)

Nope. If the text is ASCII there is no likeness to x. See how much
easier it is!

....

>> I'd have your Avogadro's constant as
>>
>> 6.02214076x10^-23
>>
>> which is not too bad, is it?!
>
> In an 8-bit world of ISO-8859-1, I'd find it passable but unsatisfying.

Quite an acceptance! :-)

> But we live in the world where Unicode exists, has nearly all the symbols
> you could ever want, and now seems to be set on a path to revert the
> evolution of writing back to the hieroglyphs of ancient Egypt with
> emojis.

AIUI Unicode has many characters which look like each other but have
different codepoints - such as the different-but-hard-to-tell
multiplication symbols, above. Are you suggesting a compiler accept all
characters which in most fonts look like each other as equivalent?

> I do not advocate going APL

APL would be easy compared with what you are suggesting...!

--
James Harris

On 23/11/2021 19:24, Bart wrote:
> On 23/11/2021 18:05, James Harris wrote:
>> On 09/11/2021 18:33, Bart wrote:

....

> SQRT isn't a great example, as it doesn't have a special version for
> ints, but let's go with it.
>
> Suppose we implement it via user=code, so we'd start off with these
> versions:
>
>     function sqrt_f64(f64 x)f64 =
>         ....
>     end
>
>
>     function sqrt_f32(f32 x)f32 =
>         ....
>     end
>
>
> First problem is what to put in place of ....: a loop to do it the hard
> way, or a call to a library routine, or maybe inline assembly, so
> needing that first item on my list.

Oh, no. I'd literally have the IR able to understand square roots or
raising to the power of 0.5 so the .... in your first example would be
something like

IR.power(f64, x1, x, 0.5)

That would tell the IR stage to create a node in the tree equivalent to

x1 = f64.power(x, 0.5)

>
> Next is that we want to be able to write:
>
>     sqrt(x)
>
> and not either sqrt_f32 or sqrt_f64, which means function overloading;
> another item (on a previous list I think). This is not an easy feature,
> esp. with multiple parameters.

The front end would have to work out whether to use f32 or f64, and it
would enter that in to the tree.

>
> Now it works, the problem is that it generates code that is a call to
> sqrt_f32 or sqrt_64; function inlining is needed. So that sqrt(x) is
> turned into whatever was the body of the function:
>
> (a) Inline ASM (specifically, sqrt_ss/sqrt_sd x64 instructions)
>
> (b) A call to a library routine
>
> (c) An algorithm.
>
> (a) would probably be OK, but (b) and (c) are going to be awkward to
> turn into the same code as (a). (c) would also require a decent
> optimiser. Actually, quite difficult /unless/ the compiler has special
> knowledege of SQRT. But if it has, then why is it wasting its timing
> going through the stages above?

As above, it wouldn't! It'd retain the power(x, 0.5) until later. If
it's still there at codegen time and the target machine had a sqrt
instruction then you could expect that that's what would be emitted.

>
> The is a further problem, which is that when you write:
>
>    sqrt(9.0)
>
> you really want that turned into the literal 3.0. That might be possible
> when the body is (c), and you've implemented 'constexpr', which involves
> interpreting the algorithm at compile-time time, in the hope it will
> finish in reasonable time.
>
> I can see that you just want to brush all this aside, things I consider
> MAJOR language features and that are complex to implement.

No! Things like this would be handled in later stages of the compiler.

>
> With my simple approach, then sqrt(x) is trivially turned into a sqrt_sd
> instruction for example, and sqrt(9.0) is turned into 3.0.

So would mine!

>
>
> Yes it would be nice for a language to be able to do this for arbitrary
> user-functions. And if it did, it would be tempting to think about
> implementing most of the built-in functions the same way.
>
> Except that it make the language many times harder to implement, and it
> would run more slowly (for example needing to interpret user-code via
> constexpr all over the place). You'd be implementing a poor version of C++.

See above. What I am suggesting would push your concerns nearer code
generation. The function of the parser (including pre-supplied and
user-provided type definitions) would be to get the /semantics/ of the
language properly loaded into an IR tree. Then most of the compiler
would perform transformations on that tree.

--
James Harris

On 23/11/2021 23:12, James Harris wrote:
> On 23/11/2021 19:24, Bart wrote:
>> On 23/11/2021 18:05, James Harris wrote:
>>> On 09/11/2021 18:33, Bart wrote:
>
> ...
>
>> SQRT isn't a great example, as it doesn't have a special version for
>> ints, but let's go with it.
>>
>> Suppose we implement it via user=code, so we'd start off with these
>> versions:
>>
>>      function sqrt_f64(f64 x)f64 =
>>          ....
>>      end
>>
>>
>>      function sqrt_f32(f32 x)f32 =
>>          ....
>>      end
>>
>>
>> First problem is what to put in place of ....: a loop to do it the
>> hard way, or a call to a library routine, or maybe inline assembly, so
>> needing that first item on my list.
>
> Oh, no. I'd literally have the IR able to understand square roots or
> raising to the power of 0.5 so the .... in your first example would be
> something like
>
>     IR.power(f64, x1, x, 0.5)
>
> That would tell the IR stage to create a node in the tree equivalent to
>
>   x1 = f64.power(x, 0.5)

So you /would/ have a class of operators which are specially known to
the language and compiler (it has to be both)?

Then that's what I call building them in.

The point of disagreement might then be in where the translation of
sqrt() to SQRT_SD or whatever would occur. (In mine, that is now the
headache of the backend, which needs to implement a 'sqrt' IL instruction.

>>
>> Next is that we want to be able to write:
>>
>>      sqrt(x)
>>
>> and not either sqrt_f32 or sqrt_f64, which means function overloading;
>> another item (on a previous list I think). This is not an easy
>> feature, esp. with multiple parameters.
>
> The front end would have to work out whether to use f32 or f64, and it
> would enter that in to the tree.
>
>>
>> Now it works, the problem is that it generates code that is a call to
>> sqrt_f32 or sqrt_64; function inlining is needed. So that sqrt(x) is
>> turned into whatever was the body of the function:
>>
>> (a) Inline ASM (specifically, sqrt_ss/sqrt_sd x64 instructions)
>>
>> (b) A call to a library routine
>>
>> (c) An algorithm.
>>
>> (a) would probably be OK, but (b) and (c) are going to be awkward to
>> turn into the same code as (a). (c) would also require a decent
>> optimiser. Actually, quite difficult /unless/ the compiler has special
>> knowledege of SQRT. But if it has, then why is it wasting its timing
>> going through the stages above?
>
> As above, it wouldn't! It'd retain the power(x, 0.5) until later. If
> it's still there at codegen time and the target machine had a sqrt
> instruction then you could expect that that's what would be emitted.
>
>>
>> The is a further problem, which is that when you write:
>>
>>     sqrt(9.0)
>>
>> you really want that turned into the literal 3.0. That might be
>> possible when the body is (c), and you've implemented 'constexpr',
>> which involves interpreting the algorithm at compile-time time, in the
>> hope it will finish in reasonable time.
>>
>> I can see that you just want to brush all this aside, things I
>> consider MAJOR language features and that are complex to implement.
>
> No! Things like this would be handled in later stages of the compiler.

But it still needs to be special. Suppose a language had sqrt() but a
user performed an experiment where they created a user-function called
trqs(), perhaps overloaded, which does exactly what sqrt does, except
its body does not make use of sqrt() (so gives no clues as to what it does).

Then, would these pairs of expressions:

sqrt(x)
trqs(x)

sqrt(9.0)
trqs(9.0)

end up generating identical native code? And if they do, how much more
compilation resources would be involving in dealing with trqs rather
than sqrt?

Remember trqs is just one of 1000 user functions.

>>
>> With my simple approach, then sqrt(x) is trivially turned into a
>> sqrt_sd instruction for example, and sqrt(9.0) is turned into 3.0.
>
> So would mine!
>
>>
>>
>> Yes it would be nice for a language to be able to do this for
>> arbitrary user-functions. And if it did, it would be tempting to think
>> about implementing most of the built-in functions the same way.
>>
>> Except that it make the language many times harder to implement, and
>> it would run more slowly (for example needing to interpret user-code
>> via constexpr all over the place). You'd be implementing a poor
>> version of C++.
>
> See above. What I am suggesting would push your concerns nearer code
> generation. The function of the parser (including pre-supplied and
> user-provided type definitions) would be to get the /semantics/ of the
> language properly loaded into an IR tree. Then most of the compiler
> would perform transformations on that tree.

If I write:

sqrt(x)

I get this AST immediately after parsing:

void------ 1 assign:
void------ - 1 name: y nullid
void------ - 2 unary: Pcl<ksqrt>
void------ - - 1 name: x nullid

It doesn't know names or types, but knows it's a square root! If I
instead write:

trqs(x)

I get:

void------ 1 assign:
void------ - 1 name: y nullid
void------ - 2 callfn:
void------ - - 1 name: trqs nullid
void------ - - 2 name: x nullid

It's got a long way to go to match the other.

On 24/11/2021 00:20, Bart wrote:
> On 23/11/2021 23:12, James Harris wrote:
>> On 23/11/2021 19:24, Bart wrote:
>>> On 23/11/2021 18:05, James Harris wrote:
>>>> On 09/11/2021 18:33, Bart wrote:
>>
>> ...
>>
>>> SQRT isn't a great example, as it doesn't have a special version for
>>> ints, but let's go with it.

....

>>> First problem is what to put in place of ....: a loop to do it the
>>> hard way, or a call to a library routine, or maybe inline assembly,
>>> so needing that first item on my list.
>>
>> Oh, no. I'd literally have the IR able to understand square roots or
>> raising to the power of 0.5 so the .... in your first example would be
>> something like
>>
>>      IR.power(f64, x1, x, 0.5)
>>
>> That would tell the IR stage to create a node in the tree equivalent to
>>
>>    x1 = f64.power(x, 0.5)
>
> So you /would/ have a class of operators which are specially known to
> the language and compiler (it has to be both)?

Almost but not quite. The language wouldn't know about any of this
stuff! Think of there being three links in this particular part of the
chain:

language (syntax) --> type definition (semantics) --> IR

The language would define and handle the syntax but would not have a
Scooby Doo about concepts such as floats or square roots!

Knowledge of floats and what "sqrt" means would be in the code for the
float type, and would be user-readable.

The IR would know about (and offer primitives for) floats and powers.
And the type would use the primitives to build the IR tree.

Note that the IR would offer /primitives/. It would not necessarily
offer each function that the type wanted. But each function of the type
would be expressible in terms of the IR's primitives - as in this case.

....

>>> I can see that you just want to brush all this aside, things I
>>> consider MAJOR language features and that are complex to implement.
>>
>> No! Things like this would be handled in later stages of the compiler.
>
>
> But it still needs to be special. Suppose a language had sqrt() but a
> user performed an experiment where they created a user-function called
> trqs(), perhaps overloaded, which does exactly what sqrt does, except
> its body does not make use of sqrt() (so gives no clues as to what it
> does).
>
> Then, would these pairs of expressions:
>
>       sqrt(x)
>       trqs(x)
>
>       sqrt(9.0)
>       trqs(9.0)
>
> end up generating identical native code? And if they do, how much more
> compilation resources would be involving in dealing with trqs rather
> than sqrt?
>
> Remember trqs is just one of 1000 user functions.

Well, as above I would have sqrt effect square root by telling the IR to
raise the operand to the power of 0.5. How would trqs do it?

--
James Harris

On 24/11/2021 07:58, James Harris wrote:
> On 24/11/2021 00:20, Bart wrote:

> The language would define and handle the syntax but would not have a
> Scooby Doo about concepts such as floats or square roots!
>
> Knowledge of floats and what "sqrt" means would be in the code for the
> float type, and would be user-readable.
>
> The IR would know about (and offer primitives for) floats and powers.
> And the type would use the primitives to build the IR tree.

So your language would know about powers, if not square roots?

> Note that the IR would offer /primitives/. It would not necessarily
> offer each function that the type wanted. But each function of the type
> would be expressible in terms of the IR's primitives - as in this case.

>> Remember trqs is just one of 1000 user functions.
>
> Well, as above I would have sqrt effect square root by telling the IR to
> raise the operand to the power of 0.5. How would trqs do it?

OK, so let's say my trqs routine was one of these: (forget overloads for
now):

function trqs_1(real x)real =
pow(x, 0.5) # uses C's pow()
end

function trqs_2(real x)real =
x**0.5 # uses built-in **
end

(Note that ** for floats maps to C's pow() anyway; see below.)

I haven't done a version with the Newton-Raphson method, which I have to
use elsewhere for bignum versions.

I now write this code:

real x,y

y := sqrt(x)
y := sqrt(9.0)

y := trqs_1(x)
y := trqs_2(x)
y := trqs_2(9.0)

The generated assembly right now is as follows. The code for the first
two could both be improved further to just one instruction each, but is
still better than calling those functions:

# y=sqrt(x)
movq XMM4, R.x # R.x (a reg) is simplified
sqrtsd XMM4, XMM4
movq R.y, XMM4

# y=sqrt(3)
movq XMM4, [L24] # L24 contains 3.0
movq R.y, XMM4

# y=trqs_1(x)
movq XMM0, R.x
call t.trqs_1
movq R.y, XMM0

# y=trqs_2(x)
movq XMM0, R.x
call t.trqs_2
movq R.y, XMM0

# y=trqs_2(9.0)
movq XMM0, [L25]
call t.trqs_2
movq R.y, XMM0

#function trqs_1

t.trqs_1:
R.t.trqs_1.x = XMM15
push Dframe
mov Dframe, Dstack
sub Dstack, 48
movq [Dframe-8], R.t.trqs_1.x
movq R.t.trqs_1.x, XMM0
movq XMM0, R.t.trqs_1.x
movq XMM1, [L19] # L19 contains 0.5
call pow*

movq R.t.trqs_1.x, [Dframe-8]
add Dstack, 48
pop Dframe
ret

#function trqs_2
t.trqs_2:
R.t.trqs_2.x = XMM15
push Dframe
mov Dframe, Dstack
sub Dstack, 48
movq [Dframe-8], R.t.trqs_2.x
movq R.t.trqs_2.x, XMM0

movq XMM0, R.t.trqs_2.x
movq XMM1, [L21]
call pow*
movq R.t.trqs_2.x, [Dframe-8]

add Dstack, 48
pop Dframe
ret

The intermediate code for those calls is the following:

push t.x r64
sqrt r64
pop t.y r64

push 3.0000000000000000e+000 r64
pop t.y r64

setargs 1 0
push t.x r64
callfn &t.trqs_1 r64
pop t.y r64

setargs 1 0
push t.x r64
callfn &t.trqs_2 r64
pop t.y r64

setargs 1 0
push 9.0000000000000000e+000 r64
callfn &t.trqs_2 r64
pop t.y r64

(The sqrt(9.0) reduction has already been done. That could have been
handled by the IL backend, but is more limiting.

Doing it earlier means being able to reduce a complete AST
subexpression, eg sqrt(9)*2+17 reduces to 23.0, which is much harder at
the IL level. Also, it means being able to do this among other things:

[sqrt(9)*2+17]int data

Array bounds must be a compile-time expression, and known before the IL
is generated.)

On 24/11/2021 11:23, Bart wrote:
> On 24/11/2021 07:58, James Harris wrote:
>> On 24/11/2021 00:20, Bart wrote:
>
>> The language would define and handle the syntax but would not have a
>> Scooby Doo about concepts such as floats or square roots!
>>
>> Knowledge of floats and what "sqrt" means would be in the code for the
>> float type, and would be user-readable.
>>
>> The IR would know about (and offer primitives for) floats and powers.
>> And the type would use the primitives to build the IR tree.
>
> So your language would know about powers, if not square roots?

No, the language wouldn't know about either. What the language would
know would be expression syntax - but knowledge of what any
subexpressions /mean/ would be contained in the /types/, as in the
example below.

>
>> Note that the IR would offer /primitives/. It would not necessarily
>> offer each function that the type wanted. But each function of the
>> type would be expressible in terms of the IR's primitives - as in this
>> case.
>
>>> Remember trqs is just one of 1000 user functions.
>>
>> Well, as above I would have sqrt effect square root by telling the IR
>> to raise the operand to the power of 0.5. How would trqs do it?
>
>
> OK, so let's say my trqs routine was one of these: (forget overloads for
> now):
>
>   function trqs_1(real x)real =
>       pow(x, 0.5)                         # uses C's pow()
>   end
>
>   function trqs_2(real x)real =
>       x**0.5                              # uses built-in **
>   end

I cannot see how those would add anything to the IR tree. Maybe you have
something else in mind but AISI the type definition which would be run
as part of the front end of the compiler to build the IR tree. The type
definition would not evaluate functions but would, instead, tell the IR
stage what to add to the parse tree. For example,

type float
function trsq(float) -> float
IR.power(0.5)

The IR.power routine would add a power node to the tree.

--
James Harris

On 26/11/2021 16:42, James Harris wrote:
> On 24/11/2021 11:23, Bart wrote:
>> On 24/11/2021 07:58, James Harris wrote:
>>> On 24/11/2021 00:20, Bart wrote:
>>
>>> The language would define and handle the syntax but would not have a
>>> Scooby Doo about concepts such as floats or square roots!
>>>
>>> Knowledge of floats and what "sqrt" means would be in the code for
>>> the float type, and would be user-readable.
>>>
>>> The IR would know about (and offer primitives for) floats and powers.
>>> And the type would use the primitives to build the IR tree.
>>
>> So your language would know about powers, if not square roots?
>
> No, the language wouldn't know about either. What the language would
> know would be expression syntax - but knowledge of what any
> subexpressions /mean/ would be contained in the /types/, as in the
> example below.
>
>>
>>> Note that the IR would offer /primitives/. It would not necessarily
>>> offer each function that the type wanted. But each function of the
>>> type would be expressible in terms of the IR's primitives - as in
>>> this case.
>>
>>>> Remember trqs is just one of 1000 user functions.
>>>
>>> Well, as above I would have sqrt effect square root by telling the IR
>>> to raise the operand to the power of 0.5. How would trqs do it?
>>
>>
>> OK, so let's say my trqs routine was one of these: (forget overloads
>> for now):
>>
>>    function trqs_1(real x)real =
>>        pow(x, 0.5)                         # uses C's pow()
>>    end
>>
>>    function trqs_2(real x)real =
>>        x**0.5                              # uses built-in **
>>    end
>
> I cannot see how those would add anything to the IR tree. Maybe you have
> something else in mind but AISI the type definition which would be run
> as part of the front end of the compiler to build the IR tree. The type
> definition would not evaluate functions but would, instead, tell the IR
> stage what to add to the parse tree. For example,
>
>   type float
>     function trsq(float) -> float
>       IR.power(0.5)
>
> The IR.power routine would add a power node to the tree.

I'm confused: is 'power' here known to the language or not? Or are you
distinguishing between the language visible to the user, and the IR used
by the language implementation?

In the latter case, in which language would IR.power be written? What
appears in the user code?

If I use this example in my user-code:

2.0*pi*sqrt(3.5/9.8)

Then the final AST node is just this:

const: 3.754921 r64

This is even before it gets to the IR, which in my case is linear VM code.

If I use my first trqs version, which emulates a language that doesn't
natively know anything about sqrt or power, then it's the usual AST
containing a call to trqs() which in turn calls an external function
called pow().

Then that reduction is not possible.

On 26/11/2021 18:03, Bart wrote:
> On 26/11/2021 16:42, James Harris wrote:
>> On 24/11/2021 11:23, Bart wrote:
>>> On 24/11/2021 07:58, James Harris wrote:
>>>> On 24/11/2021 00:20, Bart wrote:

....

>>    type float
>>      function trsq(float) -> float
>>        IR.power(0.5)
>>
>> The IR.power routine would add a power node to the tree.
>
> I'm confused: is 'power' here known to the language or not? Or are you
> distinguishing between the language visible to the user, and the IR used
> by the language implementation?

My intended approach is perhaps a bit unusual (as mentioned below) but
still follows the conventional front end, back end model. There could be
any number of front ends (one for each language to be compiled) and
multiple back ends (one for each target machine for which asm is to be
generated). Front ends and back ends are intended to be small and
simple. All the real intelligence in the compiler would be in the IR.

A front end would check legality of the source code and implement

source --> IR

such that the IR becomes a structured version of the source program. All
kinds of transformations would be applied to the IR. Then whatever back
end was being used would implement

IR --> asm

The IR is intended to be independent of any source language. It would
include a range of primitives such as addition, power, trig functions
etc for basic (scalar) types: ints, floats, and maybe a few others.

Given that, to answer your question my /language/ would essentially know
nothing about floats or powers or trig functions, etc. What the language
would understand, however, would be syntax. So in

a + b * c ** d

the language would know from precedence rules that c ** d had to be
executed first but it wouldn't know what ** meant. So how would that be
converted to a power operation? If c and d were floats then you could
imagine that the type float would have a definition for ** which took
two floats as input and produced a float as output, i.e.

**(float, float) --> float

The definition would invoke the IR routine using the IR.power()
statement I showed earlier. You could think of that as telling the IR to
add a node to the tree to raise the 'current value' to the power inside
the parens and make the result the new 'current value'. To be clear, the
IR would not do any calculations at that point. All it would do would be
to add a node to the tree.

Can you see from that how:

1. the language would know nothing about powers

2. the type float would know what a power was

3. the IR would know what a float power was, at least in principle

?

>
> In the latter case, in which language would IR.power be written?

IR.power could be written in whatever language the rest of the IR
routines were written in. It wouldn't matter too much what it was.
Anything convenient would do as long as it implemented the same calling
convention as the routines it had to interact with. But that's not
surprising. All that IR.power would need to do would be to add a node to
a tree which was being built to represent the source being compiled. It
would not have to do anything clever.

> What
> appears in the user code?

If by user code you mean the source to be compiled by the above scheme
then it could be just as you say below using sqrt. The /type/ float is
what would know that sqrt meant power(0.5).

>
> If I use this example in my user-code:
>
>     2.0*pi*sqrt(3.5/9.8)
>
> Then the final AST node is just this:
>
>     const: 3.754921 r64
>
> This is even before it gets to the IR, which in my case is linear VM code.

Essentially, mine should generate the same output. The only differences
would be that I would have the front end load the bare expression into
the IR, and the constant expression would be resolved by transformations
on the IR. AISI it's better to put such optimisations in the 'middle
end' as they can apply to a wider number of situations.

>
> If I use my first trqs version, which emulates a language that doesn't
> natively know anything about sqrt or power, then it's the usual AST
> containing a call to trqs() which in turn calls an external function
> called pow().
>
> Then that reduction is not possible.

Once the IR tree is built then in a node such as power(0.5) the 0.5
could be recognised as meaning square root. If the target machine's
square root instruction is faster than its power instruction then a sqrt
instruction could be emitted.

--
James Harris

On 26/11/2021 21:34, James Harris wrote:
> On 26/11/2021 18:03, Bart wrote:

>> I'm confused: is 'power' here known to the language or not? Or are you
>> distinguishing between the language visible to the user, and the IR
>> used by the language implementation?
>
> My intended approach is perhaps a bit unusual (as mentioned below) but
> still follows the conventional front end, back end model. There could be
> any number of front ends (one for each language to be compiled) and
> multiple back ends (one for each target machine for which asm is to be
> generated). Front ends and back ends are intended to be small and
> simple. All the real intelligence in the compiler would be in the IR.
>
> Given that, to answer your question my /language/ would essentially know
> nothing about floats or powers or trig functions, etc. What the language
> would understand, however, would be syntax. So in
>
>   a + b * c ** d
>
> the language would know from precedence rules that c ** d had to be
> executed first but it wouldn't know what ** meant. So how would that be
> converted to a power operation? If c and d were floats then you could
> imagine that the type float would have a definition for ** which took
> two floats as input and produced a float as output, i.e.
>
>   **(float, float) --> float
>
> The definition would invoke the IR routine using the IR.power()

Wait - where is this definition, somewhere inside the front end or back
end? As it seems that somewher in the language implementation is the
knowledge that ** must mean exponentiation.

> statement I showed earlier. You could think of that as telling the IR to
> add a node to the tree to raise the 'current value' to the power inside
> the parens and make the result the new 'current value'. To be clear, the
> IR would not do any calculations at that point. All it would do would be
> to add a node to the tree.
>
> Can you see from that how:
>
> 1. the language would know nothing about powers
>
> 2. the type float would know what a power was

That doesn't make sense. You say the language has a bunch of operators,
say A B C D E, with no assigned meaning except it knows that they're
operators, the number of operands (?), that they are infix, and their
relative precedences.

But then another part of the implementation decides that E with float
operands should mean power.

Well, it looks like in the end it all comes down to the same thing, if
you can get the same results, at least with x ** y, even if you like to
pretend the language is unaware of the meaning of ** (I hope the
language docs say something about it, other than it's a handy
coincidence that it ends up as 'power'!)

At least that one doesn't need expressing in user code, which would
require more effort to reduce to a single IR operation, if the start
point is a call to a user-defined function which contains multiple IR ops.

>> If I use this example in my user-code:
>>
>>      2.0*pi*sqrt(3.5/9.8)
>>
>> Then the final AST node is just this:
>>
>>      const: 3.754921 r64
>>
>> This is even before it gets to the IR, which in my case is linear VM
>> code.
>
> Essentially, mine should generate the same output. The only differences
> would be that I would have the front end load the bare expression into
> the IR, and the constant expression would be resolved by transformations
> on the IR. AISI it's better to put such optimisations in the 'middle
> end' as they can apply to a wider number of situations.

It sounds like your IR is at roughly the level of what I call AST3 - a
name-resolved/type-processed AST just awaiting conversion to linear code.

Because in linear code, it's harder to reduce a more elaborate
expression like my example.

> A front end would check legality of the source code and implement
>
> source --> IR
>
> such that the IR becomes a structured version of the source program. All
> kinds of transformations would be applied to the IR. Then whatever back
> end was being used would implement
>
> IR --> asm
>
> The IR is intended to be independent of any source language. It would
> include a range of primitives such as addition, power, trig functions
> etc for basic (scalar) types: ints, floats, and maybe a few others.
>

Actually this is exactly the change I made earlier this year. The IR (a
stack-based VM for me), was given a syntax, and could exist in discrete
files, with a separate program used to perform the translate to binary.

Except that, while intended to be portable, I only have one proper
target. (A linear C target, while it could just about work, was
abandoned.) Example:

C:\ax>mm -pcl aa
Compiling aa.m---------- to aa.pcl

C:\ax>pc aa
Processing aa.pcl to aa.exe

In practice, the main part of the 'pc' program is incorporated into
'mm', to that mm usually directly generates .exe files. Either product
can also generate .asm if necessary.

Making this separation was a lot header than it seemed at first!

On 27/11/2021 00:25, Bart wrote:
> On 26/11/2021 21:34, James Harris wrote:
>> On 26/11/2021 18:03, Bart wrote:
>
>>> I'm confused: is 'power' here known to the language or not? Or are
>>> you distinguishing between the language visible to the user, and the
>>> IR used by the language implementation?
>>
>> My intended approach is perhaps a bit unusual (as mentioned below) but
>> still follows the conventional front end, back end model. There could
>> be any number of front ends (one for each language to be compiled) and
>> multiple back ends (one for each target machine for which asm is to be
>> generated). Front ends and back ends are intended to be small and
>> simple. All the real intelligence in the compiler would be in the IR.
>>
>> Given that, to answer your question my /language/ would essentially
>> know nothing about floats or powers or trig functions, etc. What the
>> language would understand, however, would be syntax. So in
>>
>>    a + b * c ** d
>>
>> the language would know from precedence rules that c ** d had to be
>> executed first but it wouldn't know what ** meant. So how would that
>> be converted to a power operation? If c and d were floats then you
>> could imagine that the type float would have a definition for ** which
>> took two floats as input and produced a float as output, i.e.
>>
>>    **(float, float) --> float
>>
>> The definition would invoke the IR routine using the IR.power()
>
> Wait - where is this definition, somewhere inside the front end or back
> end? As it seems that somewher in the language implementation is the
> knowledge that ** must mean exponentiation.

The definition if IR.power would be part of the IR module.

Maybe it would be clearer if I were to go through the translation steps.
The goal is to make it easy for programmers to define their own types as
it is to define standard ones. And by a 'type' I essentially mean a
collection of functions.

Consider compiling source code which has both the ** operator and a call
to the sqrt function as in

r ** 2.0
sqrt(r)

1. The /language/ would know the precedence etc of ** but it would not
know what it meant. The language would also recognise that sqrt(....)
was a function call but, again, the language would have no idea what
sqrt meant.

2. If we say that r is of type float then the compiler would check where
type float was defined and would find some code like the following.

type float
function **(float a, float b)
IR.power(float, a, b)
function-end

function sqrt(float a)
IR.power(float, a, 0.5)
function-end

.... other such functions ....
type-end

Note that that defines what ** and sqrt mean by invoking a suitable
routine, in each case, in the IR module.

3. The IR routine IR.power would add a node to the parse tree.

To recap, the language would know the precedence etc of operators and
the form of function calls, the type would know what such operators or
functions mean, and the IR would contain the routines which build and
manipulate the intermediate representation of the code.

>
>
>> statement I showed earlier. You could think of that as telling the IR
>> to add a node to the tree to raise the 'current value' to the power
>> inside the parens and make the result the new 'current value'. To be
>> clear, the IR would not do any calculations at that point. All it
>> would do would be to add a node to the tree.
>>
>> Can you see from that how:
>>
>> 1. the language would know nothing about powers
>>
>> 2. the type float would know what a power was
>
> That doesn't make sense. You say the language has a bunch of operators,
> say A B C D E, with no assigned meaning except it knows that they're
> operators, the number of operands (?), that they are infix, and their
> relative precedences.

Yes.

>
> But then another part of the implementation decides that E with float
> operands should mean power.

It depends on what you call "the implementation". The language would not
know what sqrt meant but if the type of its operand was T then the
compiler would look in the definition of T to find a function called
sqrt. IOW it would expect to see

type T
function sqrt....

The important thing here is that type T could be supplied with the
language like a standard library or the programmer could write his own
types. For example, if the language extension is xx the float type could
be defined in a file called

type_float.xx

>
> Well, it looks like in the end it all comes down to the same thing, if
> you can get the same results, at least with x ** y, even if you like to
> pretend the language is unaware of the meaning of ** (I hope the
> language docs say something about it, other than it's a handy
> coincidence that it ends up as 'power'!)

Yes, it would achieve the normal outcome but it would allow users to
deploy the same mechanisms to write their own types. For example, say
that as a programmer I wanted to write a complexf type which used floats
as its components. I could start it with something like

type complexf
function +(complexf a, complexf b)
IR.add(float, a.re, b.re)
IR.add(float, a.im, b.im)

The actual form would be a bit more wordy than that but it hopefully
illustrates the basic idea.

>
> At least that one doesn't need expressing in user code, which would
> require more effort to reduce to a single IR operation, if the start
> point is a call to a user-defined function which contains multiple IR ops.

The IR would support many operations but they would all be primitives
from which other operations could be built - as in the example of the IR
not understanding sqrt but it understanding power, an operation in which
square root can be expressed.

--
James Harris

On 09/11/2021 11:36, Bart wrote:
> 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 0x100.1
>     println 2x100.1
>     println 4x100.1
.....

I've had to remove literal support for bases other than 2, 10, 16 in my
dynamic language, for integers, and bases other than 10 for floats.

I was refactoring code, and it was just too fiddly.

This is about direct compiler support for such literals; they will still
be available via library functions (TODO). Output in such bases (which
is more useful) will stay.

Support will now be:

Numeric literals in source code:

i64, u64 base 10, 2 and 16 (as 100, 2x100, and 0x100 only)
f64 base 10 only (may rely on strtod())
decimal (float) base 10 only
decimal (int) base 10 only, base 2 and 16 TODO

('Decimal' (my bignum type) literal processing is done at runtime anyway)

Printing numbers via Print, reading via Read:

i64, u64 base 2 to 16 (Print)
i64, u64 base 10, 2, 16 (Read; other bases TODO)
f64 base 10 only (may rely on ssprintf)
decimal (float) base 10 only
decimal (int) base 10 only, base 2 and 16 or other bases: TODO

My static language needs has full support, but it may need to be changed
to match.)