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?
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.
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.
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?
Ada is a strongly typed language so Ada is not an OOP language.
Ada is a strongly typed OO language.
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.
OOP implies a weakening of the typing system, since a wider class can
contain any object of the subclass.
Constrained subtypes are even "weaker" in that respect, e.g. Positive
vs. Integer.
OOP implies a weakening of the typing system, since a wider class can| contain any object of the subclass. || |
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.
Constrained subtypes are even "weaker" in that respect, e.g. Positive
vs. Integer.
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.
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.
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.
So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says:
Cf. a Smalltalk superclass can receive a subclass message for which no superclass counterpart exists, so causing a crash. OOP is poop!
So Ada is not an OOP language. Cf. Professor Alan Curtis Kay says: || |
superclass counterpart exists, so causing a crash. OOP is poop! || |
Please stop misusing a term which Prof. Kay coined.
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."!
Another thing which he did not do is wanting persons to call circles "squares".
Some people called Ada 83 an "object-based" language, perhaps becauseThis guy researched the origins of OOP with a focus on C++ apparently
Ada programs typically modelled the real application objects (as
abstract data types) even before tagged types were available.
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.
Personally I have only used any OOP features in Dart and Ada. In Dart I
hate the seemingly excessive boiler plate.
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 |
Try Python.
"... while Python will simply throw an error without providing any suggestions on how to fix it."
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
Try Python. Both functions and classes are first-class objects, so
there is little or no “boilerplate”.
No thank you. Very happy with Ada.
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?
"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?
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.
Micropython is C and some say Python is C too.
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 Burmese python (Python bivittatus) is found on the island of Java in Indonesia...
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.
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.
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?
"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/
Why do I need to instantiate a class? Provided that it is obviously impossible since the class is an open set of types.
"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
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.
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.
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 ...
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?
The question remains why should I need to instantiate it beyond
declaring an object of?
Call the thing (a set of types closed under derivation) the way you want.
It's not really useful to think of Python types as sets. Python isn't
that mathematical.
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.
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.
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.
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'
"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.
"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?
Wouldn't that make Python slow and unreliable?
The error occurred inside the body of F. F itself was successfully
called, because it is untyped. Just as I said.
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?
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.
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:
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.
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
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.
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.
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).
No, it was successfully entered,
not successfully left.
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>.
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.
On 25/08/2025 21:58, Lawrence DOliveiro 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++
The discussion was whether this would require weakening the type
system strength. Python here is really of zero interest.
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.
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.
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.
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.
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!
Hint: You cannot define the type semantics of a function in an untyped language. That is just what untyped means.
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'
So I can do something like
function F ... is
declare
type T is ...
begin
...
return T;
end;
in Ada?
It is a proprietary code. You can write it yourself.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.
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).
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,
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.
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.
Machine specifics means machine data types, addresses, interrupts etc.
As an example consider programming a bare board, writing an OS etc.
Ada is the best language by far for mapping registers to hardware orThis 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.
data packets via representation clauses.
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 :-)
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:
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.
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.
See
https://docs.python.org/3/c-api/exceptions.html
for how Python works.
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.
On Thu, 28 Aug 2025 00:20:38 -0000 (UTC), Kevin Chadwick wrote:Yes, that's sorta the entire premise of Ada's OOP lol. Use the `'Class`
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.
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 in the specific case of interacting directly with hardware[1],
Ada is far and away the best language in existence for it.
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.
So you can’t actually show us any example of such a feature, to prove it exists? Too bad ...
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.
But the function has to return the base class type, it cannot have
different return types dynamically.
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.
"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?
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?
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?
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.
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.
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.
But can you do type checking dynamically, at run-time?
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.
But can you do type checking dynamically, at run-time?
'Valid
Python is reasonably reliable in theThen let me tell you about a disaster.
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.
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.
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.
Perhaps you are trolling but you can literally twiddle any number of
bits in Ada by assignment.
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.
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.
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.
In Python everything is untyped even when type annotations are used.
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.
Hint: Type errors and errors in general cannot be checked at run-time.
Errors are bugs.
But the bug might be at the other end of a comms connection in
somebody else’s code, not at my end.
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.
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'
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?
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?
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.
Shouldn’t your test harness have had something likeNope. The Python interpreter should, at a minimum, have done that as
assert isinstance(result_of_test, bool), \
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.
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.
... 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.
Ada may be helpful with keeping complex things manageable. But Python
helps keep simple things simple, in a way that Ada cannot.
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 ...
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?
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.
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.
Something like the following? (Details of the BitVector class
omitted, but I can supply them if you’re interested):
Something like the following? (Details of the BitVector classI'm surprised Python can do some of what you have shown but it's a long way from what would be required.
omitted, but I can supply them if you’re interested):
On Sun, 31 Aug 2025 00:43:18 -0000 (UTC), Kevin Chadwick wrote:
Something like the following? (Details of the BitVector classI'm surprised Python can do some of what you have shown but it's a long way >> from what would be required.
omitted, but I can supply them if you’re interested):
What’s missing?
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,066 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 186:03:23 |
| Calls: | 13,709 |
| Calls today: | 1 |
| Files: | 186,950 |
| D/L today: |
2,977 files (857M bytes) |
| Messages: | 2,416,200 |
