In precision typing we trust

In precision typing we trust

[Kevin Chadwick]

On LinkedIn Richard Riehle suggested that strong typing was claimed by many
 languages but Ada offers more in precision typing. I wonder if precision
 would fit around the coin?

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-18 12:29, Kevin Chadwick wrote:
> On LinkedIn Richard Riehle suggested that strong typing was claimed by many
> languages but Ada offers more in precision typing. I wonder if precision
> would fit around the coin?

These are unrelated issues. Strong typing is about:

1. Any object has a type. Note that many OO languages violate this 
principle, but not Ada which has T'Class and T separate.

2. Types have definite set of operations, arguments and results are 
typed. No, ellipsis, no messages (calling an operation on any object), 
no pattern matching of calls etc.

3. Types are insulated unless a relationship is explicitly stated by the 
programmer. E.g. no implicit type conversions.

What Richard refers to is an accuracy of mapping a type to the problem 
space. Talking about numerical entities the model types have precision, 
range, accuracy (float vs. fixed-point vs. unbounded), behavior like 
rounding, handling of exceptional states (breaking out the model) etc.

A counter example to Richard's statement. A weakly typed PL/1 had 
precision types.

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

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

On Mon, 18 Aug 2025, Dmitry A. Kazakov wrote:
|-----------------------------------------------------------------------------|
|"These are unrelated issues. Strong typing is about:                         |
|                                                                             |
|1. Any object has a type. Note that many OO languages violate this principle,|
|but not Ada which has T'Class and T separate.                                |
|                                                                             |
|[. . .]"                                                                     |
|-----------------------------------------------------------------------------|

Dear Mister Kazakov,

Ada is a strongly typed language so Ada is not an OOP language.

With best regards.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-18 15:59, Niocláisín Cóilín de Ghlostéir wrote:
> On Mon, 18 Aug 2025, Dmitry A. Kazakov wrote:
> |-----------------------------------------------------------------------------|
> |"These are unrelated issues. Strong typing is about:                         |
> |                                                                             |
> |1. Any object has a type. Note that many OO languages violate this principle,|
> |but not Ada which has T'Class and T separate.                                |
> |                                                                             |
> |[. . .]"                                                                     |
> |-----------------------------------------------------------------------------|
> 
> Ada is a strongly typed language so Ada is not an OOP language.

Ada is a strongly typed OO language.

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

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

On Mon, 18 Aug 2025, Dmitry A. Kazakov wrote:
|--------------------------------------|
|"Ada is a strongly typed OO language."|
|--------------------------------------|

Dear Mister Kazakov:

I am curious as to how such an elite expert computer scientist as yourself 
concluded so perversely. Professor Alan Curtis Kay professes: “I’ve been 
shown some very, very strange-looking pieces of code over the years by 
various people, including people in universities, that they have said is 
OOP code, and written in an OOP language—and actually, I made up the term 
object-oriented”. Cf.
Kay, A. C. (1997). The Computer Revolution Hasn’t Happened Yet. In The 
12th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, 
Languages, and Applications.
HTTP://files.Squeak.org/Media/AlanKay/Alan\%20Kay\%20at\%20OOPSLA\%201997\%20-\%20The\%20computer\%20revolution\%20hasnt\%20happened\%20yet.ogg
HTTP://blog.Moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html
HTTP://Gloucester.Insomnia247.NL/Alan_Curtis_Kay/Kay_1997__I_made_up_the_term_object-oriented,_and_I_can_tell_you_I_did_not_have_C++_in_mind.avi

Professor Alan Curtis Kay says that Ada (while calling Ada “ADA” (sic)) is 
not an OOP language but one of the “Better Old Things” about “Abstract 
Data Types which was really staying with an assignment-centered way of 
thinking about programming”.

Contrast
ADA_is_a_good_non-OOP_language_says_Alan_Curtis_Kay.JPG
with
HTTP://Gloucester.Insomnia247.NL/Alan_Curtis_Kay/New_Things_OOP.JPG

Cf.
“Oh, yeah, I had to sigh when Alan Kay, the keynote speaker, had a slide
with Ada spelled as "ADA".” says Gary Kephart, “OOPSLA [was Re: Tri-Ada 
Soars; Hal eats crow -Reply]”, Team-Ada, Wed, 8 Oct 1997 14:16:31 -0700
HTTPS://LISTSERV.ACM.org/SCRIPTS/WA-ACMLPX.CGI?A2=ind9710&L=TEAM-ADA&P=R1772

Cf.
HTTP://Gloucester.Insomnia247.NL/Alan_Curtis_Kay/ADA_is_a_good_non-OOP_language_says_Alan_Curtis_Kay.JPG
Cf.
“Date: Wed, 23 Jul 2003 09:33:31 -0800

To: Stefan Ram [removed for privacy]

From Alan Kay [removed for privacy]

Subject: Re: Clarification of "object-oriented"
[. . .]
The second phase of this was to finally understand LISP and then 

using this understanding to make much nicer and smaller and more 

powerful and more late bound understructures. [. . .]
[. . .]

[. . .]

(I'm not against types, but I don't know of any type systems that 

aren't a complete pain, so I still like dynamic typing.)


OOP to me means only messaging, local retention and protection and 

hiding of state-process, and extreme late-binding of all things. It 

can be done in Smalltalk and in LISP. There are possibly other 

systems in which this is possible, but I'm not aware of them.”
says
HTTPS://userPage.FU-Berlin.De/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_de

Precisely not Ada!

Can you cite an authoritative prescriptive definition for “OO language” 
which compels Professor Kay to confess that he must conclude that he 
himself defined that Ada is an “OO language” despite Ada having “any type 
system” and potentially not demanding messaging and allowing global 
variables and demanding compilation-time checking? I note that you say “OO 
language” about a programming language (Ada), but Professor Kay says “OOP 
language” and Kay says that Ada is not an OOP language. So, do you 
theorize that Ada (i.e. a programming language) can be an “OO language” 
without being an “OOP language”? This really does not convince me! Sorry!

I mean no disrespect against you.

Sincerely.

Re: In precision typing we trust

[J-P. Rosen]

Le 18/08/2025 à 17:03, Dmitry A. Kazakov a écrit :
 >> Ada is a strongly typed language so Ada is not an OOP language.
 >
 > Ada is a strongly typed OO language.

More precisely:
OOP implies a weakening of the typing system, since a wider class can 
contain any object of the subclass.
But in Ada, this can happen only for objects of a class-wide type; so 
you get it only if you ask for it, and you immediately know from the 
type of an object which values it can hold.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-19 08:24, J-P. Rosen wrote:
> Le 18/08/2025 à 17:03, Dmitry A. Kazakov a écrit :
>  >> Ada is a strongly typed language so Ada is not an OOP language.
>  >
>  > Ada is a strongly typed OO language.
> 
> More precisely:
> OOP implies a weakening of the typing system, since a wider class can 
> contain any object of the subclass.
> But in Ada, this can happen only for objects of a class-wide type; so 
> you get it only if you ask for it, and you immediately know from the 
> type of an object which values it can hold.

Yes, however class-wide objects only behave as if they held specific 
type objects. The class-wide type is still a different type, so the type 
system remains strong.

Constrained subtypes are even "weaker" in that respect, e.g. Positive 
vs. Integer.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 19 Aug 2025 09:29:25 +0200, Dmitry A. Kazakov wrote:

> Constrained subtypes are even "weaker" in that respect, e.g. Positive
> vs. Integer.

Subtype restrictions can overlap. In OOP I suppose you would get an 
analogous effect via multiple inheritance.

Re: In precision typing we trust

[Kevin Chadwick]

I get lost in OOP talk. So much...meh.

>
>Constrained subtypes are even "weaker" in that respect, e.g. Positive 
>vs. Integer.

I don't understand this point as you can just use new types instead of
 subtypes as needed.

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-20 17:49, Kevin Chadwick wrote:
> I get lost in OOP talk. So much...meh.
> 
>> Constrained subtypes are even "weaker" in that respect, e.g. Positive 
>> vs. Integer.
> 
> I don't understand this point as you can just use new types instead of
> subtypes as needed.

The point is about the types algebra. If you have any relations between 
types => substitution, you necessarily weaken typing.

Of course you can have nothing of that, but then you loose generic 
programming = programming in terms of sets of types (closed by some 
relation.)

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 19 Aug 2025 08:24:23 +0200, J-P. Rosen wrote:

> OOP implies a weakening of the typing system, since a wider class can
> contain any object of the subclass.

Or conversely, a strengthening, since operations defined only on a 
subclass will not work on the superclass.

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

On Wed, 20 Aug 2025, so became written:
|-----------------------------------------------------------------------|
|"On Tue, 19 Aug 2025 08:24:23 +0200, J-P. Rosen wrote:                 |
|                                                                       |
|> OOP implies a weakening of the typing system, since a wider class can|
|> contain any object of the subclass.                                  |
|                                                                       |
|Or conversely, a strengthening, since operations defined only on a     |
|subclass will not work on the superclass."                             |
|-----------------------------------------------------------------------|

Operations defined only on a subclass would result in a superclass (or any 
unrelated class) receivng a message which does not match its protocol so 
it would crash. That is OOP. We do not need that. That is not Ada. We need 
Ada.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-20 15:59, Niocláisín Cóilín de Ghlostéir wrote:
> On Wed, 20 Aug 2025, so became written:
> |-----------------------------------------------------------------------|
> |"On Tue, 19 Aug 2025 08:24:23 +0200, J-P. Rosen wrote:                 |
> |                                                                       |
> |> OOP implies a weakening of the typing system, since a wider class can|
> |> contain any object of the subclass.                                  |
> |                                                                       |
> |Or conversely, a strengthening, since operations defined only on a     |
> |subclass will not work on the superclass."                             |
> |-----------------------------------------------------------------------|
> 
> Operations defined only on a subclass would result in a superclass (or 
> any unrelated class) receivng a message which does not match its 
> protocol so it would crash. That is OOP. We do not need that. That is 
> not Ada. We need Ada.

Class is a set of types. Subclass is a subset of types.

In Ada's OO a subclass is a set of types derived from some type:

    S <: T

Then S'Class is a subclass of T'Class. E.g.

    type T is tagged ...;
    type S is new T with ...;  -- S'Class is a subclass of T'Class

In no way an operation declared on S:

    procedure F (X : in out S);

can be called on T. Ada is type safe.

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

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

On Wed, 20 Aug 2025, Dmitry A. Kazakov wrote:
|-----------------------------------------------------------------|
|"Then S'Class is a subclass of T'Class. E.g.                     |
|                                                                 |
|   type T is tagged ...;                                         |
|   type S is new T with ...;  -- S'Class is a subclass of T'Class|
|                                                                 |
|In no way an operation declared on S:                            |
|                                                                 |
|   procedure F (X : in out S);                                   |
|                                                                 |
|can be called on T. Ada is type safe."                           |
|-----------------------------------------------------------------|

So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says:
"I don't know of any type systems that

aren't a complete pain, so I still like dynamic typing."
via
HTTPS://userPage.FU-Berlin.De/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_de

Cf. a Smalltalk superclass can receive a subclass message for which no 
superclass counterpart exists, so causing a crash. OOP is poop!

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-20 19:18, Niocláisín Cóilín de Ghlostéir wrote:

> So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says:

To be clear, I don't care what Prof. Kay says.

> Cf. a Smalltalk superclass can receive a subclass message for which no 
> superclass counterpart exists, so causing a crash. OOP is poop!

I care even less about Smalltalk. It is about Ada. I explained that your 
suggestion about Ada subclasses evidently wrong.

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

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Wed, 20 Aug 2025, Dmitry A. Kazakov wrote:
|------------------------------------------------------------------------|
|"On 2025-08-20 19:18, Niocláisín Cóilín de Ghlostéir wrote:             |
|                                                                        |
|> So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says:    |
|                                                                        |
|To be clear, I don't care what Prof. Kay says."                         |
|------------------------------------------------------------------------|

Please stop misusing a term which Prof. Kay coined. If you do not care 
about what Prof. Kay says, then you do not care about object orientation. 
It is fair enough for some person to not care about object orientation. 
Instead, incorrectly boasting about being an OO expert who writes in an OO 
language when this languague - Ada - is not an OO language is a bad idea, 
so please stop so.

|-------------------------------------------------------------------------|
|"> Cf. a Smalltalk superclass can receive a subclass message for which no|
|> superclass counterpart exists, so causing a crash. OOP is poop!        |
|                                                                         |
|I care even less about Smalltalk. It is about Ada. I explained that your |
|suggestion about Ada subclasses evidently wrong."                        |
|-------------------------------------------------------------------------|

I made no "suggestion about Ada subclasses" in this thread, as I clearly 
referred to an OOP language so clearly excluding Ada. Indeed, you actually 
quote me saying: "So Ada is not an OOP language."!

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 20 Aug 2025 22:38:25 +0200, Niocláisín Cóilín de Ghlostéir wrote:

> Please stop misusing a term which Prof. Kay coined.

Did he trademark the term? Or does he own the copyright on it? Did he even 
invent the concept?

No, no and no.

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

The person who invented the word that is "square" did not trademark it; 
did not copyright it; and did not invent the first square. Another thing 
which he did not do is wanting persons to call circles "squares". If 
persons want to talk about circles, then they must not call them 
"squares".

Cf.
HTTPS://WWW.JewishLearningMatters.com/Lesson2-The-Holocaust-The-Role-of-Propaganda-1778.aspx
(but I fail to find any plausible evidence that Goebbels ever really did 
say any such thing about circles and squares).

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 21 Aug 2025 01:37:37 +0200, Niocláisín Cóilín de Ghlostéir wrote:

> Another thing which he did not do is wanting persons to call circles
> "squares".

How did you know? Did you ask?

Re: In precision typing we trust

[Keith Thompson]

Niocláisín Cóilín de Ghlostéir <Spamassassin@irrt.De> writes:
> On Wed, 20 Aug 2025, Dmitry A. Kazakov wrote:
> |------------------------------------------------------------------------|
> |"On 2025-08-20 19:18, Niocláisín Cóilín de Ghlostéir wrote:             |
> |                                                                        |
> |> So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says:    |
> |                                                                        |
> |To be clear, I don't care what Prof. Kay says."                         |
> |------------------------------------------------------------------------|
>
> Please stop misusing a term which Prof. Kay coined. If you do not care 
> about what Prof. Kay says, then you do not care about object orientation. 

Nonsense.  Alan Kay has his own definition of "OOP", but that
definition is not binding on the rest of us.

Smalltalk-style and Simula-style models can both reasonably be
called OOP.

If you happen not to like languages that claim to be OOP but don't
conform to Alan Kay's definition, that's fine, but I don't see
that there's a lot more to say about it.  If you want to discuss
the benefits of one flavor of OOP over another, I suggest that
comp.lang.ada is not the best place for that discussion.

You don't think Ada is OOP.  That's fine.  You're entitled to
your opinion.  But demanding that others must agree with you (and,
I suppose, with Alan Kay) is not useful.  You're not going to change
anyone's minds with appeals to authority.

> It is fair enough for some person to not care about object orientation. 
> Instead, incorrectly boasting about being an OO expert who writes in an OO 
> language when this languague - Ada - is not an OO language is a bad idea, 
> so please stop so.

No.

And please learn to use your newsreader properly.  Quoted text is
conventionally prefixed with "> ", not surrounded by ugly ASCII
boxes.  Using a radically different format for your posts just
makes them more difficult to read.

> |-------------------------------------------------------------------------|
> |"> Cf. a Smalltalk superclass can receive a subclass message for which no|
> |> superclass counterpart exists, so causing a crash. OOP is poop!        |
> |                                                                         |
> |I care even less about Smalltalk. It is about Ada. I explained that your |
> |suggestion about Ada subclasses evidently wrong."                        |
> |-------------------------------------------------------------------------|
>
> I made no "suggestion about Ada subclasses" in this thread, as I clearly 
> referred to an OOP language so clearly excluding Ada. Indeed, you actually 
> quote me saying: "So Ada is not an OOP language."!

This is comp.lang.ada.  If you want to compare Ada to other languages,
that's fine.  If you want to talk about other languages to the
exclusion of Ada, this is not the place.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Re: In precision typing we trust

[Niklas Holsti]

On 2025-08-18 18:03, Dmitry A. Kazakov wrote:
> On 2025-08-18 15:59, Niocláisín Cóilín de Ghlostéir wrote:
>> On Mon, 18 Aug 2025, Dmitry A. Kazakov wrote:
>> |-----------------------------------------------------------------------------|
>> |"These are unrelated issues. Strong typing is 
>> about:                         |
>> |                                                                             |
>> |1. Any object has a type. Note that many OO languages violate this 
>> principle,|
>> |but not Ada which has T'Class and T 
>> separate.                                |
>> |                                                                             |
>> |[. . 
>> .]"                                                                     |
>> |-----------------------------------------------------------------------------|
>>
>> Ada is a strongly typed language so Ada is not an OOP language.
> 
> Ada is a strongly typed OO language.


I would say: Ada supports object-oriented programming, but also supports 
other programming paradigms. So calling Ada an "OO language" is saying 
too little.

Some people called Ada 83 an "object-based" language, perhaps because 
Ada programs typically modelled the real application objects (as 
abstract data types) even before tagged types were available.

It seems to me that the strength of typing in a language is mostly 
orthogonal to the differences between object-oriented programming and 
other paradigms.

But I understand that some people may feel that the "freedom" of weak or 
duck typing is important to their personal programming style, and 
perhaps especially so for object-oriented programming where it has a 
long history, as shown by other posts in this thread.

Re: In precision typing we trust

[Kevin Chadwick]

>
>Some people called Ada 83 an "object-based" language, perhaps because 
>Ada programs typically modelled the real application objects (as 
>abstract data types) even before tagged types were available.
>

This guy researched the origins of OOP with a focus on C++ apparently
 botching it up. I'm not sure how interesting anyone might find it to be.

"https://youtu.be/wo84LFzx5nI"

-- 
Regards, Kc

Re: In precision typing we trust

[Alastair Hogge]

On Wed, 20 Aug 2025 18:54:50 +0000, Kevin Chadwick wrote:


>>Some people called Ada 83 an "object-based" language, perhaps because
>>Ada programs typically modelled the real application objects (as
>>abstract data types) even before tagged types were available.
>>
>>
> This guy researched the origins of OOP with a focus on C++ apparently
>  botching it up. I'm not sure how interesting anyone might find it to
>  be.
> 
> "https://youtu.be/wo84LFzx5nI"

It is with increasing frequency that video presentations, or plain-old 
written articles are making these assertions about OOP, and it's origins, 
and obvious problems in the context of C++. They all ignore Ada, and the 
Lisps, and their contributions, and their sound design in the context of 
OOP. This is a deliberate, disingenuous attack on the viewer's intellect, 
it is an extremely low quality of pedagogy, the only aim of which, is to 
increase the author's social capital.

Casey's presentation is part of a longer history of their critique on C++ 
"OOP" (and good on them, because C++ is a stain on the construction of 
computer science), unfortunately, Casey and the rest stopped being 
humorous years ago, and their over-confident conviction, based on a fad to 
reject critical thinking, and substituting history with their own "modes 
of truth", or their "play on words, and meaning" now become insufferable 
to observe (mostly because of their emphasis on rhetoric, over reason and 
logic, draw too many parallels with conservatism, bordering on proto-
fascism)—the post-modern condition, what an absurd load of shit the world 
now produces.

-- 
To health and anarchy

Re: In precision typing we trust

[Kevin Chadwick]

>
>It is with increasing frequency that video presentations, or plain-old 
>written articles are making these assertions about OOP, and it's origins, 
>and obvious problems in the context of C++. They all ignore Ada, and the 
>Lisps, and their contributions, and their sound design in the context of 
>OOP.

The ignorance of Ada is frustrating but certainly a lot of the newer
 languages are avoiding atleast inheritance (Go, Rust, Odin and Zig).
 Personally I have only used any OOP features in Dart and Ada. In Dart I
 hate the seemingly excessive boiler plate. In Ada I rarely use tagged types
 as they are incompatible with sized record representation which I love
 (perhaps that has changed recently but I don't think so). I therefore know
 little about OOP and I haven't liked inheritance when I have used it. I
 also actually found myself disagreeing with Grady Booch objects are a
 better way diagrams in his Ada books to be honest though. So the point
 about OOP being incompatible with systems thinking might stand.

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 22 Aug 2025 12:49:54 -0000 (UTC), Kevin Chadwick wrote:

> Personally I have only used any OOP features in Dart and Ada. In Dart I
> hate the seemingly excessive boiler plate.

Try Python. Both functions and classes are first-class objects, so there 
is little or no “boilerplate”.

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

On Fri, 22 Aug 2025, Lawrence D’Oliveiro wrote:
|-------------------------------------------------------------------------|
|"On Fri, 22 Aug 2025 12:49:54 -0000 (UTC), Kevin Chadwick wrote:         |
|                                                                         |
|> Personally I have only used any OOP features in Dart and Ada. In Dart I|
|> hate the seemingly excessive boiler plate.                             |
|                                                                         |
|Try Python. Both functions and classes are first-class objects, so there |
|is little or no “boilerplate”."                                          |
|-------------------------------------------------------------------------|

"How Python and Rust handle errors is entirely different. Python will 
throw an exception when an error is encountered. Rust will return a value 
when an error is found, while Python will simply throw an error without 
providing any suggestions on how to fix it. Meanwhile, Rust will provide 
some recommendations to easily pinpoint and fix the issues."
alleges
Victor Lvovich Porton, "Python vs Rust: Choosing Your Language - Teach 
Sector", 2022,
HTTPS://TeachSector.com/python-vs-rust-choosing-your-language

"Switch your mind from nervous mode of finding bugs in your Python 
software (Have you ever mistyped an identifier?) to calm mode of 
multiparadigm programming language of increased reliability."
says
Victor Lvovich Porton, "Learn D Programming Language for Python 
programmers", 2025,
HTTPS://TeachSector.com/dforpython

Cf.
"The dynamic nature of Python usually leads to many programming errors in 
Python code, while D usually catches such errors in the compilation 
stage. This makes it easier to write correct code in D."
alleges
Victor Lvovich Porton, "The Best Python Alternative You Can Find – Course 
and Certifications - Teach Sector", 2025,
HTTPS://TeachSector.com/the-best-python-alternative-you-can-find-course-and-certifications

Cf.
"For OO paradigm it might be important, assuming Python 
implements them correctly, which I honestly doubt."
says
Dmitry A. Kazakov, "Re: Is Python higher level than Ada?",
HTTPS://Usenet.Ada-Lang.IO/comp.lang.ada/o0h7tt$1o9f$1@gioia.aioe.org

Also cf.
Jeffrey R. Carter, "Re: Is Python higher level than Ada?",
Wed, 16 Nov 2016 09:08:37 -0700
Message-ID: <o0i099$fg8$1@dont-email.me>
and
Nasser M. Abbasi, "Java and Python have just discovered 
"record" type finally after 40 years.",
Fri, 12 May 2023 12:50:14 -0500
Message-ID: <u3lu8o$1p3li$1@dont-email.me>

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sat, 23 Aug 2025 01:21:56 +0200, Niocláisín Cóilín de Ghlostéir
wrote:

> "... while Python will simply throw an error without providing any
> suggestions on how to fix it."

    ldo@theon:~> python3
    Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import math
    >>> print(math.arcsin(1))
    Traceback (most recent call last):
      File "<python-input-1>", line 1, in <module>
        print(math.arcsin(1))
              ^^^^^^^^^^^
    AttributeError: module 'math' has no attribute 'arcsin'. Did you mean: 'asin'?

> Cf.
> "For OO paradigm it might be important, assuming Python implements them
> correctly, which I honestly doubt."
> says Dmitry A. Kazakov, "Re: Is Python higher level than Ada?",
> HTTPS://Usenet.Ada-Lang.IO/comp.lang.ada/o0h7tt$1o9f$1@gioia.aioe.org

Really?? Trying to say Ada is better than OO than Python, a language
that has classes as first-class objects?

(More obviously rubbish ones omitted.)

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-24 00:58, Lawrence D’Oliveiro wrote:

>> "For OO paradigm it might be important, assuming Python implements them
>> correctly, which I honestly doubt."
>> says Dmitry A. Kazakov, "Re: Is Python higher level than Ada?",
>> HTTPS://Usenet.Ada-Lang.IO/comp.lang.ada/o0h7tt$1o9f$1@gioia.aioe.org
> 
> Really?? Trying to say Ada is better than OO than Python, a language
> that has classes as first-class objects?

Well, I maintain Ada Python bindings. When I looked at Python "derived" 
types in its API, I was astounded by a total lack of inheritance. The 
base type representation gets overridden by the new. Nothing is 
inherited at all!

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

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

On Sun, 24 Aug 2025, Dmitry A. Kazakov wrote:
|---------------------------------------------------------|
|"When I looked at Python "derived" types in              |
|its API, I was astounded by a total lack of inheritance."|
|---------------------------------------------------------|

Cf. the Java Compiler Compiler makes switch statements.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-24 13:05, Niocláisín Cóilín de Ghlostéir wrote:
> On Sun, 24 Aug 2025, Dmitry A. Kazakov wrote:
> |---------------------------------------------------------|
> |"When I looked at Python "derived" types in              |
> |its API, I was astounded by a total lack of inheritance."|
> |---------------------------------------------------------|
> 
> Cf. the Java Compiler Compiler makes switch statements.

The Burmese python (Python bivittatus) is found on the island of Java in 
Indonesia...

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sun, 24 Aug 2025 14:59:30 +0200, Dmitry A. Kazakov wrote:

> The Burmese python (Python bivittatus) is found on the island of Java in
> Indonesia...

Fun fact: the name of the language “Python” has nothing to do with snakes.

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sun, 24 Aug 2025 10:37:53 +0200, Dmitry A. Kazakov wrote:

> Well, I maintain Ada Python bindings. When I looked at Python "derived"
> types in its API, I was astounded by a total lack of inheritance.

Don’t know what you mean. Python not only has inheritance, it has full 
multiple inheritance with C3 linearization. It also has metaclasses. 
Because classes, like functions, are first-class objects.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-24 23:50, Lawrence D’Oliveiro wrote:
> On Sun, 24 Aug 2025 10:37:53 +0200, Dmitry A. Kazakov wrote:
> 
>> Well, I maintain Ada Python bindings. When I looked at Python "derived"
>> types in its API, I was astounded by a total lack of inheritance.
> 
> Don’t know what you mean.

https://docs.python.org/3/c-api/type.html

PyType_FromSpec etc.

> Python not only has inheritance, it has full
> multiple inheritance with C3 linearization.

No members are inherited. E.g. in Ada

type T is tagged record
    M : Integer;
end record;

type S is new T with record -- S is derived from T
    N : Float;
end record;

declare
    X : S;
begin
    X.M := 1; -- M is inherited

https://stackoverflow.com/questions/10064688/cant-access-parent-member-variable-in-python

Not to say that nothing is checked etc. Expecting that from an untyped 
language would be silly anyway.

But in OO it is incorrect to inherit covariant methods with arguments in 
the out or in-out mode, for example methods returning the type from the 
class:

function Covariant return T;

This would be broken for obvious reasons. So in a properly typed OO 
language, like Ada, you will be required to override Covariant upon 
derivation from T:

overriding
    function Covariant return S;

> It also has metaclasses.
> Because classes, like functions, are first-class objects.

A useless thing in an untyped language and in general one should first 
question what could be the purpose of a set of a set of types? Provided 
one could implement that thing (let's ignore pitiful Python), What 
algorithmic problems one could solve with that?

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

Re: In precision typing we trust

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> It also has metaclasses.
>> Because classes, like functions, are first-class objects.
>
> A useless thing in an untyped language and in general one should first
> question what could be the purpose of a set of a set of types?

Python metaclasses let you specify what is supposed to happen when you
instantiate a class, and that sort of thing.  I.e. it's about runtime
behaviour.

> Provided one could implement that thing (let's ignore pitiful Python),
> What algorithmic problems one could solve with that?

Types in general aren't for solving algorithmic problems.  Thus the
Turing tarpit.  Types are for being able to enforce rules about program
behaviour.

This is still worth reading:

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-25 10:51, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> It also has metaclasses.
>>> Because classes, like functions, are first-class objects.
>>
>> A useless thing in an untyped language and in general one should first
>> question what could be the purpose of a set of a set of types?
> 
> Python metaclasses let you specify what is supposed to happen when you
> instantiate a class, and that sort of thing.  I.e. it's about runtime
> behaviour.

Why do I need to instantiate a class? Provided that it is obviously 
impossible since the class is an open set of types. I simply cannot know 
what is in it. E.g. I can load a DLL at run-time and derive new types there.

The run-time behavior is not defined by "instantiation." It is partly by 
the root type specification and partly by the implementations of the 
class members = specific types.

>> Provided one could implement that thing (let's ignore pitiful Python),
>> What algorithmic problems one could solve with that?
> 
> Types in general aren't for solving algorithmic problems.  Thus the
> Turing tarpit.  Types are for being able to enforce rules about program
> behaviour.

... and the program behavior is about solving algorithmic problems.

In the hierarchy:

value
type (a set of values)
class (a set of types)
metaclass (a set of classes)

What sort of problems metaclass is supposed to help solving, describing, 
abstracting. What is a closure operation of. E.g. dynamically 
polymorphic classes are closed upon type derivation. What would be the 
type algebraic operation to construct a set of sets of types? What are 
the typical properties shared by the members of a metaclass?

You can continue the above hierarchy ad infinitum and beyond. But what for?

> This is still worth reading:
> 
> https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

It does not mention types of types.

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

Re: In precision typing we trust

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Why do I need to instantiate a class? Provided that it is obviously
> impossible since the class is an open set of types.

You aren't using the term "class" the way Python or the rest of the OOP
world does.  You also aren't in charge of which usage is "correct".  The
term is used in many different ways.

You can read more about metaclasses here:

   https://en.wikipedia.org/wiki/Metaclass

The article gives a Python example.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-25 19:12, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Why do I need to instantiate a class? Provided that it is obviously
>> impossible since the class is an open set of types.
> 
> You aren't using the term "class" the way Python or the rest of the OOP
> world does.

Call the thing (a set of types closed under derivation) the way you want.

If class means type, fine. The question remains why should I need to 
instantiate it beyond declaring an object of? E.g. FORTRAN-IV

    REAL*8 X

works fine without classes, metaclasses etc.

> You also aren't in charge of which usage is "correct".  The
> term is used in many different ways.

Can you provide a citation where I said anything about correct wording?

I merely asked you what were a practical purpose of having metaclasses 
in programming without buzz words.

> You can read more about metaclasses here:
> 
>     https://en.wikipedia.org/wiki/Metaclass

 From the text:

"In object-oriented programming, a metaclass is a class whose instances 
are classes themselves"

How is that, except for sloppiness "class is ... a class", different 
from a set of sets of types?

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Mon, 25 Aug 2025 22:09:14 +0200, Dmitry A. Kazakov wrote:

> The question remains why should I need to instantiate it beyond
> declaring an object of?

Because in Python a class, like all objects, is created at runtime, not 
compile time.

Think of a class definition, like a function definition, as just a special 
form of assignment statement. It’s not a declaration: every time it is 
executed (“elaborated” if you prefer the Ada term), it creates a new 
object.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-25 23:13, Lawrence D’Oliveiro wrote:
> On Mon, 25 Aug 2025 22:09:14 +0200, Dmitry A. Kazakov wrote:
> 
>> The question remains why should I need to instantiate it beyond
>> declaring an object of?
> 
> Because in Python a class, like all objects, is created at runtime, not
> compile time.

You mean type objects:

https://docs.python.org/3/c-api/type.html

so what?

> Think of a class definition, like a function definition, as just a special
> form of assignment statement.

Both are not.

> It’s not a declaration: every time it is
> executed (“elaborated” if you prefer the Ada term), it creates a new
> object.

Definition /= declaration. Executing definition creates an object, just 
like in any language.

You still did not explain what the buzz. If "metaclass" is merely a 
definition then OK. Nothing new, nothing interesting.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 26 Aug 2025 09:59:48 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-25 23:13, Lawrence D’Oliveiro wrote:
>>
>> On Mon, 25 Aug 2025 22:09:14 +0200, Dmitry A. Kazakov wrote:
>> 
>>> The question remains why should I need to instantiate it beyond
>>> declaring an object of?
>> 
>> Because in Python a class, like all objects, is created at runtime, not
>> compile time.
> 
> You mean type objects:

Types are objects in Python, I thought we already said that.

>> Think of a class definition, like a function definition, as just a
>> special form of assignment statement.
> 
> Both are not.
> 
>> It’s not a declaration: every time it is executed (“elaborated” if you
>> prefer the Ada term), it creates a new object.
> 
> Definition /= declaration. Executing definition creates an object, just
> like in any language.

No. In Ada, C or C++, definitions are not “executable”. They do not 
“create objects”.

Think of a function that is a class factory: each time it is called, it 
creates and returns a new class as the function result. This depends 
crucially on a) classes as first-class objects, and also b) lexical 
binding.

Can you do that in Ada, C or C++? No you cannot. You can do it in Python.

> You still did not explain what the buzz.

See my posting elsewhere about the metaclass example.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-27 02:13, Lawrence D’Oliveiro wrote:
> On Tue, 26 Aug 2025 09:59:48 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-25 23:13, Lawrence D’Oliveiro wrote:
>>>
>>> On Mon, 25 Aug 2025 22:09:14 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> The question remains why should I need to instantiate it beyond
>>>> declaring an object of?
>>>
>>> Because in Python a class, like all objects, is created at runtime, not
>>> compile time.

Not true, because in Python there exist types created before the 
interpreter starts. But it is irrelevant.

In Ada types can be created dynamically:

    declare
       type T is ...
    begin
       ...
    end;

The difference is that the semantics of such types is static in Ada and 
undefined in Python.

> No. In Ada, C or C++, definitions are not “executable”. They do not
> “create objects”.

Of course they are executable. They may or may not produce objects.
> Think of a function that is a class factory: each time it is called, it
> creates and returns a new class as the function result. This depends
> crucially on a) classes as first-class objects, and also b) lexical
> binding.
> 
> Can you do that in Ada, C or C++? No you cannot.

Yes I can. It is actively used in software design. E.g. for plug-ins, 
library implementing a driver derives  a type from the base type.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 27 Aug 2025 09:39:59 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-27 02:13, Lawrence D’Oliveiro wrote:
>>
>> On Tue, 26 Aug 2025 09:59:48 +0200, Dmitry A. Kazakov wrote:
>> 
>>> On 2025-08-25 23:13, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Mon, 25 Aug 2025 22:09:14 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> The question remains why should I need to instantiate it beyond
>>>>> declaring an object of?
>>>>
>>>> Because in Python a class, like all objects, is created at runtime,
>>>> not compile time.
> 
> Not true, because in Python there exist types created before the
> interpreter starts.

No. Builtins are created as part of interpreter startup, not before. Prove 
me wrong.

> In Ada types can be created dynamically:
> 
>     declare
>        type T is ...
>     begin
>        ...
>     end;
> 
> The difference is that the semantics of such types is static in Ada and
> undefined in Python.

Please show us Python code demonstrating how they are “undefined in 
Python”.

>> No. In Ada, C or C++, definitions are not “executable”. They do not
>> “create objects”.
> 
> Of course they are executable.

So I can do something like

    function F ... is
    declare
       type T is ...
    begin
       ...
       return T;
    end;

in Ada?

>> Think of a function that is a class factory: each time it is called, it
>> creates and returns a new class as the function result. This depends
>> crucially on a) classes as first-class objects, and also b) lexical
>> binding.
>> 
>> Can you do that in Ada, C or C++? No you cannot.
> 
> Yes I can. It is actively used in software design. E.g. for plug-ins,
> library implementing a driver derives  a type from the base type.

Show us.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 01:10, Lawrence D’Oliveiro wrote:

> So I can do something like
> 
>      function F ... is
>      declare
>         type T is ...
>      begin
>         ...
>         return T;
>      end;
> 
> in Ada?

No, you cannot spell such a function. Ada is a typed language:

   function F return T is -- T is undefined
      type T is ...;
   begin

>> Yes I can. It is actively used in software design. E.g. for plug-ins,
>> library implementing a driver derives  a type from the base type.
> 
> Show us.
It is a proprietary code. You can write it yourself.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 01:49:18 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-28 01:10, Lawrence D’Oliveiro wrote:
> 
>> So I can do something like
>> 
>>      function F ... is declare
>>         type T is ...
>>      begin
>>         ...
>>         return T;
>>      end;
>> 
>> in Ada?
> 
> No, you cannot spell such a function. Ada is a typed language:

But I thought you said “In Ada types can be created dynamically”? So it 
turns out that’s wrong? Because I can do that in Python.

>>> Yes I can. It is actively used in software design. E.g. for plug-ins,
>>> library implementing a driver derives  a type from the base type.
>> 
>> Show us.
>
> It is a proprietary code. You can write it yourself.

So you can’t actually show us any example of such a feature, to prove it 
exists? Too bad ...

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 02:35, Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 01:49:18 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-28 01:10, Lawrence D’Oliveiro wrote:
>>
>>> So I can do something like
>>>
>>>       function F ... is declare
>>>          type T is ...
>>>       begin
>>>          ...
>>>          return T;
>>>       end;
>>>
>>> in Ada?
>>
>> No, you cannot spell such a function. Ada is a typed language:
> 
> But I thought you said “In Ada types can be created dynamically”? So it
> turns out that’s wrong? Because I can do that in Python.

You cannot refer to a type before you created it, except specific cases 
of incomplete declarations.

In Python you cannot do that either. What you can in Python is to 
declare a function that returns nobody knows what, because Python is 
untyped.

> So you can’t actually show us any example of such a feature, to prove it
> exists? Too bad ...

I can explain how it works. When a DLL is loaded its library level gets 
elaborated. So if you have:

package P is
    type T is tagged ...
end P;

in the main program or DLL and

with P;
package Q is
    type S is new T with ...
    function F return T'Class;
end Q;

in the DLL being loaded, then in the process of elaboration S will be 
created which in particular means extending of the dispatching table. 
You can return a class-wide object from there and dispatch on the newly 
created type's operation.

Clear?

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

Re: In precision typing we trust

[Kevin Chadwick]

>
>I can explain how it works. When a DLL is loaded its library level gets 
>elaborated. So if you have:
>
>package P is
>    type T is tagged ...
>end P;
>
>in the main program or DLL and
>
>with P;
>package Q is
>    type S is new T with ...
>    function F return T'Class;
>end Q;
>
>in the DLL being loaded, then in the process of elaboration S will be 
>created which in particular means extending of the dispatching table. 
>You can return a class-wide object from there and dispatch on the newly 
>created type's operation.
>
>Clear?

Interesting, better than the shape examples but I guess you have to get that
 in the first instance.

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 10:50, Kevin Chadwick wrote:
> 
>>
>> I can explain how it works. When a DLL is loaded its library level 
>> gets elaborated. So if you have:
>>
>> package P is
>>    type T is tagged ...
>> end P;
>>
>> in the main program or DLL and
>>
>> with P;
>> package Q is
>>    type S is new T with ...
>>    function F return T'Class;
>> end Q;
>>
>> in the DLL being loaded, then in the process of elaboration S will be 
>> created which in particular means extending of the dispatching table. 
>> You can return a class-wide object from there and dispatch on the 
>> newly created type's operation.
>>
>> Clear?
> 
> Interesting, better than the shape examples but I guess you have to get 
> that in the first instance.

Dynamic polymorphism is an extremely powerful mechanism, but it kind of 
bends out of traditional typing.

It is like the relativity theory. Everything is relative, position, 
velocity, but up to the point. Acceleration is not anymore. Same is with 
typing: value->type, so far so good, but one more step up: 
value->type->class and something happens. Primitive operations become 
reachable even if you do not see them, you cannot hide them. Multiple 
inheritance, OK, but what about conflicts, is it additive or idempotent? 
Multiple dispatch is a total dark hole.

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

Re: In precision typing we trust

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Call the thing (a set of types closed under derivation) the way you want.

Classes in Python aren't sets of types.  For example, 3 isn't a type,
but in Python 3 it's a member of class 'int'.

    >>> a = 3
    >>> a.__class__
    <class 'int'>

Classes in Python are analogous to types in type theory, but Python
isn't lambda calculus.

    How is that, except for sloppiness "class is ... a class", different
    from a set of sets of types?

Metaclasses in Python are used to control the runtime semantics of newly
created classes.  E.g. what happens when you create a class instance.

It's not really useful to think of Python types as sets.  Python isn't
that mathematical.  You could think of them as sorts, in the sense of
multi-sorted logic.  Each Python value has a label attached to it (the
type tag) that can be inspected at runtime.  Those types are also
sometimes called latent types.

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Mon, 25 Aug 2025 14:27:55 -0700, Paul Rubin wrote:

> It's not really useful to think of Python types as sets.  Python isn't
> that mathematical.

Duck-typing, on the other hand, does make sense in terms of grouping 
Python objects into (possibly overlapping) sets. E.g. a function that 
wants to write to what is nominally an output text file might happily 
accept any object that has a “.write()” method that takes a string 
argument.

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Mon, 25 Aug 2025 10:19:50 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-24 23:50, Lawrence D’Oliveiro wrote:
>>
>> Python not only has inheritance, it has full multiple inheritance
>> with C3 linearization.
> 
> No members are inherited.

    from enum import \
        Enum

    class MYENUM(int, Enum) :
        VAL1 = 1
        VAL3 = 3
    #end MYENUM

    print(isinstance(MYENUM.VAL1, int), isinstance(MYENUM.VAL1, MYENUM))

    True True

    print(MYENUM.VAL1 + 1)

    2

    print(MYENUM(3))

    MYENUM.VAL3

    print(MYENUM(2))

    ---------------------------------------------------------------------------
    ValueError                                Traceback (most recent call last)

    [detailed traceback omitted]

    ValueError: 2 is not a valid MYENUM

> Not to say that nothing is checked etc. Expecting that from an untyped
> language would be silly anyway.

Python is strongly typed.

> But in OO it is incorrect to inherit covariant methods with arguments in
> the out or in-out mode ...

That’s OK, because Python only has “in” mode.

>> It also has metaclasses. Because classes, like functions, are
>> first-class objects.
>
> A useless thing in an untyped language ...

Except Python is strongly typed.

> ... and in general one should first question what could be the
> purpose of a set of a set of types?

It does away with the need for generics and a separate compile-time
language for working with them. Instead, you use the same run-time
language as you would for everything else.

Also, this
<https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Uses%20For%20Metaclasses.ipynb>.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-25 23:10, Lawrence D’Oliveiro wrote:
> On Mon, 25 Aug 2025 10:19:50 +0200, Dmitry A. Kazakov wrote:

>> Not to say that nothing is checked etc. Expecting that from an untyped
>> language would be silly anyway.
> 
> Python is strongly typed.

Yep, as you can pass everything to anything:

def F(X):
    X = X + 1
F(F)

Very, very strong typing!

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

Re: In precision typing we trust

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Yep, as you can pass everything to anything:
>
> def F(X):
>    X = X + 1
> F(F)

> Very, very strong typing!

==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'

The typechecking is done at runtime, just like it says on the tin.

Re: In precision typing we trust

[Kevin Chadwick]

On 26/08/2025 17:48, Paul Rubin wrote:
>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Yep, as you can pass everything to anything:
>>
>> def F(X):
>>    X = X + 1
>> F(F)
>
>> Very, very strong typing!
>
>==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'
>
>The typechecking is done at runtime, just like it says on the tin.

Wouldn't that make Python slow and unreliable?

One of the reasons I switched to Ada from Go was all the potential stdlib
 panics.

Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-26 19:01, Kevin Chadwick wrote:

> Wouldn't that make Python slow and unreliable?

Python is incredibly slow, but that is not the point. It is untyped and 
thus unsafe. One simply cannot talk about reliability because there is 
no types to be checked, no interfaces, no contracts, nothing. In no way 
you could reason about program correctness without running it.

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

Re: In precision typing we trust

[Paul Rubin]

Kevin Chadwick <kc-usenet@chadwicks.me.uk> writes:
> Wouldn't that make Python slow and unreliable?

It's slow but that's due to the rather simple implementation.  SBCL
Common Lisp is reasonably fast.  Python is reasonably reliable in the
sense that programs with errors will probably crash instead of going off
into the weeds.  The saying is that correct code is great, code that
crashes could use improvement, but incorrect code that keeps running and
delivering wrong results is a disaster.

Joe Armstrong (inventor of Erlang) also liked to say that there is no
such thing as a reliable non-distributed system, since the power cord is
a single point of failure By that standard, Ada isn't so reliable
either.

[Dmitry A. Kazakov writes:]

> The error occurred inside the body of F. F itself was successfully
> called, because it is untyped. Just as I said.

F didn't encounter a type error until it tried to do arithmetic on its
argument.  If it instead called its argument based on some decision,
that wouldn't have been a type error.  You don't get to decide whether
that counts as a type system or not.  It's just a coarser version of Ada
doing runtime checks on array subscripts and integer overflow, instead
of statically verifying that they are in range (a proof system like Agda
would consider those to also be type errors).

Same article I posted before, "What to know before debating type
systems":

https://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 26 Aug 2025 17:00:58 -0700, Paul Rubin wrote:

> Joe Armstrong (inventor of Erlang) also liked to say that there is no
> such thing as a reliable non-distributed system, since the power cord is
> a single point of failure

Did he not know about laptops?

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-27 02:00, Paul Rubin wrote:

> F didn't encounter a type error until it tried to do arithmetic on its
> argument.

It didn't encounter error before executing erroneous code... (:-))

> If it instead called its argument based on some decision,
> that wouldn't have been a type error.

Sure. But this is not a type error, it is untyped.

> You don't get to decide whether
> that counts as a type system or not.  It's just a coarser version of Ada
> doing runtime checks on array subscripts and integer overflow,

Wrong. Checking constraints is a defined behavior. The type is defined 
so that exception is a part of the operation's contract. The operation 
is bounded by that contract. In Python the contract of an operation (if 
Python were typed) is an open ended and thus non-existent as such.

> instead
> of statically verifying that they are in range (a proof system like Agda
> would consider those to also be type errors).

Nope, these are not type errors. In a strongly typed language that thing 
does not exist per definition because all type errors are detected at 
compile time.

The discussion was whether this would require weakening the type system 
strength. Python here is really of zero interest.

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

Re: In precision typing we trust

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
[...]
> The discussion was whether this would require weakening the type
> system strength. Python here is really of zero interest.

Then why do you keep talking about Python here?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-27 22:45, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [...]
>> The discussion was whether this would require weakening the type
>> system strength. Python here is really of zero interest.
> 
> Then why do you keep talking about Python here?

Because Python fans hijacked the discussion.

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

Re: In precision typing we trust

[Von Ottone]

On Thu, 28 Aug 2025 10:38:46 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On 2025-08-27 22:45, Keith Thompson wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> [...]
>>> The discussion was whether this would require weakening the type
>>> system strength. Python here is really of zero interest.
>> 
>> Then why do you keep talking about Python here?
>
>Because Python fans hijacked the discussion.

Don't mind Keith Thompson, he is the pedantic one of the whole galaxy
of programming-languages newsgroups.

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 27 Aug 2025 09:51:30 +0200, Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2025 17:00:58 -0700, Paul Rubin wrote:
>>
>> If it instead called its argument based on some decision,
>> that wouldn't have been a type error.
> 
> Sure. But this is not a type error, it is untyped.
>
> On Tue, 26 Aug 2025 09:48:51 -0700, Paul Rubin wrote:
>
>> ==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'

Need I say more?

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 01:16, Lawrence D’Oliveiro wrote:
> On Wed, 27 Aug 2025 09:51:30 +0200, Dmitry A. Kazakov wrote:
> 
>> On Tue, 26 Aug 2025 17:00:58 -0700, Paul Rubin wrote:
>>>
>>> If it instead called its argument based on some decision,
>>> that wouldn't have been a type error.
>>
>> Sure. But this is not a type error, it is untyped.
>>
>> On Tue, 26 Aug 2025 09:48:51 -0700, Paul Rubin wrote:
>>
>>> ==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'
> 
> Need I say more?

Yes:

def F(X):
    raise TypeError ("?")
F(1)

Hint: Type errors and errors in general cannot be checked at run-time. 
Errors are bugs. Dynamic checking and raising exception is not a bug, it 
is a behavior.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 10:48:13 +0200, Dmitry A. Kazakov wrote:

> Hint: Type errors and errors in general cannot be checked at run-time.

They most certainly can.

> Errors are bugs.

Possibly. But the bug might be at the other end of a comms connection in 
somebody else’s code, not at my end. Their end might even be written in 
Ada, for all I know.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-29 05:57, Lawrence D’Oliveiro wrote:

> But the bug might be at the other end of a comms connection in
> somebody else’s code, not at my end.

That is not an error in your code. You confuse errors with exceptional 
states. No program can check correctness of itself.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 09:53:42 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-29 05:57, Lawrence D’Oliveiro wrote:
> 
>> But the bug might be at the other end of a comms connection in somebody
>> else’s code, not at my end.
> 
> That is not an error in your code.

You were the one saying “errors are bugs”. Not changing your mind now, are 
you?

> You confuse errors with exceptional states.

Exceptions are a great way to handle a lot of error cases.

> No program can check correctness of itself.

Not sure what this is supposed to be relevant to, but surely a language as 
heavily used in safety-critical applications as Ada would typically see a 
lot of cross-checking happening in real-world programs.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-31 00:29, Lawrence D’Oliveiro wrote:
> On Fri, 29 Aug 2025 09:53:42 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-29 05:57, Lawrence D’Oliveiro wrote:
>>
>>> But the bug might be at the other end of a comms connection in somebody
>>> else’s code, not at my end.
>>
>> That is not an error in your code.
> 
> You were the one saying “errors are bugs”. Not changing your mind now, are
> you?

Are you aware that there may exist more than one program? (:-))

>> You confuse errors with exceptional states.
> 
> Exceptions are a great way to handle a lot of error cases.

Bugs are handled by text editor. Exceptions are a program control flow 
mechanism.

>> No program can check correctness of itself.
> 
> Not sure what this is supposed to be relevant to, but surely a language as
> heavily used in safety-critical applications as Ada would typically see a
> lot of cross-checking happening in real-world programs.

None of which is a correctness check.

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

Re: In precision typing we trust

[Björn Persson]

Paul Rubin wrote:
> Python is reasonably reliable in the
> sense that programs with errors will probably crash instead of going off
> into the weeds.  The saying is that correct code is great, code that
> crashes could use improvement, but incorrect code that keeps running and
> delivering wrong results is a disaster.

Then let me tell you about a disaster.

I once worked with a team of testers who wrote their testcases in
Python. Each testcase was supposed to return True or False to report
whether the test had succeeded or failed. Some testcases returned the
string "true" or "false" instead. When an if statement is applied to a
string in Python, "" is considered false but "false" is considered true.
Thus the test framework kept running and reported the failing test as
successful. The testers didn't notice. They didn't have tests to test
their testcases.

Whether that's reasonably reliable depends on one's opinion on what's
reasonable, I suppose.

As you guys are arguing – or rather talking past each other – about
Python in comp.lang.ada, can I assume that you all know what an Ada
compiler would do with such code?

Björn Persson

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 14:25:57 +0200, Björn Persson wrote:

> I once worked with a team of testers who wrote their testcases in
> Python. Each testcase was supposed to return True or False to report
> whether the test had succeeded or failed. Some testcases returned
> the string "true" or "false" instead.

Shouldn’t your test harness have had something like

    result_of_test = test_routine(*test_args, **test_kwargs)
    assert isinstance(result_of_test, bool), \
        "unexpected test result %s" % result_of_test
    if result_of_test :
        ... chalk up another success ..
    else :
        ... chalk up another failure ..
    #end if

It only takes one extra line of code to do that typecheck.

Re: In precision typing we trust

[Björn Persson]

Lawrence D’Oliveiro wrote:
> Shouldn’t your test harness have had something like
> 
>     assert isinstance(result_of_test, bool), \

Nope. The Python interpreter should, at a minimum, have done that as
part of its implementation of the if statement. But you already
understood that much; you're just wilfully refusing to get the point.

A better design would have checked the type at compile time. Then the
tester who wrote "false" would have fixed their mistake right away, and
learned from it. I mean, you do know which newsgroup it is you're
promoting Python in.

Programmers are human. Humans make mistakes. A well-designed
programming language helps the programmer avoid mistakes as much as
possible, and to discover their mistakes as early as possible.
Languages that go out of their way to interpret an obvious mistake as a
valid program are prone to what Paul called disaster.

Björn Persson

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 17:30:21 +0200, Björn Persson wrote:

> Lawrence D’Oliveiro wrote:
>>
>> Shouldn’t your test harness have had something like
>> 
>>     assert isinstance(result_of_test, bool), \
> 
> Nope. The Python interpreter should, at a minimum, have done that as
> part of its implementation of the if statement.

Yes, the issue with the if-statement condition not being required to be of 
a boolean type.

Python types are dynamic. So you need to check them at run-time. That goes 
with the territory.

> But you already understood that much; you're just wilfully refusing to
> get the point.

Now you’re trying to make this into some kind of personal thing. Stop it.

> A better design would have checked the type at compile time.

Remember Alan Kay’s dictum: “Simple things should be simple, and complex 
things should be possible”.

Ada may be helpful with keeping complex things manageable. But Python 
helps keep simple things simple, in a way that Ada cannot.

Re: In precision typing we trust

[Kevin Chadwick]

>
>Ada may be helpful with keeping complex things manageable. But Python 
>helps keep simple things simple, in a way that Ada cannot.

I don't know if there is *ANY* truth to that as I do not use Python but your
 example seems to suggest Python has complicated gotchas where Ada is
 simple. The code you linked didn't seem anywhere near as readable as Ada
 either.

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sat, 30 Aug 2025 08:49:22 -0000 (UTC), Kevin Chadwick wrote:

>> Ada may be helpful with keeping complex things manageable. But Python
>> helps keep simple things simple, in a way that Ada cannot.
>
> I don't know if there is *ANY* truth to that as I do not use Python
> but your example seems to suggest Python has complicated gotchas
> where Ada is simple. The code you linked didn't seem anywhere near
> as readable as Ada either.

You mean the BitVector example? That was a dump from a Jupyter
notebook, in “asciidoc” format, with various indicators as to what was
input source and what was program output. Here’s what the code looks
like without that:

    # constructor: v = BitVector(«width»[, «init»])
    # «init» defaults to all zeroes if omitted
    v1 = BitVector(3, 2)
    v2 = BitVector(5)
    v1, v2, int(v1), int(v2)

    # access can be single bits, or use standard Python slice notation
    v1[0:2], v1[2], v1[1:3], v2[2:5]

    v1[1:3] = [False, True]
    v2[:] = 13

    v1, v2, int(v1), int(v2)

    # “+” does concatenation of BitVectors; note little-endian ordering.
    v1 + v2, int(v1 + v2)

    # shifts produce results with same number of bits
    v2, v2 >> 3, v2 << 3, v2[:3] << 3, (v2 + BitVector(3)) << 3

    v1[1:3]

    Following all raise errors

    v2[:1] = v1

    v1[:] = 8

    v2[0] = 2

    v1[:] = v2[:]

I’ll leave you to go back and reread the other posting, to see how the
output relates to that ...

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 26 Aug 2025 17:01:08 -0000 (UTC), Kevin Chadwick wrote:

> On 26/08/2025 17:48, Paul Rubin wrote:
>>
>> The typechecking is done at runtime, just like it says on the tin.
>
> Wouldn't that make Python slow and unreliable?

It is slower than C code, but remember, it is a very-high-level
language, so for many purposes it saves a lot on development time.
This is why it has come to dominate the field for data science, ETL,
that kind of thing.

Consider this file format
<https://manpages.debian.org/proc_pid_mountinfo(5)>: how much C (or
Ada) code would you need to write to parse it? I wrote a
general-purpose Python function to do it: including a custom class for
representing each result line, and a utility function for decoding
those pesky octal escapes, the total came to 82 lines (including
blanks).

You can see my Python code here
<https://gitlab.com/ldo/python_linuxfs/-/blob/master/linuxfs.py#L724>.
For its purposes, it is plenty fast.

Re: In precision typing we trust

[Kevin Chadwick]

On 27/08/2025 01:09, Lawrence D\x19Oliveiro wrote:
>On Tue, 26 Aug 2025 17:01:08 -0000 (UTC), Kevin Chadwick wrote:
>
>> On 26/08/2025 17:48, Paul Rubin wrote:
>>>
>>> The typechecking is done at runtime, just like it says on the tin.
>>
>> Wouldn't that make Python slow and unreliable?
>
>It is slower than C code, but remember, it is a very-high-level
>language, so for many purposes it saves a lot on development time.
>This is why it has come to dominate the field for data science, ETL,
>that kind of thing.
>
>Consider this file format
><https://manpages.debian.org/proc_pid_mountinfo(5)>: how much C (or
>Ada) code would you need to write to parse it? I wrote a
>general-purpose Python function to do it: including a custom class for
>representing each result line, and a utility function for decoding
>those pesky octal escapes, the total came to 82 lines (including
>blanks).
>
>You can see my Python code here
><https://gitlab.com/ldo/python_linuxfs/-/blob/master/linuxfs.py#L724>.
>For its purposes, it is plenty fast.

I'm not sure what I'm looking at in that link but sounds about right. I'm
 getting the impression that some responders here have hardly used Ada.

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-26 18:48, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Yep, as you can pass everything to anything:
>>
>> def F(X):
>>     X = X + 1
>> F(F)
> 
>> Very, very strong typing!
> 
> ==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'
> 
> The typechecking is done at runtime, just like it says on the tin.

The error occurred inside the body of F. F itself was successfully 
called, because it is untyped. Just as I said.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Tue, 26 Aug 2025 21:36:29 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-26 18:48, Paul Rubin wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Yep, as you can pass everything to anything:
>>>
>>> def F(X):
>>>     X = X + 1
>>> F(F)
>> 
>>> Very, very strong typing!
>> 
>> ==>  TypeError: unsupported operand type(s) for +: 'function' and 'int'
>> 
>> The typechecking is done at runtime, just like it says on the tin.
> 
> The error occurred inside the body of F. F itself was successfully 
> called, because it is untyped. Just as I said.

No, it was successfully entered, not successfully left. Remember, “call” 
means both “transfer” to and “return from” (otherwise it becomes “goto”, 
not “call”). That was not a “successful call”.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-27 02:10, Lawrence D’Oliveiro wrote:

> No, it was successfully entered,

And that is all one need to know.

> not successfully left.

Of course it left successfully. The interpreted did not crashed!

Hint: You cannot define the type semantics of a function in an untyped 
language. That is just what untyped means.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 27 Aug 2025 09:57:28 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-27 02:10, Lawrence D’Oliveiro wrote:
> 
>> No, it was successfully entered,
> 
> And that is all one need to know.
>>
> Remember, “call” means both “transfer” to and “return from”
> (otherwise it becomes “goto”, not “call”). That was not a
> “successful call”.

>> not successfully left.
> 
> Of course it left successfully. The interpreted did not crashed!

Python does not allow resume semantics for exceptions. Otherwise the 
function would have continued executing, which it did not.

> Hint: You cannot define the type semantics of a function in an untyped
> language. That is just what untyped means.

Not sure why that’s relevant, since Python is very much typed, and quite 
strongly typed too.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 01:12, Lawrence D’Oliveiro wrote:
> On Wed, 27 Aug 2025 09:57:28 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-27 02:10, Lawrence D’Oliveiro wrote:
>>
>>> No, it was successfully entered,
>>
>> And that is all one need to know.
>>>
>> Remember, “call” means both “transfer” to and “return from”
>> (otherwise it becomes “goto”, not “call”). That was not a
>> “successful call”.
> 
>>> not successfully left.
>>
>> Of course it left successfully. The interpreted did not crashed!
> 
> Python does not allow resume semantics for exceptions. Otherwise the
> function would have continued executing, which it did not.

It continued. The function returned Null_Object and flagged an active 
exception state. See

https://docs.python.org/3/c-api/exceptions.html

for how Python works.

And no Python does not support proper zero overhead exceptions like Ada.

>> Hint: You cannot define the type semantics of a function in an untyped
>> language. That is just what untyped means.
> 
> Not sure why that’s relevant,

It is, because typed means in particular definite types of subprogram 
arguments and results.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 02:07:58 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-28 01:12, Lawrence D’Oliveiro wrote:
>>
>> Python does not allow resume semantics for exceptions. Otherwise the
>> function would have continued executing, which it did not.
> 
> It continued. The function returned Null_Object and flagged an active
> exception state.

You are confusing the internal workings of the implementation with the 
actual language semantics.

> See
> 
> https://docs.python.org/3/c-api/exceptions.html
> 
> for how Python works.

Think of that as the dumbed-down explanation, for those who can only think 
in terms of conventional languages like C, C++ or Ada. If that’s all you 
can handle ... well, you do you.

>>> Hint: You cannot define the type semantics of a function in an untyped
>>> language. That is just what untyped means.
>> 
>> Not sure why that’s relevant,
> 
> It is, because typed means in particular definite types of subprogram
> arguments and results.

Python arguments and results are always of a definite type.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 02:38, Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 02:07:58 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-28 01:12, Lawrence D’Oliveiro wrote:
>>>
>>> Python does not allow resume semantics for exceptions. Otherwise the
>>> function would have continued executing, which it did not.
>>
>> It continued. The function returned Null_Object and flagged an active
>> exception state.
> 
> You are confusing the internal workings of the implementation with the
> actual language semantics.

What semantics? F is called. F is returned. Where in the code any 
semantics was stated?

>> See
>>
>> https://docs.python.org/3/c-api/exceptions.html
>>
>> for how Python works.
> 
> Think of that as the dumbed-down explanation, for those who can only think
> in terms of conventional languages like C, C++ or Ada. If that’s all you
> can handle ... well, you do you.

There is nothing unconventional in command line interpreters, except for 
extremely ugly syntax, e.g. Python, Bash, Windows Cmd. But that seems to 
be a kind of convention, isn't it? (:-))

>>>> Hint: You cannot define the type semantics of a function in an untyped
>>>> language. That is just what untyped means.
>>>
>>> Not sure why that’s relevant,
>>
>> It is, because typed means in particular definite types of subprogram
>> arguments and results.
> 
> Python arguments and results are always of a definite type.

Can you name them in the example given? It seems that you confuse 
objects with formal arguments.

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

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-25 23:10, Lawrence D’Oliveiro wrote:
> On Mon, 25 Aug 2025 10:19:50 +0200, Dmitry A. Kazakov wrote:

>> But in OO it is incorrect to inherit covariant methods with arguments in
>> the out or in-out mode ...
> 
> That’s OK, because Python only has “in” mode.

You must be joking. I cannot return a value from a function?

Ah, yes, in a "strongly" typed Python you cannot tell if there is a 
result nor can you dispatch on it...

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

Re: In precision typing we trust

[Kevin Chadwick]

\r>Try Python.

No thank you. Very happy with Ada. In fact I plan to run Ada as the business
 logic within Flutter via FFI assuming the boiler plate of that isn't too
 bad.

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sat, 23 Aug 2025 00:26:11 -0000 (UTC), Kevin Chadwick wrote:

>> Try Python. Both functions and classes are first-class objects, so
>> there is little or no “boilerplate”.
> 
> No thank you. Very happy with Ada.

And all its boilerplate?

Re: In precision typing we trust

[Kevin Chadwick]

On 23/08/2025 23:59, Lawrence D\x19Oliveiro wrote:
>On Sat, 23 Aug 2025 00:26:11 -0000 (UTC), Kevin Chadwick wrote:
>
>>> Try Python. Both functions and classes are first-class objects, so
>>> there is little or no “boilerplate”.
>> 
>> No thank you. Very happy with Ada.
>
>And all its boilerplate?

There isn't any boilerplate if you don't use tagged types. Though to be fair
 Darts boilerplate dissapears if you use it procedurally without OOP too.
 However Darts OOP has a lot more than Adas e.g. access type to avoid issues
 with size variations and composites etc.. Adas C interfacing has far less
 boilerplate than Darts FFI too. I don't know Python and don't want to.
 Micropython is C and some say Python is C too.

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sat, 23 Aug 2025 23:58:12 -0000 (UTC), Kevin Chadwick wrote:

> Micropython is C and some say Python is C too.

Python is Python, not C. It has strong dynamic typing and lexical binding, 
and functions and classes are first-class objects.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-24 23:49, Lawrence D’Oliveiro wrote:
> On Sat, 23 Aug 2025 23:58:12 -0000 (UTC), Kevin Chadwick wrote:
> 
>> Micropython is C and some say Python is C too.
> 
> Python is Python, not C. It has strong dynamic typing and lexical binding,
> and functions and classes are first-class objects.

Python is a C front-end... (:-))

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Mon, 25 Aug 2025 10:19:43 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-24 23:49, Lawrence D’Oliveiro wrote:
>>
>> On Sat, 23 Aug 2025 23:58:12 -0000 (UTC), Kevin Chadwick wrote:
>> 
>>> Micropython is C and some say Python is C too.
>> 
>> Python is Python, not C. It has strong dynamic typing and lexical
>> binding, and functions and classes are first-class objects.

With Python, you don’t even need to write C code to interface to C code
<https://docs.python.org/3/library/ctypes.html>.

Re: In precision typing we trust

[Kevin Chadwick]

On 25/08/2025 21:58, Lawrence D\x19Oliveiro wrote:
>On Mon, 25 Aug 2025 10:19:43 +0200, Dmitry A. Kazakov wrote:
>
>> On 2025-08-24 23:49, Lawrence D’Oliveiro wrote:
>>>
>>> On Sat, 23 Aug 2025 23:58:12 -0000 (UTC), Kevin Chadwick wrote:
>>> 
>>>> Micropython is C and some say Python is C too.
>>> 
>>> Python is Python, not C. It has strong dynamic typing and lexical
>>> binding, and functions and classes are first-class objects.
>
>With Python, you don’t even need to write C code to interface to C code
><https://docs.python.org/3/library/ctypes.html>.

You don't in Ada either. Maybe to get around some issues with C++

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-27 11:01, Kevin Chadwick wrote:
> On 25/08/2025 21:58, Lawrence D\x19Oliveiro wrote:
>> On Mon, 25 Aug 2025 10:19:43 +0200, Dmitry A. Kazakov wrote:
>>
>>> On 2025-08-24 23:49, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Sat, 23 Aug 2025 23:58:12 -0000 (UTC), Kevin Chadwick wrote:
>>>>
>>>>> Micropython is C and some say Python is C too.
>>>>
>>>> Python is Python, not C. It has strong dynamic typing and lexical
>>>> binding, and functions and classes are first-class objects.
>>
>> With Python, you don’t even need to write C code to interface to C code
>> <https://docs.python.org/3/library/ctypes.html>.
> 
> You don't in Ada either. Maybe to get around some issues with C++

Actually in Python they use a C library to call C. So it illustrates the 
opposite: you cannot call C or be called from C in Python. You need some 
FFI layer. But in Ada you can, because of an ability to specify 
conventions in Ada.

This is an unfair comparison, because Ada is a general purpose language. 
Direct hardware access is a part of Ada's functionality. Python is a 
mere command-line interpreter that cannot deal with machine specifics.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 27 Aug 2025 11:24:18 +0200, Dmitry A. Kazakov wrote:

> Actually in Python they use a C library to call C. So it illustrates
> the opposite: you cannot call C or be called from C in Python. You
> need some FFI layer. But in Ada you can, because of an ability to
> specify conventions in Ada.

But the most common Ada compiler, GNAT, is part of GCC, which is written 
in C and C++, is it not? So Ada cannot actually specify those 
“conventions” without the help of C/C++ code.

> This is an unfair comparison, because Ada is a general purpose
> language. Direct hardware access is a part of Ada's functionality.

It does it in such a clumsy way compared to C, or even Python.

> Python is a mere command-line interpreter that cannot deal with
> machine specifics.

I posted that example of some machine specifics (the mountinfo API). Feel 
free to offer your comparable Ada code, just to see if it’s better or 
(more likely) worse than the Python version.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 01:07, Lawrence D’Oliveiro wrote:
> On Wed, 27 Aug 2025 11:24:18 +0200, Dmitry A. Kazakov wrote:
> 
>> Actually in Python they use a C library to call C. So it illustrates
>> the opposite: you cannot call C or be called from C in Python. You
>> need some FFI layer. But in Ada you can, because of an ability to
>> specify conventions in Ada.
> 
> But the most common Ada compiler, GNAT, is part of GCC, which is written
> in C and C++, is it not?

No. GNAT is written in Ada.

> So Ada cannot actually specify those
> “conventions” without the help of C/C++ code.

Wrong. These are a part of the language standard ARM B. No C code involved.

>> This is an unfair comparison, because Ada is a general purpose
>> language. Direct hardware access is a part of Ada's functionality.
> 
> It does it in such a clumsy way compared to C, or even Python.

Example?

>> Python is a mere command-line interpreter that cannot deal with
>> machine specifics.
> 
> I posted that example of some machine specifics (the mountinfo API).

Machine specifics means machine data types, addresses, interrupts etc. 
As an example consider programming a bare board, writing an OS etc.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 02:00:44 +0200, Dmitry A. Kazakov wrote:

> Machine specifics means machine data types, addresses, interrupts etc.
> As an example consider programming a bare board, writing an OS etc.

Like MicroPython?

Re: In precision typing we trust

[Kevin Chadwick]

>
>> This is an unfair comparison, because Ada is a general purpose
>> language. Direct hardware access is a part of Ada's functionality.
>
>It does it in such a clumsy way compared to C, or even Python.
>

Ada is the best language by far for mapping registers to hardware or data
 packets via representation clauses. I have found many bugs in STs svd files
 and C code because of Adas type system.

-- 
Regards, Kc

Re: In precision typing we trust

[Kevin Chadwick]

\r>>> This is an unfair comparison, because Ada is a general purpose
>>> language. Direct hardware access is a part of Ada's functionality.
>>
>>It does it in such a clumsy way compared to C, or even Python.
>>
>
>Ada is the best language by far for mapping registers to hardware or data
> packets via representation clauses. I have found many bugs in STs svd files
> and C code because of Adas type system.

The reason it's so good aside from Gnats excellent size checks etc. is due
 to precision types :-)

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 00:20:38 -0000 (UTC), Kevin Chadwick wrote:

>> Ada is the best language by far for mapping registers to hardware
>> or data packets via representation clauses. I have found many bugs
>> in STs svd files and C code because of Adas type system.
>
> The reason it's so good aside from Gnats excellent size checks etc.
> is due to precision types :-)

But can you do type checking dynamically, at run-time?

For example, in one project (a Python wrapper for receiving fanotify
events from the Linux kernel), I had to deal with a sequence of
packets of variable length and type. I could dispatch on the
packet-type field and return correspondingly typesafe results in my
wrapper.

Re: In precision typing we trust

[Alex // nytpu]

On 8/27/25 6:33 PM, Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 00:20:38 -0000 (UTC), Kevin Chadwick wrote:
> 
>>> Ada is the best language by far for mapping registers to hardware
>>> or data packets via representation clauses. I have found many bugs
>>> in STs svd files and C code because of Adas type system.
>>
>> The reason it's so good aside from Gnats excellent size checks etc.
>> is due to precision types :-)
> 
> But can you do type checking dynamically, at run-time?
> 
> For example, in one project (a Python wrapper for receiving fanotify
> events from the Linux kernel), I had to deal with a sequence of
> packets of variable length and type. I could dispatch on the
> packet-type field and return correspondingly typesafe results in my
> wrapper.
Yes, that's sorta the entire premise of Ada's OOP lol.  Use the `'Class` 
type to give you a root class and then you can dispatch with a method 
call or you sorta can match directly (nowhere even near the convenience 
of more modern functional-style matching admittedly though).  Or just 
have a variant record that you can match on with a `case` if one 
prefers---I usually do this unless I need dynamic dispatch or inheritance.

To be clear, for nearly all of this thread I've strongly agreed with you 
(mostly seems like Dmitry is just being willfully ignorant about basic 
computer science facts like "what dynamic typing is and how it's 
orthogonal to strong/weak typing").  But in the specific case of 
interacting directly with hardware[1], Ada is far and away the best 
language in existence for it.  And I'm a weird-ass language connoisseur 
and like doing weird-ass things with them, so I have lots of experience 
with everything all over the map.  Ada 2012, with its representation 
clauses and useful set of aspects, is really just the best for working 
with memory-mapped I/O and such.

~nytpu

[1]: as in, directly interacting with it in an embedded context; not 
using an OS abstraction, not binding to an existing C HLL, etc., 
specifically writing the bindings yourself.  If you're dealing with 
existing software abstractions it's much more up in the air and comes 
mostly down to personal preference (I'm partial to Common Lisp when in 
hosted environments myself, but in this case I assume the benefits are 
mostly equivalent to Python other than Lisp's macro stuff)

-- 
Alex // nytpu
https://nytpu.com/ - gemini://nytpu.com/ - gopher://nytpu.com/

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Wed, 27 Aug 2025 19:17:43 -0600, Alex // nytpu wrote:

> On 8/27/25 6:33 PM, Lawrence D’Oliveiro wrote:
>>
>> But can you do type checking dynamically, at run-time?
>>
>> For example, in one project (a Python wrapper for receiving
>> fanotify events from the Linux kernel), I had to deal with a
>> sequence of packets of variable length and type. I could dispatch
>> on the packet-type field and return correspondingly typesafe
>> results in my wrapper.
>
> Yes, that's sorta the entire premise of Ada's OOP lol. Use the
> `'Class` type to give you a root class and then you can dispatch
> with a method call or you sorta can match directly (nowhere even
> near the convenience of more modern functional-style matching
> admittedly though). Or just have a variant record that you can match
> on with a `case` if one prefers---I usually do this unless I need
> dynamic dispatch or inheritance.

But the function has to return the base class type, it cannot have
different return types dynamically. E.g. in the above case, I have an
expression like

    info_type = infoptr.contents.info_type
    infoptr = ct.cast \
      (
        infoptr,
        ct.POINTER
          (
            {
                FANOTIFY.EVENT_INFO_TYPE_FID : FANOTIFY.event_info_fid,
                FANOTIFY.EVENT_INFO_TYPE_DFID_NAME : FANOTIFY.event_info_fid,
                FANOTIFY.EVENT_INFO_TYPE_DFID : FANOTIFY.event_info_fid,
                FANOTIFY.EVENT_INFO_TYPE_PIDFD : FANOTIFY.event_info_pidfd,
                FANOTIFY.EVENT_INFO_TYPE_ERROR : FANOTIFY.event_info_error,
            }[info_type]
          )
      )
    additional.append(infoptr)
    if info_type == FANOTIFY.EVENT_INFO_TYPE_DFID_NAME :
        nameptr = ct.cast \
          (
                ct.cast(infoptr, ct.c_void_p).value
            +
                ct.sizeof(FANOTIFY.event_info_fid)
            +
                infoptr.contents.handle.handle_bytes,
            ct.c_char_p
          )
        additional.append(nameptr.value)
    #end if

Note how you have a switch-expression that uses the value of the
event-type field to return the corresponding type object, and I cast
the info pointer to point to that type. And then the “additional”
variable-length array can contain pointers to additional data,
depending on the event type.

> But in the specific case of interacting directly with hardware[1],
> Ada is far and away the best language in existence for it.

Look at MicroPython, though. It makes it so easy to write just a few
lines of code to twiddle some bits or something. Ada is for the big
stuff, not the small stuff.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 03:45, Lawrence D’Oliveiro wrote:

> But the function has to return the base class type, it cannot have
> different return types dynamically.

Of course you can. That is the meaning of the term "class" and "class 
type" as a type which values are the values of the class members.

In Ada class type is denoted as T'Class. T'Class values are values of T 
or any type derived from T. The operations declared on T'Class are 
called class-wide, so

    function F (...) return T'Class;

> Note how you have a switch-expression that uses the value of the
> event-type field to return the corresponding type object, and I cast
> the info pointer to point to that type. And then the “additional”
> variable-length array can contain pointers to additional data,
> depending on the event type.

That is not much OO as you have all alternatives static. An Ada 
programmer might tend to use a variant record and enumeration for the case.

But for the OO approach:

    function F return Abstract_Packet'Class is
    begin
       case Kind_Of is
          when Foo =>
             return Foo_Packet; -- Derived from Abstract_Packet
          when Bar =>
             return Bar_Packet; -- Derived from Abstract_Packet
       ...

Note also that one can return instances not knowing the specific type at 
all. E.g. you can dispatch on the bare tag or an argument. In the latter 
case the derived type registers itself in a mapping value -> 
constructing function. The client simply calls the function from the 
mapping and gets a class-wide object.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 10:24:54 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-28 03:45, Lawrence D’Oliveiro wrote:
> 
>> But the function has to return the base class type, it cannot have
>> different return types dynamically.
> 
> Of course you can. That is the meaning of the term "class" and "class
> type" as a type which values are the values of the class members.

Assigning the result to a variable of type subclass involves dynamic type 
checking. Which you have been insisting so far is “untyped”.

>> Note how you have a switch-expression that uses the value of the
>> event-type field to return the corresponding type object, and I cast
>> the info pointer to point to that type. And then the “additional”
>> variable-length array can contain pointers to additional data,
>> depending on the event type.
> 
> That is not much OO as you have all alternatives static.

No, they are dynamic, not static. See below.

> But for the OO approach:
> 
>     function F return Abstract_Packet'Class is begin
>        case Kind_Of is
>           when Foo =>
>              return Foo_Packet; -- Derived from Abstract_Packet
>           when Bar =>
>              return Bar_Packet; -- Derived from Abstract_Packet
>        ...
> 
> Note also that one can return instances not knowing the specific type at
> all.

But they are still of that same “Abstract_Packet'Class”, which is the base 
class. You cannot specify “Foo_Packet'Class” as the return type on one 
call, “Bar_Packet'Class” on another call, etc.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-29 05:53, Lawrence D’Oliveiro wrote:

> But they are still of that same “Abstract_Packet'Class”, which is the base
> class.

Yes, because it was designed so. This is what being typed is.

> You cannot specify “Foo_Packet'Class” as the return type on one
> call, “Bar_Packet'Class” on another call, etc.

Why should I? The return type is equivalent (not is!) to Foo_Packet in 
one call and Bar_Packet in another.

A value of Abstract_Packet'Class can be viewed as a value of Foo_Packet, 
if the type tag specifies Foo_Packet as the specific type. You can check 
the tag dynamically or use it indirectly in dispatching calls = calls to 
methods (in Ada terminology "primitive operations").

The caller expects a value of a class member = a value of a descendant 
of Abstract_Packet.

This paradigm in literature is called "generic programming" when a 
program is written in terms of a class (class Abstract_Packet) = a set 
of types derived from Abstract_Packet = {Foo_Packet, Bar_Packet, ...}. 
The program does not know the specific type and need not to know.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 10:07:45 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-29 05:53, Lawrence D’Oliveiro wrote:
>
>> But they are still of that same “Abstract_Packet'Class”, which is
>> the base class.
>
> Yes, because it was designed so. This is what being typed is.

That is what “being statically typed” is.

>> You cannot specify “Foo_Packet'Class” as the return type on one
>> call, “Bar_Packet'Class” on another call, etc.
>
> Why should I?

Because that’s what dynamic typing means.

Remember, if a language is not typed (e.g. BLISS, BCPL), then you
don’t specify any types at all.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-31 00:27, Lawrence D’Oliveiro wrote:
> On Fri, 29 Aug 2025 10:07:45 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-29 05:53, Lawrence D’Oliveiro wrote:
>>
>>> But they are still of that same “Abstract_Packet'Class”, which is
>>> the base class.
>>
>> Yes, because it was designed so. This is what being typed is.
> 
> That is what “being statically typed” is.

No, being able to specify a set of types is neither static nor dynamic. 
Nothing in dynamic typing prevents you from doing that and checking at 
run-time if the constraint satisfied.

But when the behavior is defined as WHATEVER as in Python that is 
untyped. It is equivalent to having a single proper type with some tag 
called "dynamic type." All dynamically typed languages are statically 
typed in that sense, which is why they are uninteresting from the type 
system point of view.

>>> You cannot specify “Foo_Packet'Class” as the return type on one
>>> call, “Bar_Packet'Class” on another call, etc.
>>
>> Why should I?
> 
> Because that’s what dynamic typing means.

Dynamic typing means that the type of an object is not statically 
determinable and that it can change. In a statically typed language the 
type is determinable and cannot be changed. Any dynamically typed 
language can be reduced to an equivalent statically typed one.

> Remember, if a language is not typed (e.g. BLISS, BCPL), then you
> don’t specify any types at all.

Just like in Python where types of arguments and results are not specified.

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

Re: In precision typing we trust

[Kevin Chadwick]

>
>Look at MicroPython, though. It makes it so easy to write just a few
>lines of code to twiddle some bits or something. Ada is for the big
>stuff, not the small stuff.

Perhaps you are trolling but you can literally twiddle any number of bits in
 Ada by assignment. I often change svd files by adding enumerations to have
 type protected register access generated by svd2ada that C does not protect
 the engineer from.

I2C1.Address := 7_Bit_Address;
I2C1.Protocol := Motorola;

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 09:17:10 -0000 (UTC), Kevin Chadwick wrote:

> Perhaps you are trolling but you can literally twiddle any number of
> bits in Ada by assignment.

So can you in Python. You can also access I/O registers (i.e. not
memory-mapped I/O) via assignment. Can Ada manage that?

Who’s trolling now?
Who’s trolling now?
Who’s telling porkies, so dorky, and how?

(To the tune of “Who’s Sorry Now?”)

Re: In precision typing we trust

[Kevin Chadwick]

>So can you in Python. You can also access I/O registers (i.e. not
>memory-mapped I/O) via assignment. Can Ada manage that?
>

Yes if I understand you correctly but I don't believe you understand what
 I'm talking about as I believe Python

-- 
Regards, Kc

Re: In precision typing we trust

[Kevin Chadwick]

On 29/08/2025 10:27, Kevin Chadwick wrote:
>
>>So can you in Python. You can also access I/O registers (i.e. not
>>memory-mapped I/O) via assignment. Can Ada manage that?
>>
>

Yes if I understand you correctly but I don't believe you understand what
 I'm talking about as I believe Python does not have the ability for easily
 creating e.g. Unsigned_2, Unsigned_4 or Unsigned_15 and writing just those
 bits by assignment to wherever the programmer wants.


-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 09:33:27 -0000 (UTC), Kevin Chadwick wrote:

> ... I don't believe you understand what I'm talking about as I
> believe Python does not have the ability for easily creating e.g.
> Unsigned_2, Unsigned_4 or Unsigned_15 and writing just those bits by
> assignment to wherever the programmer wants.

Something like the following? (Details of the BitVector class
omitted, but I can supply them if you’re interested):

+*In[2]:*+
[source, ipython3]
----
# constructor: v = BitVector(«width»[, «init»])
# «init» defaults to all zeroes if omitted
v1 = BitVector(3, 2)
v2 = BitVector(5)
v1, v2, int(v1), int(v2)
----

+*Out[2]:*+
----(BitVector(3, [False, True, False]),
 BitVector(5, [False, False, False, False, False]),
 2,
 0)----

+*In[3]:*+
[source, ipython3]
----
# access can be single bits, or use standard Python slice notation
v1[0:2], v1[2], v1[1:3], v2[2:5]
----

+*Out[3]:*+
----(BitVector(2, [False, True]),
 False,
 BitVector(2, [True, False]),
 BitVector(3, [False, False, False]))----

+*In[4]:*+
[source, ipython3]
----
v1[1:3] = [False, True]
v2[:] = 13
----

+*In[5]:*+
[source, ipython3]
----
v1, v2, int(v1), int(v2)
----

+*Out[5]:*+
----(BitVector(3, [False, False, True]),
 BitVector(5, [True, False, True, True, False]),
 4,
 13)----

+*In[6]:*+
[source, ipython3]
----
# “+” does concatenation of BitVectors; note little-endian ordering.
v1 + v2, int(v1 + v2)
----

+*Out[6]:*+
----(BitVector(8, [False, False, True, True, False, True, True, False]), 108)----

+*In[7]:*+
[source, ipython3]
----
# shifts produce results with same number of bits
v2, v2 >> 3, v2 << 3, v2[:3] << 3, (v2 + BitVector(3)) << 3
----

+*Out[7]:*+
----(BitVector(5, [True, False, True, True, False]),
 BitVector(5, [True, False, False, False, False]),
 BitVector(5, [False, False, False, True, False]),
 BitVector(3, [False, False, False]),
 BitVector(8, [False, False, False, True, False, True, True, False]))----

+*In[8]:*+
[source, ipython3]
----
v1[1:3]
----

+*Out[8]:*+
----BitVector(2, [False, True])----

Following all raise errors

+*In[9]:*+
[source, ipython3]
----
v2[:1] = v1
----

+*Out[9]:*+
----
    ---------------------------------------------------------------------------

    ValueError                                Traceback (most recent call last)

    Cell In[9], line 1
    ----> 1 v2[:1] = v1

    [traceback details omitted]

    ValueError: value has 3 bits, only allowed 1 for this usage
----

+*In[10]:*+
[source, ipython3]
----
v1[:] = 8
----

+*Out[10]:*+
----
    ---------------------------------------------------------------------------

    ValueError                                Traceback (most recent call last)

    Cell In[10], line 1
    ----> 1 v1[:] = 8

    [traceback details omitted]

    ValueError: value has 4 bits, only allowed 3 for this usage
----

+*In[11]:*+
[source, ipython3]
----
v2[0] = 2
----

+*Out[11]:*+
----
    ---------------------------------------------------------------------------

    ValueError                                Traceback (most recent call last)

    Cell In[11], line 1
    ----> 1 v2[0] = 2

    [traceback details omitted]

    ValueError: value has 2 bits, only allowed 1 for this usage
----

+*In[12]:*+
[source, ipython3]
----
v1[:] = v2[:]
----

+*Out[12]:*+
----
    ---------------------------------------------------------------------------
    ValueError                                Traceback (most recent call last)

    Cell In[12], line 1
    ----> 1 v1[:] = v2[:]

    [traceback details omitted]

    ValueError: value has 5 bits, only allowed 3 for this usage
----

Re: In precision typing we trust

[Kevin Chadwick]

>
>Something like the following? (Details of the BitVector class
>omitted, but I can supply them if you’re interested):
>

I'm surprised Python can do some of what you have shown but it's a long way
 from what would be required.


-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Sun, 31 Aug 2025 00:43:18 -0000 (UTC), Kevin Chadwick wrote:

>> Something like the following? (Details of the BitVector class
>> omitted, but I can supply them if you’re interested):
>>
> I'm surprised Python can do some of what you have shown but it's a long way
> from what would be required.

What’s missing?

Re: In precision typing we trust

[Kevin Chadwick]

On 31/08/2025 08:30, Lawrence D\x19Oliveiro wrote:
>On Sun, 31 Aug 2025 00:43:18 -0000 (UTC), Kevin Chadwick wrote:
>
>>> Something like the following? (Details of the BitVector class
>>> omitted, but I can supply them if you’re interested):
>>>
>> I'm surprised Python can do some of what you have shown but it's a long way
>> from what would be required.
>
>What’s missing?

Complete size controls and things like vomatile_full_access and proper type
 protections (though Python/C users might be quite happy with the ability to
 slice between completely different registers that could be dangerous and
 breaks separation of concerns).

https://learn.adacore.com/courses/intro-to-embedded-sys-prog/chapters/low_level_programming.html#separation-principle


-- 
Regards, Kc

Re: In precision typing we trust

[Kevin Chadwick]

On 28/08/2025 01:33, Lawrence D\x19Oliveiro wrote:
>On Thu, 28 Aug 2025 00:20:38 -0000 (UTC), Kevin Chadwick wrote:
>
>>> Ada is the best language by far for mapping registers to hardware
>>> or data packets via representation clauses. I have found many bugs
>>> in STs svd files and C code because of Adas type system.
>>
>> The reason it's so good aside from Gnats excellent size checks etc.
>> is due to precision types :-)
>
>But can you do type checking dynamically, at run-time?
>
>For example, in one project (a Python wrapper for receiving fanotify
>events from the Linux kernel), I had to deal with a sequence of
>packets of variable length and type. I could dispatch on the
>packet-type field and return correspondingly typesafe results in my
>wrapper.

To any degree that is sensible and secure yes as you should always validate
 the packet even from behind a cryptographic protection. Cobs crate helps.

https://alire.ada.dev/crates/cobs

Or you can use Streams on anything above a light runtime.

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 09:04:06 -0000 (UTC), Kevin Chadwick wrote:

> On 28/08/2025 01:33, Lawrence D’Oliveiro wrote:
>>
>> But can you do type checking dynamically, at run-time?
>
> To any degree that is sensible and secure yes as you should always
> validate the packet even from behind a cryptographic protection.
> Cobs crate helps.
>
> https://alire.ada.dev/crates/cobs
>
> Or you can use Streams on anything above a light runtime.

That’s not a “yes” though, is it.

Re: In precision typing we trust

[Kevin Chadwick]

On 29/08/2025 04:55, Lawrence D\x19Oliveiro wrote:
>On Thu, 28 Aug 2025 09:04:06 -0000 (UTC), Kevin Chadwick wrote:
>
>> On 28/08/2025 01:33, Lawrence D’Oliveiro wrote:
>>>
>>> But can you do type checking dynamically, at run-time?
>>
>> To any degree that is sensible and secure yes as you should always
>> validate the packet even from behind a cryptographic protection.
>> Cobs crate helps.
>>
>> https://alire.ada.dev/crates/cobs
>>
>> Or you can use Streams on anything above a light runtime.
>
>That’s not a “yes” though, is it.

Ada was designed to be cost effective as a common language for large and
 realtime systems.

Full dynamic typing is not cost effective except maybe like C for
 prototyping.

"https://www.wirekat.com/python-a-loved-but-eternally-flawed-language/"

-- 
Regards, Kc

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 09:41:52 -0000 (UTC), Kevin Chadwick wrote:

> Ada was designed to be cost effective as a common language for large and
> realtime systems.
> 
> Full dynamic typing is not cost effective except maybe like C for
> prototyping.

Remember Alan Kay’s dictum: “Simple things should be simple, and complex 
things should be possible”.

Ada may be helpful with keeping complex things manageable, but Python 
helps keep simple things simple.

Re: In precision typing we trust

[Kevin Chadwick]

>
>But can you do type checking dynamically, at run-time?
>

'Valid

-- 
Regards, Kc

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-28 11:05, Kevin Chadwick wrote:

>> But can you do type checking dynamically, at run-time?
>>
> 
> 'Valid

Except that this is not checking of the type, which is not possible on 
fundamental grounds.

It is checking a value of an object for constraints. That a value might 
violate the constraints is itself a result of type violation when the 
value was coerced to the type by an operation not defined on the type, 
e.g. per Unchecked_Conversion or memory mapping.

But the point you make is correct it is same as Python's "type 
checking," namely lets take something apparently untyped and see if that 
thing could pass for the given type.

In Python everything is untyped even when type annotations are used.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 11:43:15 +0200, Dmitry A. Kazakov wrote:

> In Python everything is untyped even when type annotations are used.

    Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 2 + "2"
    Traceback (most recent call last):
      File "<python-input-0>", line 1, in <module>
        2 + "2"
        ~~^~~~~
    TypeError: unsupported operand type(s) for +: 'int' and 'str'

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-29 05:54, Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 11:43:15 +0200, Dmitry A. Kazakov wrote:
> 
>> In Python everything is untyped even when type annotations are used.
> 
>      Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
>      Type "help", "copyright", "credits" or "license" for more information.
>      >>> 2 + "2"
>      Traceback (most recent call last):
>        File "<python-input-0>", line 1, in <module>
>          2 + "2"
>          ~~^~~~~
>      TypeError: unsupported operand type(s) for +: 'int' and 'str'

"+" is implemented to raise an exception named TypeError. So? How is 
that a type check?

How do I know if that happens without executing "+"?

It is just untyped as no types of "+" are specified anywhere.

It is an undefined behavior, because nobody knows a-priory if "+" would 
return and which type or bomb the program.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Fri, 29 Aug 2025 10:15:56 +0200, Dmitry A. Kazakov wrote:

> On 2025-08-29 05:54, Lawrence D’Oliveiro wrote:
>>
>> On Thu, 28 Aug 2025 11:43:15 +0200, Dmitry A. Kazakov wrote:
>> 
>>> In Python everything is untyped even when type annotations are used.
>> 
>>      Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
>>      Type "help", "copyright", "credits" or "license" for more information.
>>      >>> 2 + "2"
>>      Traceback (most recent call last):
>>        File "<python-input-0>", line 1, in <module>
>>          2 + "2"
>>          ~~^~~~~
>>      TypeError: unsupported operand type(s) for +: 'int' and 'str'
> 
> "+" is implemented to raise an exception named TypeError. So? How is 
> that a type check?

You mean it doesn’t do type checking in Ada??

> How do I know if that happens without executing "+"?

Look at the definitions of the classes involved.

> It is just untyped as no types of "+" are specified anywhere.

They are in the classes that implement that operator.

> It is an undefined behavior ...

It is defined in the classes that implement that operator.

Re: In precision typing we trust

[Dmitry A. Kazakov]

On 2025-08-31 00:25, Lawrence D’Oliveiro wrote:
> On Fri, 29 Aug 2025 10:15:56 +0200, Dmitry A. Kazakov wrote:
> 
>> On 2025-08-29 05:54, Lawrence D’Oliveiro wrote:
>>>
>>> On Thu, 28 Aug 2025 11:43:15 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> In Python everything is untyped even when type annotations are used.
>>>
>>>       Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
>>>       Type "help", "copyright", "credits" or "license" for more information.
>>>       >>> 2 + "2"
>>>       Traceback (most recent call last):
>>>         File "<python-input-0>", line 1, in <module>
>>>           2 + "2"
>>>           ~~^~~~~
>>>       TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>
>> "+" is implemented to raise an exception named TypeError. So? How is
>> that a type check?
> 
> You mean it doesn’t do type checking in Ada??

I mean that no type check is made in Python. Naming exception TypeError 
does not mean type error.

>> How do I know if that happens without executing "+"?
> 
> Look at the definitions of the classes involved.

What "look" does formally mean and why Python didn't do it?

>> It is just untyped as no types of "+" are specified anywhere.
> 
> They are in the classes that implement that operator.

Can you list them? No? Then see above "no types of "+" are specified 
anywhere."

>> It is an undefined behavior ...
> 
> It is defined in the classes that implement that operator.

q.e.d.

It is undefined in the classes that do not implement that operator => On 
all classes it is undefined.

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

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Thu, 28 Aug 2025 00:11:37 -0000 (UTC), Kevin Chadwick wrote:

>>> This is an unfair comparison, because Ada is a general purpose
>>> language. Direct hardware access is a part of Ada's functionality.
>>
>> It does it in such a clumsy way compared to C, or even Python.
>>
> Ada is the best language by far for mapping registers to hardware or
> data packets via representation clauses.

Python has standard library modules to aid with that.

For data packets, I wrote a script for a client once which processed video 
files recorded on GoPro cameras and extracted the instrumentation streams 
containing GPS and accelerometer data.

I used the ffprobe command (part of the FFmpeg suite) to locate the 
positions and PTS values for the packets, then decoded them with the 
struct <https://docs.python.org/3/library/struct.html> module.

Details on the format (a bit incomplete and out of date, last I checked): 
<https://github.com/gopro/gpmf-parser>.

Re: In precision typing we trust

[Niocláisín Cóilín de Ghlostéir]

On Wed, 20 Aug 2025, Niklas Holsti wrote:
|--------------------------------------------------------------------------|
|"Some people called Ada 83 an "object-based" language, perhaps because Ada|
|programs typically modelled the real application objects (as abstract data|
|types) even before tagged types were available."                          |
|--------------------------------------------------------------------------|

Dear Dr. Holsti,

Thanks for this contribution.

The person who coined "object-based" professes that OOP necessarily 
involves inheritance, whereas "object-based" programming does not. 
However, he did not coin "OOP".

Even \cite{Objective-C} professes that inheritence is not necessary for 
OOP. (But then again, it is not by Alan Curtis Kay, and it professes that 
Objective C be an OOP language, so do not rely on it for what an "OOP" 
language is!)

"OOP to me means only messaging, local retention and protection and

hiding of state-process, and extreme late-binding of all things."
says
HTTPS://userPage.FU-Berlin.De/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_de
It might be possible to interpret this quotation to not necessitate 
inheritance, even with the part about "extreme late-binding of all 
things."


@book{Objective-C,
  author = {Cox, Brad J.},
  title = {Object oriented programming: an evolutionary approach},
  year = {1987},
  note = {``Reprinted with corrections April, 1987
Copyright {\copyright} 1986 by Productivity Products International, 
Inc.''},
  publisher = {Addison-Wesley}
  }

Re: In precision typing we trust

[Lawrence D’Oliveiro]

On Mon, 18 Aug 2025 13:08:32 +0200, Dmitry A. Kazakov wrote:

> What Richard refers to is an accuracy of mapping a type to the problem
> space. Talking about numerical entities the model types have precision,
> range, accuracy (float vs. fixed-point vs. unbounded), behavior like
> rounding, handling of exceptional states (breaking out the model) etc.

Subclassing?

Re: In precision typing we trust

[Kevin Chadwick]

On 19/08/2025 00:27, Lawrence D\x19Oliveiro wrote:
>On Mon, 18 Aug 2025 13:08:32 +0200, Dmitry A. Kazakov wrote:
>
>> What Richard refers to is an accuracy of mapping a type to the problem
>> space. Talking about numerical entities the model types have precision,
>> range, accuracy (float vs. fixed-point vs. unbounded), behavior like
>> rounding, handling of exceptional states (breaking out the model) etc.
>
>Subclassing?

For example engineering parameters so only valid inputs are possible using
 e.g. ranges. That could be a subtype or new type etc..

-- 
Regards, Kc