On 24/08/2021 20:19, Dmitry A. Kazakov wrote:
> On 2021-08-24 18:29, Bart wrote:
>> On 24/08/2021 16:47, Dmitry A. Kazakov wrote:
>
>>> Is your print interoperable with GTK or Windows GDI or ...?
>>
>> Sure:
>>
>>    a:=100
>>    b:=201.3
>>
>>    messagebox(mess:sprint(a,b))
>
> That does not look like print.
>

'print a,b,c' or 'print @dest,a,b,c' is a statement; it send its output
to console or dest, and doesn't return a value.

'sprint(a,b,c)' is the same thing but with function-like syntax. It
accumulates its output to a string, and returns that string.

A bit Ada's 'Image, but that corresponds more with my 'tostring' which
converts one expression at a time. print/sprint does a whole list, and
applies tostring automatically.

My static language doesn't have sprint. To write into a string, I have
to use @, as in 'print @str,a,b,c', then str contains generated text.

On 24/08/2021 18:09, Bart wrote:
> On 24/08/2021 15:38, Bart wrote:
>
>> In my very limited experience of Ada it probably took half an hour
>> just to figure out how to print an integer variable.
>>
>> In any language of mine, to print X, you say: print X.
>>
>> What's the equivalent in Ada
>
> I took a short-cut by looking through Rosetta Code examples.
>
> Provided you start with this:
>
>     with Ada.Text_IO; use Ada.Text_IO;
>
> then printing 2 numbers involves simply:
>
>     Put(Integer'Image(A) & " " & Integer'Image(B));
>
> Yikes! Apparently one quirk is that when A or B is positive, it writes a
> leading space, but not when negative.
>
> When A and B are floats, then you have to use Float'Image instead.
>
> Remember my two current languages just require:
>
>     print A, B
>
> /whatever/ the types of A and B, provided 'tostring' is defined by the
> language.
>
> (I also notice that Ada's Integer type appears to be int32; maybe that
> explains your (DAK's) attitute towards int64.)

I read somewhere (but can't find the reference or quotation) that the
strength of a programming language comes not from the features it has,
but the restrictions it has. Ada is considered a relatively safe
language, suitable for high reliability and safety-critical systems
because of its restrictions - it tries to make it hard to do the wrong
thing. You need to know what you are doing, or the code won't compile.
If you want to print "A", you need to know the type of A, and you need
to know the type required by the "Put" function, and you need to know
how to convert between them. Mistakes are likely to show up as compile
failures, or in code reviews (as the details are given explicitly),
rather than relying on luck of testing.

There are appropriate uses for different kinds of language. Languages
like yours aim to be fast and easy to write, but lack safety - you get
that in something like Python. Languages like Ada (or its more extreme
subset, SPARK) are aimed at safety and reliability, not speed of
development. The joke about Ada programming is that if you can get it
to compile, it's ready to ship - that would actually be the ideal situation.

On 24/08/2021 16:37, Bart wrote:
> On 24/08/2021 15:35, James Harris wrote:
>> On 24/08/2021 12:01, Bart wrote:
>
>> There's no contradiction. I wasn't saying to parse headers but to run
>> C code such as
>>
>>    void main(void) {
>>      printf("barttype pid_t = u%i\n", sizeof(pid_t) * CHAR_BIT);
>>    }
>>
>> instead of a traditional configuration step.
>
> So, let's say that that tells me that pid_t /in this C implementation/

It's meant to be run on the /target/ implementation (which is no
different from any configuration program or script).

> is "u32" (as you're assuming unsigned here!).

It shouldn't be too difficult to determine signedness. The mechanism
could even be wrapped in a macro and reused for other fields.

....

> But that's only part of it. Say you need to be able construct a 'struct
> stat' in your language; for that you need to sizes and offsets of all
> the members, so as to be able to allocate the right space, and to be
> able to access members.
>
> Where to get the list of members? 'man struct stat' lists the types as:
>
>  dev_t ino_t mode_t nlink_t uid_t gid_t dev_t off_t blksize_t
>  blksize_t blkcnt_t
>
> You've already lost the will to live!

See below!

I agree that it would be nicer to have a master config file from which
we could generate such a struct for each language. But it's also true
that that config file would have to be expressed in a language of some
sort, even if that language is easier to parse.

In human terms I expect that people around the world wish that documents
were written in a language other than English. Perhaps Esperanto. But
English has become dominant, as has C.

English is quirky, as is C.

At least C can be parsed, even if not easily.

....

> My C compiler has its own simpler version of struct stat (I posted
> that). If I get that compiler to generate an import file suitable for my
> language, I get this:
>
>     record _stat = $caligned
>         u32 st_dev
>         u16 st_ino
>         u16 st_mode
>         i16 st_nlink
>         i16 st_uid
>         i16 st_gid
>         u32 st_rdev
>         u32 st_size
>         u64 st_atime
>         u64 st_mtime
>         u64 st_ctime
>     end
>
> This is for the same Win64 platform/msvcrt.dll library.

Different environments have different stat structures. Worse, some
header files describe different versions of such a structure depending
on environmental variables leading to dreaded C preprocessor #if
clauses. That makes the headers hard to parse.

However, the C ecosystem can help. If I have a file with

#include <sys/stat.h>

and I preprocess it with

cc -E

then I get

struct stat
{
__dev_t st_dev;
__ino_t st_ino;
__nlink_t st_nlink;
__mode_t st_mode;
__uid_t st_uid;
__gid_t st_gid;
int __pad0;
__dev_t st_rdev;
__off_t st_size;
__blksize_t st_blksize;
__blkcnt_t st_blocks;
struct timespec st_atim;
struct timespec st_mtim;
struct timespec st_ctim;
__syscall_slong_t __glibc_reserved[3];
};

That's not too bad, is it?

BTW, I would hope your stat structure, above, is not manually created.
That could lead to inconsistencies. I'd suggest to create it each time
it's needed. (A copy once created could be cached, however.)

>
> Even though this is not C, which would you rather use as a reference for
> your own version of this record? Which would take less time than mucking
> about tracking down even the types of the members, and running trial and
> error programs?
>
> BTW did you manage to put together a struct stat equivalent for your
> language?

No, your development is far beyond mine.

--
James Harris

On 24/08/2021 12:20, Bart wrote:
> On 24/08/2021 12:01, Bart wrote:
>
>> For me, because I've already had to do the hard work of putting
>> together a definition of struct stat for my C compiler's headers, my
>> version of it is relatively straightforward:
>>
>> struct _stat {
>>      unsigned int    st_dev;
>>      unsigned short  st_ino;
>>      unsigned short  st_mode;
>>      short           st_nlink;
>>      short           st_uid;
>>      short           st_gid;
>>      unsigned long   st_rdev;
>>      unsigned int    st_size;
>>      unsigned long long int  st_atime;
>>      unsigned long long int  st_mtime;
>>      unsigned long long int  st_ctime;
>> };
>>
>> [This is for Windows where short, int, long, long long are i16, i32,
>> i32, i64 respectively.]
>
>
> There is still a gotcha here: because of C struct alignment rules (now
> an /optional/ part of the ABI I believe), there is a hidden 'short'
> member between st_gid and st_rdev to provide 2 bytes of padding.

Maybe the gotcha is there because you produced the above manually? In
the reply I just posted I got the C compiler to generate the struct and
it included in the definition

int __pad0;

--
James Harris

On 25/08/2021 20:21, James Harris wrote:
> On 24/08/2021 12:20, Bart wrote:
>> On 24/08/2021 12:01, Bart wrote:
>>
>>> For me, because I've already had to do the hard work of putting
>>> together a definition of struct stat for my C compiler's headers, my
>>> version of it is relatively straightforward:
>>>
>>> struct _stat {
>>>      unsigned int    st_dev;
>>>      unsigned short  st_ino;
>>>      unsigned short  st_mode;
>>>      short           st_nlink;
>>>      short           st_uid;
>>>      short           st_gid;
>>>      unsigned long   st_rdev;
>>>      unsigned int    st_size;
>>>      unsigned long long int  st_atime;
>>>      unsigned long long int  st_mtime;
>>>      unsigned long long int  st_ctime;
>>> };
>>>
>>> [This is for Windows where short, int, long, long long are i16, i32,
>>> i32, i64 respectively.]
>>
>>
>> There is still a gotcha here: because of C struct alignment rules (now
>> an /optional/ part of the ABI I believe), there is a hidden 'short'
>> member between st_gid and st_rdev to provide 2 bytes of padding.
>
> Maybe the gotcha is there because you produced the above manually?

The gotcha is because of C alignment rules as I said. Unless your own
language uses exactly the same rules for padding as C, then the offsets
will be wrong.

In
> the reply I just posted I got the C compiler to generate the struct and
> it included in the definition
>
>     int __pad0;

No, that's nothing that got inserted by the -E flag. That is, unusually,
an explicit padding field. On my RPI4, delving deep into the system
headers, I get the version of struct stat shown below.

If I try the -E flag on Windows, then I get 5 variations of struct stat
(stati64 etc) inside a 700-line output file.

On RPI4, I get 300-400 lines with only 2 variations.

But notice the version below uses __dev_t. With that -E output, that's
defined with this typedef:

typedef __dev_t dev_t;

__dev_t is defined with:

__extension__ typedef __u_guard_t __dev_t;

__u_guard_t is defined with:

__extension__ typedef long long int __guard_t;

I guess that makes it i64. But why 3 levels of typedef instead just 1?
Why not 6 for good measure?!

In any case, getting the actual list of members and types is just the
start point. (Although the -E method, provided you choose a C compiler
matching the same environment as your language, will remove some of
those conditionals.)

>> BTW did you manage to put together a struct stat equivalent for your
language?

>No, your development is far beyond mine.

But you can still do the exercise on paper, or try to recreate a
duplicate struct using only the u/intN_t types of C.

For a small extra challenge, use #pragma pack(1) for that struct, so
that padding is not automatically inserted. That's how my languages
worked until I added the $caligned attribute.

My problem also is that I do not want to HAVE to use a C compiler, out
of principle.

I have a binary DLL on one hand, and my language on the other where I'm
itching to write some bindings in my syntax for functions I want to use.

The info I need may be online, or it may be as C headers which are
/supposed/ to be human readable. I do not want to be delving into
obscure locations to find the headers, then I find the sort of mess of
which the one below is a very mild example.

With more complex libraries too, just running a compiler with the line:

#include <gtk/gtk.h>

is challenging, as there are hundreds nested headers and you need to
tell the compiler where they all are. You need something called
pkgconfig or some such thing, at least nothing that ever works on Windows.

It's always something that keeps drawing you in to this giant rabbit
hole that is the world of C and C compilers and C headers and C compiler
options and C macros and C makefiles and C everything.

I'm really not interested (I'm trying to simplify!). Just me give some
function signatures with universal types so that I don't need to involve
C at all.

----------------------------------------------------------
struct stat
{
__dev_t st_dev; /* Device. */
unsigned short int __pad1;
#ifndef __USE_FILE_OFFSET64
__ino_t st_ino; /* File serial number. */
#else
__ino_t __st_ino; /* 32bit file serial number. */
#endif
__mode_t st_mode; /* File mode. */
__nlink_t st_nlink; /* Link count. */
__uid_t st_uid; /* User ID of the file's owner. */
__gid_t st_gid; /* Group ID of the file's group.*/
__dev_t st_rdev; /* Device number, if device. */
unsigned short int __pad2;
#ifndef __USE_FILE_OFFSET64
__off_t st_size; /* Size of file, in bytes. */
#else
__off64_t st_size; /* Size of file, in bytes. */
#endif
__blksize_t st_blksize; /* Optimal block size for I/O. */

#ifndef __USE_FILE_OFFSET64
__blkcnt_t st_blocks; /* Number 512-byte blocks allocated. */
#else
__blkcnt64_t st_blocks; /* Number 512-byte blocks allocated. */
#endif
#ifdef __USE_XOPEN2K8
/* Nanosecond resolution timestamps are stored in a format
equivalent to 'struct timespec'. This is the type used
whenever possible but the Unix namespace rules do not allow the
identifier 'timespec' to appear in the <sys/stat.h> header.
Therefore we have to handle the use of this header in strictly
standard-compliant sources special. */
struct timespec st_atim; /* Time of last access. */
struct timespec st_mtim; /* Time of last modification. */
struct timespec st_ctim; /* Time of last status change. */
# define st_atime st_atim.tv_sec /* Backward compatibility. */
# define st_mtime st_mtim.tv_sec
# define st_ctime st_ctim.tv_sec
#else
__time_t st_atime; /* Time of last access. */
unsigned long int st_atimensec; /* Nscecs of last access. */
__time_t st_mtime; /* Time of last modification. */
unsigned long int st_mtimensec; /* Nsecs of last modification. */
__time_t st_ctime; /* Time of last status change. */
unsigned long int st_ctimensec; /* Nsecs of last status change. */
#endif
#ifndef __USE_FILE_OFFSET64
unsigned long int __glibc_reserved4;
unsigned long int __glibc_reserved5;
#else
__ino64_t st_ino; /* File serial number. */
#endif
};

------------------------------------------------------------------

Someone using my languages will do the following to get the size of a
file, where f is a file handle as returned by fopen (any pointer type
will do):

-------- static language -----------
import mlib
size := getfilesize(f)

-------- dynamic language ----------
size := getfilesize(f)

Both return an int64 type for the type (but currently capped at u32
because they are implemented on top of 32-bit functions).

However, this stuff should be that simple. Why dozens of different types
just to get basic file info? (There were 4 involved with dev_t, but 10
different types for the members of struct stat, times 4, is 40!)

On 2021-08-26 00:07, Bart wrote:

> My problem also is that I do not want to HAVE to use a C compiler, out
> of principle.
>
> I have a binary DLL on one hand, and my language on the other where I'm
> itching to write some bindings in my syntax for functions I want to use.

And nobody cared to separate interface from implementation (like you),
so all internal mess of meaningless structures have got exposed...

> The info I need may be online, or it may be as C headers which are
> /supposed/ to be human readable.

Where did you get that? C headers are supposed to be cryptic,
treacherous and unforgiving.

> I do not want to be delving into
> obscure locations to find the headers, then I find the sort of mess of
> which the one below is a very mild example.

That is per design. The mantra is: any competent C programmer...

This is not just C. It is a common attitude. If you looked at network
protocol standards you would be wondered how inventive people are in
preventing the reader to learn the layout of the packets. They deploy
special data definition languages, sometimes several on top of each
other, in order to hide that sensitive information from you...

> With more complex libraries too, just running a compiler with the line:
>
>   #include <gtk/gtk.h>
>
> is challenging, as there are hundreds nested headers and you need to
> tell the compiler where they all are. You need something called
> pkgconfig or some such thing, at least nothing that ever works on Windows.

GTK (actually GObject) is a perfect lesson for you and James. It tries
to implement object-oriented classes on top of low-level C. The result
is what see.

> It's always something that keeps drawing you in to this giant rabbit
> hole that is the world of C and C compilers and C headers and C compiler
> options and C macros and C makefiles and C everything.

And that is a lesson for our dear employers. If you hired a couple of
geeks, you cannot trust any work to, fire them. Never ever give them a
spare machine. They might invent C and UNIX!

> However, this stuff should be that simple. Why dozens of different types
> just to get basic file info? (There were 4 involved with dev_t, but 10
> different types for the members of struct stat, times 4, is 40!)

Because there are dozens of different entities involved. Welcome back to
reality.

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

On 26/08/2021 09:33, Dmitry A. Kazakov wrote:
> On 2021-08-26 00:07, Bart wrote:
>
>> My problem also is that I do not want to HAVE to use a C compiler, out
>> of principle.
>>
>> I have a binary DLL on one hand, and my language on the other where
>> I'm itching to write some bindings in my syntax for functions I want
>> to use.
>
> And nobody cared to separate interface from implementation (like you),
> so all internal mess of meaningless structures have got exposed...
>
>> The info I need may be online, or it may be as C headers which are
>> /supposed/ to be human readable.
>
> Where did you get that? C headers are supposed to be cryptic,
> treacherous and unforgiving.

They certainly can be - but they can also be human readable. It is
common that for small libraries or pieces of code, headers are clear
enough that they provide the main information about how to use the code.

On the other hand, for larger libraries and especially libraries that
are intended to be portable across a range of systems, C (and C++)
versions, integer sizes, operating systems, compilers, processors, etc.,
the headers are going to be unreadable. The headers are, in effect, and
automatic configuration system to match the compiler's needs. Users are
expected to read the documentation provided in other formats, and use
the library according to that documentation (such as using the types
specified, not trying to guess what other types might be the same size).

In between, there are headers where the C code is a bit too messy to be
human readable as it is, but the header contains doxygen comments so
that user documentation is generated automatically as a combination of
the code and manually-written documentation.

>
>> I do not want to be delving into obscure locations to find the
>> headers, then I find the sort of mess of which the one below is a very
>> mild example.
>
> That is per design. The mantra is: any competent C programmer...
>
> This is not just C. It is a common attitude. If you looked at network
> protocol standards you would be wondered how inventive people are in
> preventing the reader to learn the layout of the packets. They deploy
> special data definition languages, sometimes several on top of each
> other, in order to hide that sensitive information from you...
>

I don't think it is often done to hide information. It is just that
different documents (including headers) provide different levels of
detail for different people. The RFC's for TCP/IP are complicated, but
are needed for people writing network stacks - people /using/ TCP/IP in
their code need a very different level of documentation. Similarly,
system library headers provide information for the /compiler/, while
programmers get their information from the documentation.

>
>> However, this stuff should be that simple. Why dozens of different
>> types just to get basic file info? (There were 4 involved with dev_t,
>> but 10 different types for the members of struct stat, times 4, is 40!)
>
> Because there are dozens of different entities involved. Welcome back to
> reality.
>

Bart doesn't like that reality. He wants a reality where everything is
designed to suit his convenience, and is fine-tuned for the systems he
uses and nothing else.

On 2021-08-26 10:29, David Brown wrote:

> In between, there are headers where the C code is a bit too messy to be
> human readable as it is, but the header contains doxygen comments so
> that user documentation is generated automatically as a combination of
> the code and manually-written documentation.

How I hate that sort of "documentation."

But regarding C headers, once upon a time there existed now completely
forgotten language design principle that the program should be all
documentation you needed.

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

On 26/08/2021 08:33, Dmitry A. Kazakov wrote:
> On 2021-08-26 00:07, Bart wrote:
>
>> My problem also is that I do not want to HAVE to use a C compiler, out
>> of principle.
>>
>> I have a binary DLL on one hand, and my language on the other where
>> I'm itching to write some bindings in my syntax for functions I want
>> to use.
>
> And nobody cared to separate interface from implementation (like you),
> so all internal mess of meaningless structures have got exposed...

If someone creates a library to be used via an FFI (or even in the same
language!), then they can choose to create a more suitable interface
that only exposes what is essential.

But I don't care; I just want something that works. I want being able to
use such a library to be routine, not a challenge that will need
time-consuming, ad hoc, hit and miss approaches that may or may not succeed.

>> The info I need may be online, or it may be as C headers which are
>> /supposed/ to be human readable.
>
> Where did you get that? C headers are supposed to be cryptic,
> treacherous and unforgiving.

Too many seem to show the messy, inner workings of the implementation
that you usually want hidden away. Great; imagine if you had delve
inside the compiler sources of language X in order to use any of its
libraries.

>> I do not want to be delving into obscure locations to find the
>> headers, then I find the sort of mess of which the one below is a very
>> mild example.
>
> That is per design. The mantra is: any competent C programmer...

C shouldn't come into it at all. A 'C type system' isn't really a type
system, but just a thin layer over the underlying hardware.

Actually it works hard to obscure those underlying types without adding
anything useful.

At least the primitive hardware-oriented types - based around u8-u64,
i8-i64, f32-f64 - would actually have been much more straightforword to
use via an FFI.

C just provides obfuscation. The binary library might have been written
in C, but so what? Now it is in binary!

> This is not just C. It is a common attitude. If you looked at network
> protocol standards you would be wondered how inventive people are in
> preventing the reader to learn the layout of the packets. They deploy
> special data definition languages, sometimes several on top of each
> other, in order to hide that sensitive information from you...
>
>> With more complex libraries too, just running a compiler with the line:
>>
>>    #include <gtk/gtk.h>
>>
>> is challenging, as there are hundreds nested headers and you need to
>> tell the compiler where they all are. You need something called
>> pkgconfig or some such thing, at least nothing that ever works on
>> Windows.
>
> GTK (actually GObject) is a perfect lesson for you and James. It tries
> to implement object-oriented classes on top of low-level C. The result
> is what see.

The result is a monstrous library that I wouldn't want to use anyway
even if it could be used via an FFI with no problems at all. (It was
just a challenging library to try out my conversion software on.)

Imagine arranging to distribute or remotely installing 28 DLL binaries,
all with elaborate filenames that are not even fixed; they will vary by
version.

>> However, this stuff should be that simple. Why dozens of different
>> types just to get basic file info? (There were 4 involved with dev_t,
>> but 10 different types for the members of struct stat, times 4, is 40!)
>
> Because there are dozens of different entities involved. Welcome back to
> reality.

But there aren't. This is not part of a directory structure that is
stored on disk so the size is sensitive because there might be 1 millon
files.

They might be a dozen files that are open by an application, but it's
not even that.

You make a call to the FS routines to access a collection of data about
ONE file. Does it matter if the returned info is 48 bytes or 96? Because
it will then be discarded or reused.

Why return that info all in one lump anyway: have multiple routines, or
provide a parameter to choose the specific attribute you need.

That info can just be a 64-bit integer for each piece of data; it's just
a number (didn't you say above that you shouldn't expose the inner
workings?). You don't need to complicate matters with multiple types.

In any case, what is the point of hiding int64 under 'long long int', of
hiding long long int under '__u_guard_t', of hiding __u_guard_t under
'__dev_t', of hiding __dev_t under 'dev_t'?

Don't tell that is good programming even under Ada! Don't forget this is
defining just one field of that struct.

On 26/08/2021 10:45, Dmitry A. Kazakov wrote:
> On 2021-08-26 10:29, David Brown wrote:
>
>> In between, there are headers where the C code is a bit too messy to be
>> human readable as it is, but the header contains doxygen comments so
>> that user documentation is generated automatically as a combination of
>> the code and manually-written documentation.
>
> How I hate that sort of "documentation."

Like anything else, it can be done well or it can be done badly. If
it's just a list of the same thing you get by looking at the headers
directly, it's not much use. But if it contains complementary
information, examples, etc., then it means you've got an accurate
reference that matches the actual code, and the developers keep it all
up to date in the same place.

As an example, look at <http://www.nongnu.org/avr-libc/user-manual/>

>
> But regarding C headers, once upon a time there existed now completely
> forgotten language design principle that the program should be all
> documentation you needed.
>

That principle never worked - it was always a misconception.

The correct principle is never put in comments things that can equally
well be expressed in code.

But no programming language can express everything. (Some do better
than others, obviously.) And the source code can be in a different
language from the one the programmer is using, or simply a very
different kind of programming.

On 26/08/2021 09:29, David Brown wrote:
> On 26/08/2021 09:33, Dmitry A. Kazakov wrote:

>> Because there are dozens of different entities involved. Welcome back to
>> reality.
>>
>
> Bart doesn't like that reality. He wants a reality where everything is
> designed to suit his convenience, and is fine-tuned for the systems he
> uses and nothing else.

I want a reality which suits anyone, not just those using C.

That means not being so C-centric in every single aspect.

SDL is one of the smaller and better libraries (but it's still 80
headers at least).

The on-line docs are pretty good. However one parameter to do with
rectangles has the type SDL_Rect. The SDL Wiki list the fields (not in
code but as a table) as follows:

int x
int y
int w
int h

(https://wiki.libsdl.org/SDL_Rect)

Great. But if I double-check that, another page has this:

typedef struct{
Sint16 x, y;
Uint16 w, h;
} SDL_Rect;

(https://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlrect.html)

Which is quite different (8 bytes vs. 16 bytes). If I look inside the
actual headers of my implementation, it has:

typedef struct SDL_Rect
{ int x, y;
int w, h;
} SDL_Rect;

Well, at least this one is easy to understand! But it's not reassuring
that online resources can give contradictory information. I have to hope
that the accompanying DLL, which a user normally has to install
independently, uses a definition which matches the layout that is
built-in to the binary of my application.

Neither is it particularly assuring to see a library that likes to use
aliases like Sint32 and Uint32, to use a non-specific int type like this.

For people actually coding in C, only the number of fields, names and
order is important; the types are not so relevant. But those are vital
for anyone else.

On 2021-08-26 12:43, Bart wrote:
> On 26/08/2021 08:33, Dmitry A. Kazakov wrote:

>> And nobody cared to separate interface from implementation (like you),
>> so all internal mess of meaningless structures have got exposed...
>
> If someone creates a library to be used via an FFI (or even in the same
> language!), then they can choose to create a more suitable interface
> that only exposes what is essential.

Or choose not to...

> But I don't care; I just want something that works. I want being able to
> use such a library to be routine, not a challenge that will need
> time-consuming, ad hoc, hit and miss approaches that may or may not
> succeed.

Everybody wants that. The problem is that people always choose the worst
possible solution. In DEC VMS you could call any system function from
any language just same. Then came MS-DOS. DEC does not exist anymore and
Microsoft is worth of billions, busy rounding window corners. Sh*t sells
best!

> C shouldn't come into it at all. A 'C type system' isn't really a type
> system, but just a thin layer over the underlying hardware.

Maybe. But I wonder if it would something much worse, like your
language... (:-))

> C just provides obfuscation. The binary library might have been written
> in C, but so what? Now it is in binary!

The C headers are provided for C developers. Nobody cares about other
languages. You are free to use these headers, but that is where the
train stops. However nobody forbids you to reverse engineer the DLL
interface in machine code either, not even Google nor Facebook.

>> GTK (actually GObject) is a perfect lesson for you and James. It tries
>> to implement object-oriented classes on top of low-level C. The result
>> is what see.
>
> The result is a monstrous library that I wouldn't want to use anyway
> even if it could be used via an FFI with no problems at all. (It was
> just a challenging library to try out my conversion software on.)

And all that is because C cannot classes.

> Imagine arranging to distribute or remotely installing 28 DLL binaries,
> all with elaborate filenames that are not even fixed; they will vary by
> version.

Doing it all time. This is what packaging systems are, e.g. Inno Setup,
rpmbuild, dh-make. BTW, GTK is more than 50 DLLs, plus fonts, icons,
locales etc. Hundred of files you needed if you wanted to package it.

>> Because there are dozens of different entities involved. Welcome back
>> to reality.
>
> But there aren't. This is not part of a directory structure that is
> stored on disk so the size is sensitive because there might be 1 millon
> files.

Of course they are, where it gets them from?

> Why return that info all in one lump anyway: have multiple routines, or
> provide a parameter to choose the specific attribute you need.

Individual getters are undesirable in the case of potential race
condition. And this is always the case with shared resources like files.
Then, individual operations might be very expensive, e.g. if network is
involved. You would need caching, the cache might get dirty etc. Getter
is not always the answer.

However getters would change nothing. The entities are still there, the
getter has to use the member type.

> That info can just be a 64-bit integer for each piece of data; it's just
> a number (didn't you say above that you shouldn't expose the inner
> workings?). You don't need to complicate matters with multiple types.

Rubbish. Types are there to prevent silly errors of comparing the user
ID with the group ID. Nobody wants untyped interfaces. C guys at least
try to pretend that they care...

> In any case, what is the point of hiding int64 under 'long long int', of
> hiding long long int under '__u_guard_t', of hiding __u_guard_t under
> '__dev_t', of hiding __dev_t under 'dev_t'?

No program shall use predefined types. Guard is not integer. __dev_t is
probably implementation-specific, must be hidden even deeper.

> Don't tell that is good programming even under Ada! Don't forget this is
> defining just one field of that struct.

In Ada there would be more types.

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

On 26/08/2021 12:59, Dmitry A. Kazakov wrote:
> On 2021-08-26 12:43, Bart wrote:

>> The result is a monstrous library that I wouldn't want to use anyway
>> even if it could be used via an FFI with no problems at all. (It was
>> just a challenging library to try out my conversion software on.)
>
> And all that is because C cannot classes.

Classes would be worse. As I further elaborate below, APIs designed to
work across languages should use the lowest common factor type system.

>> But there aren't. This is not part of a directory structure that is
>> stored on disk so the size is sensitive because there might be 1
>> millon files.
>
> Of course they are, where it gets them from?

So if the field was used in on-disk data structure that encoded a file
size in 42 bits of data, the API should demand that a language also had
a 42-bit type to receive it?

It's just /a number/. The most suitable and most univeral natural type
/amongst programming languages/ to represents all values of that field
would be i64 or u64.

Anything more elaborate (eg. some complex bigint format) would not be
suitable for very many languages.

>> Why return that info all in one lump anyway: have multiple routines,
>> or provide a parameter to choose the specific attribute you need.
>
> Individual getters are undesirable in the case of potential race
> condition.

Yet WinAPI has the function GetFileSize. All these values could be
out-of-date a microsecond after a call returns.

> And this is always the case with shared resources like files.
> Then, individual operations might be very expensive, e.g. if network is
> involved. You would need caching, the cache might get dirty etc. Getter
> is not always the answer.

With files there will always be so many variables there any sort of
programming become impossible if you have to worry about absolutely
everything.

How is it even possible to compile a source file, since half-way through
parsing it, it may have changed!

Actually any language that uses independent compilation could have
problems. Trying to capture and 'freeze' all source files before
starting to compile wouldn't work either, as you can't do that
simultaneously.

Fortunately, in what I do, I don't need to worry about that.

>> That info can just be a 64-bit integer for each piece of data; it's
>> just a number (didn't you say above that you shouldn't expose the
>> inner workings?). You don't need to complicate matters with multiple
>> types.
>
> Rubbish. Types are there to prevent silly errors of comparing the user
> ID with the group ID.

That belongs within the language. It's less practical in cross-language
APIs since every language will have the own way of representing such types.

However, it we are talking the number of bytes in a file [at a
particular instant at least], it is just a NUMBER, a COUNT.

If you want to stop the caller from multiplying two file sizes together,
then good luck with that. Although burying an i64 value beneath half a
dozen C typedefs might be one way of doing it, as calling the function
becomes impossible!

> Nobody wants untyped interfaces.

They ARE typed, but using non-application-specific numeric types as they
are most common cross-language types, and the most flexible to work with.

And also, once the information is available, then there is nothing to
stop the person writing the bindings for their language from
superimposing a stricter type system on those parameter types, or
writing wrapper functions that are more in keeping with the language style.

But /this doesn't belong/ in a common API.

Take the SDL_Rect example I posted earlier, which uses 4 'int' fields.
They represent pixel positions in a 2D matrix of a raw window or image.

What type what /you/ make those?

> In Ada there would be more types.

Fortunately there are no Ada libraries I'd want to use.

On 2021-08-26 15:42, Bart wrote:
> On 26/08/2021 12:59, Dmitry A. Kazakov wrote:
>> On 2021-08-26 12:43, Bart wrote:
>
>>> The result is a monstrous library that I wouldn't want to use anyway
>>> even if it could be used via an FFI with no problems at all. (It was
>>> just a challenging library to try out my conversion software on.)
>>
>> And all that is because C cannot classes.
>
> Classes would be worse.

Why?

> As I further elaborate below, APIs designed to
> work across languages should use the lowest common factor type system.

They are designed to work with C.

>>> But there aren't. This is not part of a directory structure that is
>>> stored on disk so the size is sensitive because there might be 1
>>> millon files.
>>
>> Of course they are, where it gets them from?
>
> So if the field was used in on-disk data structure that encoded a file
> size in 42 bits of data, the API should demand that a language also had
> a 42-bit type to receive it?

Nope. The format on the disk is utterly irrelevant.

> It's just /a number/.

It is almost never a number. Numbers are used in numeric applications,
which filesystems have very little to do with.

> Anything more elaborate (eg. some complex bigint format) would not be
> suitable for very many languages.

Nobody cares about languages. Languages are tools. If you cannot design
a usable language, it is your problem. There are plenty other languages
to choose from.

>>> Why return that info all in one lump anyway: have multiple routines,
>>> or provide a parameter to choose the specific attribute you need.
>>
>> Individual getters are undesirable in the case of potential race
>> condition.
>
> Yet WinAPI has the function GetFileSize. All these values could be
> out-of-date a microsecond after a call returns.

Yes, and an error in the timestamp will decide if the build tool-chain
would recompile the source file or link an invalid object file. A quite
critical stuff.

> With files there will always be so many variables there any sort of
> programming become impossible if you have to worry about absolutely
> everything.

When people's lives and money depend on the program, you must worry a
lot. This is why safe languages and safe design choices are priority.

> Actually any language that uses independent compilation could have
> problems. Trying to capture and 'freeze' all source files before
> starting to compile wouldn't work either, as you can't do that
> simultaneously.

You do not need to freeze anything. It is relatively simple to ensure
consistency of inputs on each build step.

>> Rubbish. Types are there to prevent silly errors of comparing the user
>> ID with the group ID.
>
> That belongs within the language. It's less practical in cross-language
> APIs since every language will have the own way of representing such types.

This has nothing to do with representation. It must be distinct types
whatever represented.

> However, it we are talking the number of bytes in a file [at a
> particular instant at least], it is just a NUMBER, a COUNT.

No such thing exist outside a textbook on elementary mathematics.

> If you want to stop the caller from multiplying two file sizes together,
> then good luck with that.

What is the problem with that? Just do not provide * for the type. In
Ada it is rather trivial:

type File_Size is range 0..2**64-1; -- How we love such numbers!
function "*" (Left, Right : File_Size) return File_Size is abstract;
function "/" (Left, Right : File_Size) return File_Size is abstract;

Done, we killed them.

>> Nobody wants untyped interfaces.
>
> They ARE typed, but using non-application-specific numeric types as they
> are most common cross-language types, and the most flexible to work with.

If they all are of the same type 'number', how is that typed?

> And also, once the information is available,  then there is nothing to
> stop the person writing the bindings for their language from
> superimposing a stricter type system on those parameter types, or
> writing wrapper functions that are more in keeping with the language style.

There is nothing to stop anybody writing bug-free code. Yet somehow they
manage...

> But /this doesn't belong/ in a common API.

It does, as elementary safety.

Before the Dark Age, there were considerations of hardware architectures
supporting types. It was difficult then. Today tagging run-time objects
in a safe way would not be that expensive.

> Take the SDL_Rect example I posted earlier, which uses 4 'int' fields.
> They represent pixel positions in a 2D matrix of a raw window or image.
>
> What type what /you/ make those?

I customary use different types for screen coordinates. It helps a lot.
Another pair of types would be to have different relative and absolute
coordinates.

A huge amount of bugs are coming from mixing those. It is a real plague
in Cairo when you forget to translate coordinates or translate one too
many. The same issue has GTK tree view and model. You need to translate
view coordinates, model iterators etc all the time and if you fail, you
crash the application.

>> In Ada there would be more types.
>
> Fortunately there are no Ada libraries I'd want to use.

You could not anyway from your language.

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

On 26/08/2021 13:06, Bart wrote:
> On 26/08/2021 09:29, David Brown wrote:
>> On 26/08/2021 09:33, Dmitry A. Kazakov wrote:
>
>>> Because there are dozens of different entities involved. Welcome back to
>>> reality.
>>>
>>
>> Bart doesn't like that reality.  He wants a reality where everything is
>> designed to suit his convenience, and is fine-tuned for the systems he
>> uses and nothing else.
>
> I want a reality which suits anyone, not just those using C.

Everyone else - regardless of language - manages fine. There will
always be compromises, and things will be a little more difficult for
some people than otherwise expected. And for any system that has
evolved over time, there will be sub-optimal solutions due to continuous
backwards compatibility.

But here is the /real/ reality for you. There are a great many people
involved in the programming world. Many are a lot smarter than you,
with a lot more experience and knowledge. They don't sit alone and
expect the world to do what suits them - they work together with people,
organisations, companies, projects, and solve these issues. Where there
are real problems, things change over time. Where tools make life
easier, tools are written.

Now, it /occasionally/ happens that when one person disagrees with the
rest of the people in a given field, that one person is right and the
status quo is wrong. But it's extremely rare.

On 26/08/2021 16:40, David Brown wrote:
> On 26/08/2021 13:06, Bart wrote:
>> On 26/08/2021 09:29, David Brown wrote:
>>> On 26/08/2021 09:33, Dmitry A. Kazakov wrote:
>>
>>>> Because there are dozens of different entities involved. Welcome back to
>>>> reality.
>>>>
>>>
>>> Bart doesn't like that reality.  He wants a reality where everything is
>>> designed to suit his convenience, and is fine-tuned for the systems he
>>> uses and nothing else.
>>
>> I want a reality which suits anyone, not just those using C.
>
> Everyone else - regardless of language - manages fine.

You don't know how fine they manage or how much effort it is or what
complex dependencies need to be introduced.

If /I/ wrote a library, made available a DLL for it, and exposed a
struct like this for a key type:

struct {
Fee a;
Fie b;
Foe c;
Foo d;
} Rec

without any of Fee, Fie, Foe, Foo being defined anywhere in that
interface, or maybe defined in a way that requiring someone downloading
my language and writing and running test programs to figure out the
characteristics of those types, I think most would agree that that is a
bad show.

On the other hand, if I made it available like this:

struct {
Int32 a;
Int16 b;
Int16 padding;
Int32 c;
int32 d;
} Rec;

then it must obvious even to you that that is a much more preferable
start point. You don't need to have any involvement in my language.

But if some degree of abstract typing is desired even in the API, then
at the very least I would add this to the original:

type Fee = Int32
type Fie = Int16
type Foe = Int32
type Foo = Int32

with either a note applied to the struct that C-style layout rules
apply, or with that padding added.

> But here is the /real/ reality for you. There are a great many people
> involved in the programming world. Many are a lot smarter than you,
> with a lot more experience and knowledge.

Sure. But they don't seem very adept at writing agreeable programming
languages! (They all seem to be outdoing each in creating more and more
impossible functional languages, and doing away with more and more
features that people still need.)

> They don't sit alone and
> expect the world to do what suits them

I think have a fairly unusual perspective: most things involved in
programming I've had to deal with from nothing at some point:

* The hardware (built from microprocessors, logic and RAM)
* Display hardware (from ready-mode controllers and later from logic)
* Graphics display hardware (loads of these)
* ADCs and DACs for the latter
* (Even a keyboard once, plus one or two PSUs from bare transformers)
* Cassette tape storage
* Floppy drives via bare controller chips
* Hard drives via bus-connected controller boards
* Comms and basic networks using rs232/rs423 from bare controllers
* Bitmapped fonts and later some vector fonts
* Display drivers
* Graphics and GUI libraries
* Printer and plotter drivers
* Tablet drivers (ie. digitisers)
* Languages
* Assemblers (my first was written in hex)
* Compilers (early ones written in asm)
* Linkers
* Application script languages
* Interpreters
* Editors
* Floating point emulation
* Maths libraries
* Image file formats
* Internationalisation
* Writing user and technical manuals
* Writing page layout software for those same manuals,
in my scripting language, run using my graphics app,
and using my Postscript driver on that app
* ...

ALL of this was also done without external tools: no software tools, no
external languages, and to start with, until I had access to
oscilloscopes, no hardware tools either.

All of this is stuff that most people now just take for granted; it gets
handed to them on a plate, but I had to build it or invent it or write it.

So HOW DARE YOU say that I somehow expect the world to do this stuff for me.

I can still cope quite well thank you very much, but some of the
functionality I need is now hidden behind effective firewalls of poorly
documented libraries with complex interfaces.

All I'm asking is for people to be more critical of those APIs and to
think more carefully about exactly how portable they really are and what
dependencies and assumptions are built in.

You don't seem to be critical of anything at all. Take that chain of 4
types to define 'dev_t'; how long does that chain need to be before even
/you/ start to question it. Or wouldn't you care provided that ghastly
mess is dealt with by someone else or buried under layers of tools?

Don't you have sense of aesthetics at all, any pride in writing code
that isn't a huge sprawling mess and GRATUITOUS of typedefs and macros?

Wouldn't you prefer you own tidier product not to have to depend on such
a mess?

work together with people,
> organisations, companies, projects, and solve these issues. Where there
> are real problems, things change over time. Where tools make life
> easier, tools are written.

Yeah, bigger and more monstrous tools than ever.

So I'm also hoping some people will start to think small rather than
big. When I briefly had VS2017 on my machine, it took a minute and a
half to get started. Come on...

On 26/08/2021 15:46, Dmitry A. Kazakov wrote:
> On 2021-08-26 15:42, Bart wrote:
>> On 26/08/2021 12:59, Dmitry A. Kazakov wrote:

>>> And all that is because C cannot classes.
>>
>> Classes would be worse.
>
> Why?
>
>> As I further elaborate below, APIs designed to work across languages
>> should use the lowest common factor type system.
>
> They are designed to work with C.

Didn't you just say that C can't do classes?

>> It's just /a number/.
>
> It is almost never a number. Numbers are used in numeric applications,
> which filesystems have very little to do with.

It's a number as most normal people understand it.

My compiler's executable file is 521728 bytes; if that's not a number,
good luck trying to multiply it by N on any calculator, as those only
deal with numbers!

>> Yet WinAPI has the function GetFileSize. All these values could be
>> out-of-date a microsecond after a call returns.
>
> Yes, and an error in the timestamp will decide if the build tool-chain
> would recompile the source file or link an invalid object file. A quite
> critical stuff.

What do you compare the timestamp too? If module A depends on B, and you
compile A first, then edit B and compiler B, now the output for A will
be out of date.

Now suppose you have A depending on B, and B depending on A/

There are some issues there, but they are nothing to with the fact that
the size of A reported by something may changed in the millisecond
before the file is read in.

>> With files there will always be so many variables there any sort of
>> programming become impossible if you have to worry about absolutely
>> everything.
>
> When people's lives and money depend on the program, you must worry a
> lot. This is why safe languages and safe design choices are priority.

Most of my software is not that critical. Most of the software in my
household devices is not that critical.

I mean, how mission critical does a text editor need to be when I'm
writing a shopping list; if it ends up with Milf instead of Milk, that
wouldn't be the end of the world!

> What is the problem with that? Just do not provide * for the type. In
> Ada it is rather trivial:
>
>    type File_Size is range 0..2**64-1; -- How we love such numbers!
>    function "*" (Left, Right : File_Size) return File_Size is abstract;
>    function "/" (Left, Right : File_Size) return File_Size is abstract;
>
> Done, we killed them.

Done where, inside the API? The API will not use Ada. It might be
another language (usually C), or it might not use a language at all.

What about languages that don't have such features?

>> They ARE typed, but using non-application-specific numeric types as
>> they are most common cross-language types, and the most flexible to
>> work with.
>
> If they all are of the same type 'number', how is that typed?

They have one of the types from u8 u16 u32 u64 i8 i16 i32 i64 r32 r64,
as a minimum set (usually pointers and strings and composite types are
extra ones).

You of course will have a unique view of what constitutes a type.

>> But /this doesn't belong/ in a common API.
>
> It does, as elementary safety.

OK. Write me a API with a type-safe version of GetFileSize.

Remember this will have a concrete, binary implementation in some
library. Your API, together with a known ABI, needs to have enough
information to be able to use it from any suitable language, for
example, assembly.

> Before the Dark Age, there were considerations of hardware architectures
> supporting types. It was difficult then. Today tagging run-time objects
> in a safe way would not be that expensive.
>
>> Take the SDL_Rect example I posted earlier, which uses 4 'int' fields.
>> They represent pixel positions in a 2D matrix of a raw window or image.
>>
>> What type what /you/ make those?
>
> I customary use different types for screen coordinates. It helps a lot.
> Another pair of types would be to have different relative and absolute
> coordinates.
>
> A huge amount of bugs are coming from mixing those. It is a real plague
> in Cairo when you forget to translate coordinates or translate one too
> many. The same issue has GTK tree view and model. You need to translate
> view coordinates, model iterators etc all the time and if you fail, you
> crash the application.

But introduce special types, ones that the language stops you combining,
and you will come across a need to do exactly that. Then you need to
allow it. And sooner or later those special types start to poison every
other function.

Here's a simple example, plotting into a 256x256 8-bit greyscale image:

for x:=0 to 255 do
setpixel(img, x, y, x)
end

It creates a greyscale getting brighter from left to right. The 2nd
parameter of setpixel is an x-coordinate; the 4th is a pixel value.

I guess you have pixel positions and image intensities have different
types, but here you need to convert one to the other.

Would you also have different types for x and y pixel positions? That
would stop you transposing x and y, but sometimes you need exactly that.

Would x and y be a type limited from 0 to 255? That would be hard to
enforce at compile-time with an image size set at runtime. But if not
limited, now you can pass setpixel invalid coordinates.

See how much of pain it becomes? There's a probably a good reason for
those libraries not to employ stricter types.

And there's probably nothing that stops you wrapping those functions
with stricter parameter types.

(What, that would mean creating your own set of functions to use that
library? Welcome to the club!)

On 2021-08-26 20:02, Bart wrote:
> On 26/08/2021 15:46, Dmitry A. Kazakov wrote:
>> On 2021-08-26 15:42, Bart wrote:
>>> On 26/08/2021 12:59, Dmitry A. Kazakov wrote:
>
>>>> And all that is because C cannot classes.
>>>
>>> Classes would be worse.
>>
>> Why?
>>
>>> As I further elaborate below, APIs designed to work across languages
>>> should use the lowest common factor type system.

Again, C API do not care about other languages. C has preprocessor, an
idiotic concept happily died with PL/1. No other languages I know have
it. Do C programmers care, nope, C API is full of this mess.

>> They are designed to work with C.
>
> Didn't you just say that C can't do classes?

I did. But if C had classes, then everybody would have to adapt.

>>> It's just /a number/.
>>
>> It is almost never a number. Numbers are used in numeric applications,
>> which filesystems have very little to do with.
>
> It's a number as most normal people understand it.

Nope. Size is measured in bytes, inches, tracks, magnetic domains etc.

> My compiler's executable file is 521728 bytes; if that's not a number,

See, it is bytes.

> There are some issues there, but they are nothing to with the fact that
> the size of A reported by something may changed in the millisecond
> before the file is read in.

No idea what are you arguing with. As I said, certain applications
require data consistency.

> Most of my software is not that critical. Most of the software in my
> household devices is not that critical.

That is your choice and your problem. Do not impose it on others.

>> What is the problem with that? Just do not provide * for the type. In
>> Ada it is rather trivial:
>>
>>     type File_Size is range 0..2**64-1; -- How we love such numbers!
>>     function "*" (Left, Right : File_Size) return File_Size is abstract;
>>     function "/" (Left, Right : File_Size) return File_Size is abstract;
>>
>> Done, we killed them.
>
> Done where, inside the API?

Yes, inside the definition of the API.

> The API will not use Ada.

No, we are talking about API defined in Ada. You asked how it could be
done differently in a different language. I explained.

> What about languages that don't have such features?

What about your language incapable to conform to C APIs? Nothing. The
designers of API just do not care. They put up the requirements and it
is your problem afterwards.

>>> They ARE typed, but using non-application-specific numeric types as
>>> they are most common cross-language types, and the most flexible to
>>> work with.
>>
>> If they all are of the same type 'number', how is that typed?
>
> They have one of the types from u8 u16 u32 u64 i8 i16 i32 i64 r32 r64,
> as a minimum set (usually pointers and strings and composite types are
> extra ones).

You said you wanted everything be unsigned 64. You also said that user
ID, group ID, process ID, thread ID, node ID are all of the same type.
That is the definition of untyped.

> You of course will have a unique view of what constitutes a type.

Just standard type definition you can find everywhere. A type is a set
of values and a set operations on these values.

Since user ID is not group ID, no value of the user ID type is a value
of the group ID types. Ergo, they are different types.

>>> But /this doesn't belong/ in a common API.
>>
>> It does, as elementary safety.
>
> OK. Write me a API with a type-safe version of GetFileSize.

That is not possible in C, but one could do that in any strongly typed
language Ada, C++ (in its strongly typed subset) etc.

> Remember this will have a concrete, binary implementation in some
> library.

Just *any* programming language capable to create a library with
satisfies that. If you think about *what* a programming language is.

>> Before the Dark Age, there were considerations of hardware
>> architectures supporting types. It was difficult then. Today tagging
>> run-time objects in a safe way would not be that expensive.
>>
>>> Take the SDL_Rect example I posted earlier, which uses 4 'int'
>>> fields. They represent pixel positions in a 2D matrix of a raw window
>>> or image.
>>>
>>> What type what /you/ make those?

Horizontal_Axis
Vertical_Axis
Horizontal_Distance
Vertical_Distance

> I guess you have  pixel positions and image intensities have different
> types, but here you need to convert one to the other.

And why is that a problem?

> Would you also have different types for x and y pixel positions? That
> would stop you transposing x and y, but sometimes you need exactly that.

Where is a problem?

> See how much of pain it becomes? There's a probably a good reason for
> those libraries not to employ stricter types.

If you mean fixing bugs painful, I prefer that pain at compile time. I
would not wish debugging image processing code to my worst enemy. I
started as a programmer in an air sensing laboratory. We programmed
heavy image processing stuff in assembly. That was no fun.

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

On 26/08/2021 21:39, Dmitry A. Kazakov wrote:
> On 2021-08-26 20:02, Bart wrote:

>> My compiler's executable file is 521728 bytes; if that's not a number,
>
> See, it is bytes.

Yes, there's a unit associated with it. But units do not usually form
tangible parts of parts of APIs.

Many languages now have a specific type such as size_t, usize, or isize.
Mainly it's separate from 'int' because 'int' is commonly 32 bits, and
sizes of things, specifically bytes or the size of an array, can often
exceed that.

>> Most of my software is not that critical. Most of the software in my
>> household devices is not that critical.
>
> That is your choice and your problem. Do not impose it on others.

I don't write the software in my household devices, or in my car, on
that's running on websites that I am obliged to used. Most of it is buggy.

>> They have one of the types from u8 u16 u32 u64 i8 i16 i32 i64 r32 r64,
>> as a minimum set (usually pointers and strings and composite types are
>> extra ones).
>
> You said you wanted everything be unsigned 64.

The primary integer type is i64. For floats, either f32 or f64 (eg.
OpenGL likes to use f32). Distinct interger/float types are important
since ABIs tend to pass those differently.

The narrower types are mainly associated with storage: arrays, packed
structs, pointer targets. u64 might sometimes be used in place of i64.

> You also said that user
> ID, group ID, process ID, thread ID, node ID are all of the same type.
> That is the definition of untyped.

You can go overboard with micromanaging types to the extent that your
application becomes unmanagable.

Would you also have a million string types: user name, password, group
name, process name, thread name, node name?

In that case, what type would IntegerImage(I) have in Ada? Is that
separate from FloatImage(F)?

If you want to work with filenames, would one type suffice for a file
specifier, or would there be separate string types for the path, base
filename and extension? Suppose you extracted a slice of a filename, is
the result still classed as a filename, or is it now (at last!) just a
String?

I don't like such type systems because IME they are a can of worms.

>>>> What type what /you/ make those?
>
>    Horizontal_Axis
>    Vertical_Axis
>    Horizontal_Distance
>    Vertical_Distance

OK, so you would dispense even with the x, and y we used to use at school.

>> I guess you have  pixel positions and image intensities have different
>> types, but here you need to convert one to the other.
>
> And why is that a problem?

Won't the language stop you from using a Horizontal_Axis etc as an
Intensity?

>> Would you also have different types for x and y pixel positions? That
>> would stop you transposing x and y, but sometimes you need exactly that.
>
> Where is a problem?

>> See how much of pain it becomes? There's a probably a good reason for
>> those libraries not to employ stricter types.
>
> If you mean fixing bugs painful, I prefer that pain at compile time. I
> would not wish debugging image processing code to my worst enemy. I
> started as a programmer in an air sensing laboratory. We programmed
> heavy image processing stuff in assembly. That was no fun.

Well, I did some image processing stuff (associated with
satellite-captured solar images) in Fortran. That was fun actually. You
really don't need a separate type for every pixel or whatever.

It might help with a few bugs but a cost of massively harder coding.

On 26/08/2021 19:19, Bart wrote:

> All I'm asking is for people to be more critical of those APIs and to
> think more carefully about exactly how portable they really are and what
> dependencies and assumptions are built in.
>
> You don't seem to be critical of anything at all. Take that chain of 4
> types to define 'dev_t'; how long does that chain need to be before even
> /you/ start to question it. Or wouldn't you care provided that ghastly
> mess is dealt with by someone else or buried under layers of tools?
>
> Don't you have sense of aesthetics at all, any pride in writing code
> that isn't a huge sprawling mess and GRATUITOUS of typedefs and macros?
>
> Wouldn't you prefer you own tidier product not to have to depend on such
> a mess?
>

You misunderstand my position.

I don't think the way APIs are often written is perfect. I don't think
the way C headers are written is perfect. I don't think /C/ is perfect.
I don't think the tools are perfect.

I think they are all /good enough/ to work with.

I understand why they are the way they are. I understand what is
realistic to change, and what is unrealistic. I understand that there
are many different people with different needs, and the whole shebang is
a compromise that is not ideal for anyone, but is useable by almost
everyone.

I understand that when the reality of the world does not suit us, it is
/our/ responsibility to adapt - no one is helped by simply complaining.
/Occasionally/ the right answer is to change the world, rather than
ourselves, but that is rare. Perhaps you can change it a little.
Perhaps you can group together with lots of other people and change it a
lot. Perhaps you are one of those rare individuals with the drive and
passion to lead others in making a bigger change. But for the most
part, for things that don't actually matter that much, you adapt
yourself - or find something else to do.

On 2021-08-27 00:37, Bart wrote:
> On 26/08/2021 21:39, Dmitry A. Kazakov wrote:

> Yes, there's a unit associated with it. But units do not usually form
> tangible parts of parts of APIs.

It is lot more than just unit (which byte is not). The whole semantics
of the values. This semantics is expressed by the type. There exist no
values without that.

> I don't write the software in my household devices, or in my car, on
> that's running on websites that I am obliged to used. Most of it is buggy.

One of contributors to low quality is code design in an untyped/weakly
typed manner.

>> You also said that user ID, group ID, process ID, thread ID, node ID
>> are all of the same type. That is the definition of untyped.
>
> You can go overboard with micromanaging types to the extent that your
> application becomes unmanagable.

How exactly adding file size to customer salary makes application more
manageable?

> Would you also have a million string types: user name, password, group
> name, process name, thread name, node name?

Sometimes. For example password string will be automatically zeroed upon
finalization. The password string will have hash operations, like SHA-n etc.

Certainly with differently encoded strings must have different types. It
is a very common error to pass a Latin-1 string where UTF-8 is expected.
And of course that would automatically handle re-coding as necessary.

> In that case, what type would IntegerImage(I) have in Ada? Is that
> separate from FloatImage(F)?

I have no idea what are you asking.

> If you want to work with filenames, would one type suffice for a file
> specifier, or would there be separate string types for the path, base
> filename and extension? Suppose you extracted a slice of a filename, is
> the result still classed as a filename, or is it now (at last!) just a
> String?

Sure. Path is not string. Absolute path is not relative path etc. In
properly designed software you would have separate types and operations
defined on them. Which by the way would significantly reduce bugs and
improve performance since extracting simple file name from the path
would become O(1) operation rather than O(n).

> I don't like such type systems because IME they are a can of worms.

I know, you prefer a basin of vipers...

>>> I guess you have  pixel positions and image intensities have
>>> different types, but here you need to convert one to the other.
>>
>> And why is that a problem?
>
> Won't the language stop you from using a Horizontal_Axis etc as an
> Intensity?

It will require to write a conversion function and make you think what
the hell are you writing, where is that library function to flood fill
gradients...

> Well, I did some image processing stuff (associated with
> satellite-captured solar images) in Fortran. That was fun actually.

It was no fun, because in order to find an error, we dumped the image on
a tape. The tape was brought to a device that transferred the tape to a
film and only then you could see artifacts, if you were lucky.

> You
> really don't need a separate type for every pixel or whatever.

Of course there are different types of pixels. You have lots of
differently encoded pixels. Hundreds of color models, grayscale,
opacity, layers etc.

> It might help with a few bugs but a cost of massively harder coding.

Typed code is much easier to read and write.

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

On 27/08/2021 09:17, Dmitry A. Kazakov wrote:
> On 2021-08-27 00:37, Bart wrote:
>> On 26/08/2021 21:39, Dmitry A. Kazakov wrote:
>
>> Yes, there's a unit associated with it. But units do not usually form
>> tangible parts of parts of APIs.
>
> It is lot more than just unit (which byte is not).

Why not? That might prevent me from directly adding X representing bytes
to Y representing MB (now called MiB).

Or it would tell the language to scale Y by 1048576 before adding to X.
At last something useful that overly pedantic typing can do!

(I did something like this in one language, but it was limited to
literals; it didn't involve types:

print 100mm + 4m + 10 ins

It would display 4354 (natural unit being mm). But it didn't stop me
addding together incompatible units.)

The whole semantics
> of the values. This semantics is expressed by the type. There exist no
> values without that.
>
>> I don't write the software in my household devices, or in my car, on
>> that's running on websites that I am obliged to used. Most of it is
>> buggy.
>
> One of contributors to low quality is code design in an untyped/weakly
> typed manner.

Yes you can improve code quality by increasing the number of enforced
types. But you ony need to increase so much; no need to become obsessive
about it, always looking for ways to further separate one type into 2,
or N, further types.

However, I've no idea what languages are used in the digital devices in
my life. The reason for the problems can be diverse.

>>> You also said that user ID, group ID, process ID, thread ID, node ID
>>> are all of the same type. That is the definition of untyped.
>>
>> You can go overboard with micromanaging types to the extent that your
>> application becomes unmanagable.
>
> How exactly adding file size to customer salary makes application more
> manageable?

If that doesn't make sense, then don't do it! Why make a dozen more
things that /do/ make sense harder to do, requiring you to waste effort
in special workarounds, an even bigger zoo of types, and more cluttered
code?

>> In that case, what type would IntegerImage(I) have in Ada? Is that
>> separate from FloatImage(F)?
>
> I have no idea what are you asking.

I thought IntegerImage() returned a String. If so, is that a generic
String, or Text-Reprepresentation-of-an_Integer-String?

>> It might help with a few bugs but a cost of massively harder coding.
>
> Typed code is much easier to read and write.

That's a funny point of view, because what made script languages more
user-friendly, informal and quick to code in, was that exact absence of
strict typing!

On 2021-08-27 12:30, Bart wrote:
> On 27/08/2021 09:17, Dmitry A. Kazakov wrote:
>> On 2021-08-27 00:37, Bart wrote:
>>> On 26/08/2021 21:39, Dmitry A. Kazakov wrote:
>>
>>> Yes, there's a unit associated with it. But units do not usually form
>>> tangible parts of parts of APIs.
>>
>> It is lot more than just unit (which byte is not).
>
> Why not?

Byte is not a physical entity. You could add it though since measurement
unit systems are more or less arbitrary.

However typically, stuff like bytes is treated as having the unit 1 SI,
like percents, angular degrees, radians, neper etc.

> That might prevent me from directly adding X representing bytes
> to Y representing MB (now called MiB).

Why would it? If you want a type model of measurement units is perfectly
possible. You will be able to add bytes to megabytes and get a correct
result. Not in your language though.

> Or it would tell the language to scale Y by 1048576 before adding to X.
> At last something useful that overly pedantic typing can do!

Yes it will. The unit model is (Gain * Value + Offset) x Unit. In this
case offsets are 0. The gains are 1 and 2**10, correspondingly. The unit
would be (byte**1, meter**0, second**0, ..., ampere**0), if byte is to
treated as a separate unit.

General rules:

1. Types of same unit can be added (have +,-)
2. Types of same unit and zero offset can be multiplied (have *,/)
3. Types of zero offset can be multiplied by types of the unit
(1,1,...,1) also with zero offset.
4. Types of any unit and zero offset can be powered by a whole number (**n)

>>> You can go overboard with micromanaging types to the extent that your
>>> application becomes unmanagable.
>>
>> How exactly adding file size to customer salary makes application more
>> manageable?
>
> If that doesn't make sense, then don't do it!

You did not answer the question.

>>> In that case, what type would IntegerImage(I) have in Ada? Is that
>>> separate from FloatImage(F)?
>>
>> I have no idea what are you asking.
>
> I thought IntegerImage() returned a String. If so, is that a generic
> String, or Text-Reprepresentation-of-an_Integer-String?

A generic string.

>>> It might help with a few bugs but a cost of massively harder coding.
>>
>> Typed code is much easier to read and write.
>
> That's a funny point of view, because what made script languages more
> user-friendly, informal and quick to code in, was that exact absence of
> strict typing!

LOL, script languages are *extremely* user unfriendly. Did you ever use
bash, batch etc? They are utter mess in each possible aspect. Just to
write simple you must consult Internet and then spend a day to figure
out why it does not work as expected.

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

On 27/08/2021 12:30, Dmitry A. Kazakov wrote:
> On 2021-08-27 12:30, Bart wrote:
>> On 27/08/2021 09:17, Dmitry A. Kazakov wrote:
>>> On 2021-08-27 00:37, Bart wrote:
>>>> On 26/08/2021 21:39, Dmitry A. Kazakov wrote:
>>>
>>>> Yes, there's a unit associated with it. But units do not usually
>>>> form tangible parts of parts of APIs.
>>>
>>> It is lot more than just unit (which byte is not).
>>
>> Why not?
>
> Byte is not a physical entity. You could add it though since measurement
> unit systems are more or less arbitrary.
>
> However typically, stuff like bytes is treated as having the unit 1 SI,
> like percents, angular degrees, radians, neper etc.
>
>> That might prevent me from directly adding X representing bytes to Y
>> representing MB (now called MiB).
>
> Why would it? If you want a type model of measurement units is perfectly
> possible. You will be able to add bytes to megabytes and get a correct
> result. Not in your language though.

My example showed exactly that, but limited to literals.

However you wouldn't be able to do that in your language either, unless
B, KB, MB units etc are already built-in.

You would need to program that behaviour. I can do the same, but it
would be more clunky.

>
>> Or it would tell the language to scale Y by 1048576 before adding to
>> X. At last something useful that overly pedantic typing can do!
>
> Yes it will. The unit model is (Gain * Value + Offset) x Unit. In this
> case offsets are 0. The gains are 1 and 2**10, correspondingly. The unit
> would be (byte**1, meter**0, second**0, ..., ampere**0), if byte is to
> treated as a separate unit.
>
> General rules:
>
> 1. Types of same unit can be added (have +,-)
> 2. Types of same unit and zero offset can be multiplied (have *,/)
> 3. Types of zero offset can be multiplied by types of the unit
> (1,1,...,1) also with zero offset.
> 4. Types of any unit and zero offset can be powered by a whole number (**n)

Are there any offset units apart from Celsius and Fahrenheit?

>> If that doesn't make sense, then don't do it!
>
> You did not answer the question.

OK. It makes all the operations that DO makes sense easier to do
effortlessly. Where they don't make sense, the language won't stop you,
you have to just use normal programming 'nous' to not do that.

After all the language can't do everything for you; you still need to do
some coding of your own!

>> I thought IntegerImage() returned a String. If so, is that a generic
>> String, or Text-Reprepresentation-of-an_Integer-String?
>
> A generic string.

OK, somewhat reassuring I suppose that Ada does use generic types in
some cases!

>> That's a funny point of view, because what made script languages more
>> user-friendly, informal and quick to code in, was that exact absence
>> of strict typing!
>
> LOL, script languages are *extremely* user unfriendly. Did you ever use
> bash, batch etc? They are utter mess in each possible aspect. Just to
> write simple you must consult Internet and then spend a day to figure
> out why it does not work as expected.

Most people would disagree. As for learning to use them, I nearly always
use my own, so that is not an issue.

On 2021-08-27 17:00, Bart wrote:
> On 27/08/2021 12:30, Dmitry A. Kazakov wrote:
>> On 2021-08-27 12:30, Bart wrote:
>>> On 27/08/2021 09:17, Dmitry A. Kazakov wrote:
>>>> On 2021-08-27 00:37, Bart wrote:
>>>>> On 26/08/2021 21:39, Dmitry A. Kazakov wrote:
>>>>
>>>>> Yes, there's a unit associated with it. But units do not usually
>>>>> form tangible parts of parts of APIs.
>>>>
>>>> It is lot more than just unit (which byte is not).
>>>
>>> Why not?
>>
>> Byte is not a physical entity. You could add it though since
>> measurement unit systems are more or less arbitrary.
>>
>> However typically, stuff like bytes is treated as having the unit 1
>> SI, like percents, angular degrees, radians, neper etc.
>>
>>> That might prevent me from directly adding X representing bytes to Y
>>> representing MB (now called MiB).
>>
>> Why would it? If you want a type model of measurement units is
>> perfectly possible. You will be able to add bytes to megabytes and get
>> a correct result. Not in your language though.
>
> My example showed exactly that, but limited to literals.
>
> However you wouldn't be able to do that in your language either, unless
> B, KB, MB units etc are already built-in.

Unit is just a type. You can easily implement any measurement system in Ada:

http://www.dmitry-kazakov.de/ada/units.htm

or in C++. The problem is that Ada's and C++ type systems are to weak
eliminate unit checks and unit tags in static cases.

Again, these are real problems of language design, not making everything
64-bit integer.

> Are there any offset units apart from Celsius and Fahrenheit?

and Réaumur degree and a couple other temperature scales.

AFAIK, there are no other shifted units except temperatures, because
temperature is a wrong unit that does not obey the relativity rules.
Compare it with time and date. Time is a proper unit, date is not.
Temperature is kind of 'date' nailed to a fixed point.

>>> If that doesn't make sense, then don't do it!
>>
>> You did not answer the question.
>
> OK. It makes all the operations that DO makes sense easier to do
> effortlessly. Where they don't make sense, the language won't stop you,
> you have to just use normal programming 'nous' to not do that.

In short, you are walking the minefield.

How is that more manageable than disallowing operations that do not make
sense (the mines)?

> After all the language can't do everything for you; you still need to do
> some coding of your own!

Since braking cannot save you in all emergencies, let's have no brakes?
Everything is a question the costs of preventive measures vs. risks of
faults. Typing has very low costs.

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