On Monday, August 30, 2021 at 4:47:58 AM UTC-5, James Harris wrote:
> On 29/08/2021 20:32, Dmitry A. Kazakov wrote:
> > On 2021-08-29 20:24, James Harris wrote:
> >
> >> Ignoring the length part (as some objects would have their own length
> >> and some would not but that difference is immaterial here) how would a
> >> 'tag' system be laid out in memory and how would one use that to
> >> locate a method?
> >
> > You must consider the following inheritance variants:
> ...
>
> Thanks for the information, Dmitry. I might come back to you about some
> of that. But for this thread I was wondering how the memory might be
> laid out under the tag model that you mentioned. What form does a tag
> take and how does the runtime get from the tag to a method?
>
> If it depends on which model is in use then what about single
> inheritance and the Full MI model you mentioned?

For TMI on tags and tagging, see Representing Type Information in
Dynamically Typed Languages by David Gudeman.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.4394&rep=rep1&type=pdf

On 09/09/2021 22:04, Bart wrote:
> On 09/09/2021 19:32, James Harris wrote:
>> On 09/09/2021 19:10, Bart wrote:
>>> On 09/09/2021 18:25, James Harris wrote:
>>>> On 04/09/2021 22:35, Bart wrote:
>>>>> On 04/09/2021 21:44, James Harris wrote:

....

>>>>>>    type A
>>>>>>      |
>>>>>>    type B

....

>>>> An object of type B has all of A's fields and some of its own.

....

>> So the offsets
>> would not change, and a type B could appear to be a type A.
>
> Where is that written?

Try the following set of slides. They are part of a compilers course and
show how such objects could be implemented, including how they could be
laid out in memory.

http://openclassroom.stanford.edu/MainFolder/courses/Compilers/docs/slides/12-06-object-layout-annotated.pdf

Keeping the fields is a natural consequence of the "is a" relationship
when using static typing. An object of type B _is_ also an object of
type A so it has to be usable wherever an object of type A is usable
and/or has been declared. That's the case even if type B provides new
methods to manipulate A's fields or adds some fields of its own.

To stress, this is about /static/ typing. If using dynamic typing then
the field types /could/ be overridden, and IIUC that's how the
dynamically typed Python works.

There are various permutations but you should find the above slides to
be really helpful in detailing the fundamentals. The full lectures are
probably findable on line, too.

....

> Exactly how different can variant types be? Maybe X is an int, and maybe
> X is an array of structs. Or an array of Variants. What are the
> limitations?

I don't see the need for any limitation on what types could be used but
the permissible types would have to be specified. For example,

typedef T = variant (int # array float # boolean)

(where # separates alternatives and "array float" means an array of
floats).

>
> Staying with my X[i] where X's type is array of Variant elements, they
> could be ints, floats or strings. And maybe i is a 32-int, or 64-bit
> int, or a float.
>
> You need to analyse it each time is is accessed to see if conversion is
> needed.
>
> Also, Variants could presumably be assigned something else of a
> different type? Then you can't even assume it will stay the same type.

Wouldn't code which handles variants typically include a switch on the
type as in the following?

switch T.type
case int:
/* Handle int */
case array float:
/* Handle array of float */
end switch /* Ignoring other cases */

>
>
>>>
>>> Or maybe write some C++ code and see what the compiler generates.
>>
>> Why would I want to do that?!
>
> To see what limitations it places on the possibilities. Or maybe there
> are no limitations and the resulting code is horrendous.

The problem with looking at how another language handles matters is that
it can limit the scope for creativity and tend to lead to the same ideas.

Wouldn't it be better to come up with designs based on how objects and
structures might be laid out and used?

>
> I don't quite understand why you seem to think that dealing with variant
> types is straightforward.

I don't think I ever said it was straightforward.

In fact, IMO the opposite is the case. There's a big language-design
challenge, here. Designers have come up with many ways to match objects
with code:

coercion
overloading
variants
polymorphism
generics
metatypes
macros

It may be better to get rid of some of them and absorb what they can do
into a common approach - as long as it makes programming easier rather
than harder.

>
>
>>>> Frankly, I'd like the programmer to be able to work purely in terms
>>>> of the logic of his algorithm and for the compiler to pick the
>>>> implementation.
>>>
>>> You might be on the verge of switching to a dynamically typed language!
>>>
>>
>> Not me!
>
> If you have a fully flexible Variant type with no limitations, then you
> will de facto have a language that supports dynamic typing.

Indeed! Variants effectively allow a programmer to use dynamically typed
objects in a statically typed language. But variants have the advantage
of letting a programmer restrict which types can be used.

BTW, if anyone is wondering why I haven't yet replied to some other
message in this group I should say it's probably your own fault! You
shouldn't raise so many big issues!

--
James Harris

On 2021-09-22 16:24, James Harris wrote:

> Try the following set of slides. They are part of a compilers course and
> show how such objects could be implemented, including how they could be
> laid out in memory.
>
> http://openclassroom.stanford.edu/MainFolder/courses/Compilers/docs/slides/12-06-object-layout-annotated.pdf

A quite poor introduction that does not even cover multiple inheritance.

> Keeping the fields is a natural consequence of the "is a" relationship
> when using static typing. An object of type B _is_ also an object of
> type A so it has to be usable wherever an object of type A is usable
> and/or has been declared.

Not quite. Is-a = substitutable, is a member of same class. B is not A,
it can fake A.

The means of substitutution may differ. If B contains a representation
of A, then substitution could be a mere reference shift. This why
languages tend to limit inheritance to extension only and pass tagged
objects by reference.

Otherwise, to achieve substitution you would need to create a new object
A from B. In C and C++ implicit conversions are that sort of is-a
relationship, e.g. float is-a double.

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

On 22/09/2021 15:24, James Harris wrote:
> On 09/09/2021 22:04, Bart wrote:

>> Also, Variants could presumably be assigned something else of a
>> different type? Then you can't even assume it will stay the same type.
>
> Wouldn't code which handles variants typically include a switch on the
> type as in the following?
>
>   switch T.type
>     case int:
>       /* Handle int */
>     case array float:
>       /* Handle array of float */
>   end switch /* Ignoring other cases */

You need to show an example of source code where such types are used,
and see that the generated code might be like.

But let's take your example:

type U = int |[]float

U a, b, c

a := b + c

Here, it knows that b and c are both of type U, but doesn't know - at
compile-time - whether they are ints or arrays.

So just to do b+c, it will need 2-way dispatch:

int temp
if b.type=c.type=int then # Hey, a chained compare example!
temp = b.ivalue+c.ivalue
else
.... # error? Unless "+" is defined for float arrays, array+iny
end

Now to assign result to a:

if a.type=float_array then
// destroy resources, or decr reference count for array
end

a.type = int
a.ivalue = temp

And that's just for one valid combination, and one type of temp, so that
'a' is only ever going to be assigned an int. How about:

type U = int32 | int64 | float32 | float64

U a, b, c, d, e

a = b*c + d*e

All 16 combinations of types should be valid, but do you want to try
writing the switch statements for them?

I don't think this amount of boilerplate is practical to write as inline
code.

You should however try doing so for example fragments of code to see as
I suggested to see what is involved.

This type of variant means that:

a := a[i]

could be legal. Anything goes.

On 2021-09-22 21:47, Bart wrote:
> On 22/09/2021 15:24, James Harris wrote:
>> On 09/09/2021 22:04, Bart wrote:
>
>>> Also, Variants could presumably be assigned something else of a
>>> different type? Then you can't even assume it will stay the same type.
>>
>> Wouldn't code which handles variants typically include a switch on the
>> type as in the following?
>>
>>    switch T.type
>>      case int:
>>        /* Handle int */
>>      case array float:
>>        /* Handle array of float */
>>    end switch /* Ignoring other cases */
>
> You need to show an example of source code where such types are used,

Come on, is that a joke?

https://docs.microsoft.com/en-us/windows/win32/api/oaidl/ns-oaidl-variant

http://documentation.unified-automation.com/uasdkcpp/1.5.2/html/structOpcUa__Variant.html

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

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/variants/

Next you will ask for examples of loops?

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

On 22/09/2021 22:43, Dmitry A. Kazakov wrote:
> On 2021-09-22 21:47, Bart wrote:
>> On 22/09/2021 15:24, James Harris wrote:
>>> On 09/09/2021 22:04, Bart wrote:
>>
>>>> Also, Variants could presumably be assigned something else of a
>>>> different type? Then you can't even assume it will stay the same type.
>>>
>>> Wouldn't code which handles variants typically include a switch on
>>> the type as in the following?
>>>
>>>    switch T.type
>>>      case int:
>>>        /* Handle int */
>>>      case array float:
>>>        /* Handle array of float */
>>>    end switch /* Ignoring other cases */
>>
>> You need to show an example of source code where such types are used,
>
> Come on, is that a joke?
>
> https://docs.microsoft.com/en-us/windows/win32/api/oaidl/ns-oaidl-variant
>
> http://documentation.unified-automation.com/uasdkcpp/1.5.2/html/structOpcUa__Variant.html
>
>
> https://en.wikipedia.org/wiki/Tagged_union
>
> https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/variants/
>
> Next you will ask for examples of loops?
>

So where are the actual examples of using those variants? What are the
capabilities? How are those capabilities implemented: what code is
generated, how much is generated, and how efficient is it?

'Variants' seem to be mean lots of different things.

I've used them for 35 years within dynamic scripting languages, so I
know the answers for my own code. But I assume the context here is for a
static language or perhaps one with type inference.

That Switch example is meaningless without knowing what operation is
being performed in the source code, hence the request for the
corresponding fragment of source code.

Or perhaps you can tell just from the example?

I'm played with variants in my static language, but they have now been
dropped; they were too difficult to deal with in the general case (eg.
arbitrary lists of elements that can be variants and also arbitrary
lists....).

But this fragment of code from an old version, where 'variant' can be
any /object/ type (ie. one implemented as a reference to a
reference-counted descriptor):

variant a, b, c
a := b + c

generated this x64 code (not ABI-compliant):

lea D0, [Dframe+-8]
push D0
call [L5] # init a
lea D0, [Dframe+-16]
push D0
call [L5] # init b
lea D0, [Dframe+-24]
push D0
call [L5] # init c

mov D0, [Dframe+-16] # 'push b'
inc word32 [D0] # step ref count
mov D1, [Dframe+-24] # 'push c'
inc word32 [D1] # step ref count
push D0
push D1
call [L6] # addvar(b, c)
lea D1, [Dframe+-8] # &a
push D0
push D1
call [L7] # 'pop 'a'

So it's all done with function calls; little inline code. And it's
inefficient.

But that's how /I/ did it. This might not be what James has in mind.

On 22/09/2021 21:47, Bart wrote:
> On 22/09/2021 15:24, James Harris wrote:
>> On 09/09/2021 22:04, Bart wrote:
>
>>> Also, Variants could presumably be assigned something else of a
>>> different type? Then you can't even assume it will stay the same type.
>>
>> Wouldn't code which handles variants typically include a switch on the
>> type as in the following?
>>
>>    switch T.type
>>      case int:
>>        /* Handle int */
>>      case array float:
>>        /* Handle array of float */
>>    end switch /* Ignoring other cases */
>
> You need to show an example of source code where such types are used,
> and see that the generated code might be like.
>

Variant types are typically implemented by having a "type" field - an
integer that says which of the allowed types is currently valid. In
C++, this is std::variant. In Pascal, it is a "tagged union" or
"variant record".

In C, you might have :

typedef struct {
enum { T_is_int, T_is_float } type_index;
union {
int int_value;
float float_value;
}
} T;
switch (t.type_index) {
case T_is_int :
// Use t.int_value
break;
case T_is_float :
// Use t.float_value
break;
}

You can produce similar code in any language. Variant types are not
magic, but of course there is plenty of scope for making them neater and
safer than in C! (It doesn't have to be part of the language - with a
powerful enough language, they can be part of the library.)

And compilers can optimise their knowledge of the type stored to reduce
storing or checking "type_index" as much as possible.

> But let's take your example:
>
>    type U = int |[]float
>
>    U a, b, c
>
>    a := b + c
>
> Here, it knows that b and c are both of type U, but doesn't know - at
> compile-time - whether they are ints or arrays.
>
> So just to do b+c, it will need 2-way dispatch:
>
>
>   int temp
>   if b.type=c.type=int then        # Hey, a chained compare example!
>      temp = b.ivalue+c.ivalue
>   else
>     .... # error? Unless "+" is defined for float arrays, array+iny
>   end
>
> Now to assign result to a:
>
>   if a.type=float_array then
>      // destroy resources, or decr reference count for array
>   end
>
>   a.type = int
>   a.ivalue = temp
>
> And that's just for one valid combination, and one type of temp, so that
> 'a' is only ever going to be assigned an int. How about:
>
>   type U = int32 | int64 | float32 | float64
>
>   U a, b, c, d, e
>
>   a = b*c + d*e
>
> All 16 combinations of types should be valid, but do you want to try
> writing the switch statements for them?
> > I don't think this amount of boilerplate is practical to write as inline
> code.

If you write impractical code, you must expect inefficient results.

It is not common for constructed types to automatically inherit support
for operations or functions from their parts. An array of floats does
not inherit addition from float, a struct of 3 ints does not inherit
multiplication from its constituent ints. A variant or tagged union
does not (in most languages or libraries) inherit arithmetic operations
from its parts even if they all support them individually.

So the programmer who makes the U type, decides what is sensible to do
with elements of the type. /They/ decide which combinations are
allowed, and how they are implemented.

(A helpful language might also generate some of the boilerplate code
automatically.)

Of course, a variant like your example here is unlikely to be found in
real code. Some more likely examples could be a type that can hold a
valid result or an error number:

type Result = Value int | Error int

A binomial "Tree" might be a leaf with a string, or a node with two
branches :

type Tree = Leaf string | Node Tree Tree

In more theoretical programming (such as with functional programming
languages), such "sum types" are as important as "product types", which
you know of as structs or records.

>
> You should however try doing so for example fragments of code to see as
> I suggested to see what is involved.
>
> This type of variant means that:
>
>    a := a[i]
>
> could be legal. Anything goes.

Anything the programmer decides to allow and support, goes.

On 2021-09-23 00:13, Bart wrote:

> That Switch example is meaningless without knowing what operation is
> being performed in the source code, hence the request for the
> corresponding fragment of source code.

The predefined operations should be:

1. Equality/inequality
2. Access to the constraint (the selector value, read-only)
3. Member access (the variant value, read/write)
4. Aggregate (literal value)
5. Assignment as a whole, IFF variant is definite, otherwise, no assignment.

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

On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
> On 2021-09-23 00:13, Bart wrote:
>
>> That Switch example is meaningless without knowing what operation is
>> being performed in the source code, hence the request for the
>> corresponding fragment of source code.
>
> The predefined operations should be:
>
> 1. Equality/inequality
> 2. Access to the constraint (the selector value, read-only)
> 3. Member access (the variant value, read/write)
> 4. Aggregate (literal value)
> 5. Assignment as a whole, IFF variant is definite, otherwise, no
> assignment.

But you can't do A+B? See, this is the sort of information which needs
to be explicitly stated: what sort of 'variant' are we talking about;
what are the possibilities, and what even source code might look like.

What do you have to do in a language with YOUR idea of a variant, in
order to evaluate A+B? Assuming it can be done, what goes on behind the
scenes?

If you have a variant which can include suitable types, tell me why any
of the following operations, which I generally allow, should not apply
to variants.

In your first link, there is a variant record shown with 50 different
types. A user-defined one could have more than that, including user
defined types.

add
sub
mul
div
idiv
irem
iand
ior
ixor
and
or
shl
shr
eq
ne
lt
le
ge
gt
neg
abs
inot
not
sqrt
sin
cos etc
conversions
indexing
slicing
bit indexing
bitfield slicing
member selection
call
len
lwb/upb
minvalue/maxvalue
switch index
in/not in
min/max

addto (augmented assignmnt)
subto
multo
divto
idivto
iremto
iandto
iorto
ixorto
andto
orto
shlto
shrto
negto
absto
inotto
notto
incr
decr
minto/maxto

Oh, and assignment. And sort(). And dozens of other operations usually
implemented as library functions rather than as built-in ops.

On 23/09/2021 08:10, David Brown wrote:
> On 22/09/2021 21:47, Bart wrote:
>> On 22/09/2021 15:24, James Harris wrote:
>>> On 09/09/2021 22:04, Bart wrote:
>>
>>>> Also, Variants could presumably be assigned something else of a
>>>> different type? Then you can't even assume it will stay the same type.
>>>
>>> Wouldn't code which handles variants typically include a switch on the
>>> type as in the following?
>>>
>>>    switch T.type
>>>      case int:
>>>        /* Handle int */
>>>      case array float:
>>>        /* Handle array of float */
>>>    end switch /* Ignoring other cases */
>>
>> You need to show an example of source code where such types are used,
>> and see that the generated code might be like.
>>
>
> Variant types are typically implemented by having a "type" field - an
> integer that says which of the allowed types is currently valid. In
> C++, this is std::variant. In Pascal, it is a "tagged union" or
> "variant record".
>
> In C, you might have :
>
> typedef struct {
> enum { T_is_int, T_is_float } type_index;
> union {
> int int_value;
> float float_value;
> }
> } T;
>
> switch (t.type_index) {
> case T_is_int :
> // Use t.int_value
> break;
> case T_is_float :
> // Use t.float_value
> break;
> }
>

No one has yet explained exactly what kind of variant they are talking
about.

You're assuming it is just a tagged union or sumtype, where all you can
do is write explicit code to extract one of the possible values.

Or if you try and use one of those values directly (t.int_value) the
compiler will perform a behind the scenes check that it is an int.

The C++ variant might do a little bit more.

The kind of variant I've used in dynamic code is considerably more powerful:

for x in (100, 23.4, "cat", 50..60, [7,8,9], (100,110,120)) do
println x.type, "\t", x
end

Here, 'x' is a variant type (actually, everything is), and can store
/anything/. The output of this program is:

int 100
real 23.400000
string cat
range 50..60
set [7..9]
list (100,110,120)

I assumed James was talking about the kind of variant which can only
represent a predefined set of types, and which was to be implemented in
static code.

On 2021-09-23 11:38, Bart wrote:
> On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
>> On 2021-09-23 00:13, Bart wrote:
>>
>>> That Switch example is meaningless without knowing what operation is
>>> being performed in the source code, hence the request for the
>>> corresponding fragment of source code.
>>
>> The predefined operations should be:
>>
>> 1. Equality/inequality
>> 2. Access to the constraint (the selector value, read-only)
>> 3. Member access (the variant value, read/write)
>> 4. Aggregate (literal value)
>> 5. Assignment as a whole, IFF variant is definite, otherwise, no
>> assignment.
>
> But you can't do A+B?

Because it is not defined. If the programmer wants "+", Foo, Boo he can
declare and implement them as with any other type.

> What do you have to do in a language with YOUR idea of a variant, in
> order to evaluate A+B? Assuming it can be done, what goes on behind the
> scenes?

Nothing. What you see is what you get.

> If you have a variant which can include suitable types, tell me why any
> of the following operations, which I generally allow, should not apply
> to variants.

Tell me why they should. Days of PL/1 are gone.

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

On 2021-09-23 11:54, Bart wrote:

> You're assuming it is just a tagged union or sumtype, where all you can
> do is write explicit code to extract one of the possible values.

Why there should be more?

If you want more, you must tell that in the language. For this you need
subtypes (that pesky polymorhpism), e.g. variant being a subtype of the
type of some/all of its members.

It is the stuff you are unwilling to support, telling us that you do not
need it. Why asking then?

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

On 23/09/2021 11:22, Dmitry A. Kazakov wrote:
> On 2021-09-23 11:38, Bart wrote:
>> On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
>>> On 2021-09-23 00:13, Bart wrote:
>>>
>>>> That Switch example is meaningless without knowing what operation is
>>>> being performed in the source code, hence the request for the
>>>> corresponding fragment of source code.
>>>
>>> The predefined operations should be:
>>>
>>> 1. Equality/inequality
>>> 2. Access to the constraint (the selector value, read-only)
>>> 3. Member access (the variant value, read/write)
>>> 4. Aggregate (literal value)
>>> 5. Assignment as a whole, IFF variant is definite, otherwise, no
>>> assignment.
>>
>> But you can't do A+B?
>
> Because it is not defined. If the programmer wants "+", Foo, Boo he can
> declare and implement them as with any other type.

Show me. Let's say with a variant that can be an Integer, or a String.

And let's say that "+" is defined between two such variants when they
contain integers.

What does the source code look like to make it possible. And what will
the behind-the-scenes code be?

Assume that what the user wants to do is something like this:

Variant (String | Int) a, b, c

b := 200
c := 300
.... undisclosed code
a := b + c

print a

Would that be possible? What should it do when 'c' is set to a string?

>> What do you have to do in a language with YOUR idea of a variant, in
>> order to evaluate A+B? Assuming it can be done, what goes on behind
>> the scenes?
>
> Nothing. What you see is what you get.
>
>> If you have a variant which can include suitable types, tell me why
>> any of the following operations, which I generally allow, should not
>> apply to variants.
>
> Tell me why they should. Days of PL/1 are gone.

Most languages allows all those ops, or a big subset.

You seem to be saying that A+B is allowed when A and B are both int types.

But not when A and B are variant types, even if that type is (Int |
Real), not without a lot of work.

Then that's not a Variant type as I understand it. It's just a union or
tagged union, a much cruder type.

On 2021-09-23 12:40, Bart wrote:
> On 23/09/2021 11:22, Dmitry A. Kazakov wrote:
>> On 2021-09-23 11:38, Bart wrote:
>>> On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
>>>> On 2021-09-23 00:13, Bart wrote:
>>>>
>>>>> That Switch example is meaningless without knowing what operation
>>>>> is being performed in the source code, hence the request for the
>>>>> corresponding fragment of source code.
>>>>
>>>> The predefined operations should be:
>>>>
>>>> 1. Equality/inequality
>>>> 2. Access to the constraint (the selector value, read-only)
>>>> 3. Member access (the variant value, read/write)
>>>> 4. Aggregate (literal value)
>>>> 5. Assignment as a whole, IFF variant is definite, otherwise, no
>>>> assignment.
>>>
>>> But you can't do A+B?
>>
>> Because it is not defined. If the programmer wants "+", Foo, Boo he
>> can declare and implement them as with any other type.
>
> Show me. Let's say with a variant that can be an Integer, or a String.

function "+" (Left, Right : Variant) return Variant;

>>> If you have a variant which can include suitable types, tell me why
>>> any of the following operations, which I generally allow, should not
>>> apply to variants.
>>
>> Tell me why they should. Days of PL/1 are gone.
>
> Most languages allows all those ops, or a big subset.

None I know of.

> You seem to be saying that A+B is allowed when A and B are both int types.
>
> But not when A and B are variant types, even if that type is (Int |
> Real), not without a lot of work.

Again, what is the reason why?

> Then that's not a Variant type as I understand it. It's just a union or
> tagged union, a much cruder type.

You confuse a variant type with an ad-hoc class of types. A variant type
is not a class of its member types. These are semantically different
types, though they might have similar representations.

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

On 23/09/2021 12:15, Dmitry A. Kazakov wrote:
> On 2021-09-23 12:40, Bart wrote:
>> On 23/09/2021 11:22, Dmitry A. Kazakov wrote:
>>> On 2021-09-23 11:38, Bart wrote:
>>>> On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-23 00:13, Bart wrote:
>>>>>
>>>>>> That Switch example is meaningless without knowing what operation
>>>>>> is being performed in the source code, hence the request for the
>>>>>> corresponding fragment of source code.
>>>>>
>>>>> The predefined operations should be:
>>>>>
>>>>> 1. Equality/inequality
>>>>> 2. Access to the constraint (the selector value, read-only)
>>>>> 3. Member access (the variant value, read/write)
>>>>> 4. Aggregate (literal value)
>>>>> 5. Assignment as a whole, IFF variant is definite, otherwise, no
>>>>> assignment.
>>>>
>>>> But you can't do A+B?
>>>
>>> Because it is not defined. If the programmer wants "+", Foo, Boo he
>>> can declare and implement them as with any other type.
>>
>> Show me. Let's say with a variant that can be an Integer, or a String.
>
>    function "+" (Left, Right : Variant) return Variant;

So, what does that do? Does it magically allow A+B?

If not, then what's the point?

If it does, then we're back to square one: if A+B is now allowed in user
code, how is it implemented?

(Also, what is the 'Variant' in your example; is it the name of a
specific user type, so N such declarations are needed, or is it a
generic 'variant' so that this declaration suffices for all possible types?)

Suppose, also, that variant A is (int | real), and variant B is (real |
string)'; can I do A+B? (Here A,B represent types.)

I'm not expecting any actual concrete answers. I'm just interested in
how you will avoid answering the question this time.

>
>>>> If you have a variant which can include suitable types, tell me why
>>>> any of the following operations, which I generally allow, should not
>>>> apply to variants.
>>>
>>> Tell me why they should. Days of PL/1 are gone.
>>
>> Most languages allows all those ops, or a big subset.
>
> None I know of.
>
>> You seem to be saying that A+B is allowed when A and B are both int
>> types.
>>
>> But not when A and B are variant types, even if that type is (Int |
>> Real), not without a lot of work.
>
> Again, what is the reason why?

Why what? Why I should be able to do A+B?

If not, then what is the purpose of a Variant type, other than as a
glorified union.

>
>> Then that's not a Variant type as I understand it. It's just a union
>> or tagged union, a much cruder type.
>
> You confuse a variant type with an ad-hoc class of types.

James' proposal looks to me like an ad-hoc collection of types, within
an umbrella type.

It might also be specifically created to get away from terms like class,
and member and inheritance!

On 2021-09-23 13:34, Bart wrote:
> On 23/09/2021 12:15, Dmitry A. Kazakov wrote:
>> On 2021-09-23 12:40, Bart wrote:
>>> On 23/09/2021 11:22, Dmitry A. Kazakov wrote:
>>>> On 2021-09-23 11:38, Bart wrote:
>>>>> On 23/09/2021 10:14, Dmitry A. Kazakov wrote:
>>>>>> On 2021-09-23 00:13, Bart wrote:
>>>>>>
>>>>>>> That Switch example is meaningless without knowing what operation
>>>>>>> is being performed in the source code, hence the request for the
>>>>>>> corresponding fragment of source code.
>>>>>>
>>>>>> The predefined operations should be:
>>>>>>
>>>>>> 1. Equality/inequality
>>>>>> 2. Access to the constraint (the selector value, read-only)
>>>>>> 3. Member access (the variant value, read/write)
>>>>>> 4. Aggregate (literal value)
>>>>>> 5. Assignment as a whole, IFF variant is definite, otherwise, no
>>>>>> assignment.
>>>>>
>>>>> But you can't do A+B?
>>>>
>>>> Because it is not defined. If the programmer wants "+", Foo, Boo he
>>>> can declare and implement them as with any other type.
>>>
>>> Show me. Let's say with a variant that can be an Integer, or a String.
>>
>>     function "+" (Left, Right : Variant) return Variant;
>
> So, what does that do?

Whatever the programmer puts inside it.

> Does it magically allow A+B?

Yes, when you declare a function you can magically call it.

> If not, then what's the point?

No idea, you asked how to declare a function "+". The point is up to you.

> (Also, what is the 'Variant' in your example; is it the name of a
> specific user type, so N such declarations are needed, or is it a
> generic 'variant' so that this declaration suffices for all possible
> types?)

Read the link I posted:

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

> Suppose, also, that variant A is (int | real), and variant B is (real |
> string)'; can I do A+B? (Here A,B represent types.)

Nope.

>>> But not when A and B are variant types, even if that type is (Int |
>>> Real), not without a lot of work.
>>
>> Again, what is the reason why?
>
> Why what? Why I should be able to do A+B?

Yes, why should you be able to call arbitrary operations on arbitrary types.

> If not, then what is the purpose of a Variant type, other than as a
> glorified union.

None, variant is exactly a tagged union AKA variant record.

>>> Then that's not a Variant type as I understand it. It's just a union
>>> or tagged union, a much cruder type.
>>
>> You confuse a variant type with an ad-hoc class of types.
>
> James' proposal looks to me like an ad-hoc collection of types, within
> an umbrella type.

That is not variant, that is an ad-hoc class with inheritance and all
bells and whistles. He may not understand that or be in denial, but that
is his problem.

> It might also be specifically created to get away from terms like class,
> and member and inheritance!

He has his delusions you have yours.

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

On 23/09/2021 13:20, Dmitry A. Kazakov wrote:
> On 2021-09-23 13:34, Bart wrote:

>> If not, then what is the purpose of a Variant type, other than as a
>> glorified union.
>
> None, variant is exactly a tagged union AKA variant record.

Then we're talking at cross purposes.

This was entirely the point of my request for usage examples in source
code, then the kind of variant people had in mind would become more
apparent.

In my language, if I implemented the type of variant I assumed this was,
A+B (and EVERY operation normally allowed for fixed static types) would
be allowed for any two variants, provided it was meaningful between at
least two combinations of types from each side.

But it would be horrendous to implement in a static language.

This is the proposed feature in action:

type T = int | real | string

function biggerof (T a, b)=>T =
if a>b then
return a
else
return b
fi
end

println biggerof(100, 200) # 200
println biggerof(pi, 2) # 3.14159...
println biggerof("two","three") # two (alphatical ordering)
println biggerof(23, "45") # error (runtime or compiletime)

Note that this is not generics, so 'biggerof' is not a template for
multiple instantiations of 'biggerof'; it is just one function.

(This is the kind of example that would have made things clear.)

>
>>>> Then that's not a Variant type as I understand it. It's just a union
>>>> or tagged union, a much cruder type.
>>>
>>> You confuse a variant type with an ad-hoc class of types.
>>
>> James' proposal looks to me like an ad-hoc collection of types, within
>> an umbrella type.
>
> That is not variant, that is an ad-hoc class with inheritance and all
> bells and whistles. He may not understand that or be in denial, but that
> is his problem.
>
>> It might also be specifically created to get away from terms like
>> class, and member and inheritance!
>
> He has his delusions you have yours.

We're both implementing actual languages.

On 23/09/2021 11:54, Bart wrote:
> On 23/09/2021 08:10, David Brown wrote:
>> On 22/09/2021 21:47, Bart wrote:
>>> On 22/09/2021 15:24, James Harris wrote:
>>>> On 09/09/2021 22:04, Bart wrote:
>>>
>>>>> Also, Variants could presumably be assigned something else of a
>>>>> different type? Then you can't even assume it will stay the same type.
>>>>
>>>> Wouldn't code which handles variants typically include a switch on the
>>>> type as in the following?
>>>>
>>>>     switch T.type
>>>>       case int:
>>>>         /* Handle int */
>>>>       case array float:
>>>>         /* Handle array of float */
>>>>     end switch /* Ignoring other cases */
>>>
>>> You need to show an example of source code where such types are used,
>>> and see that the generated code might be like.
>>>
>>
>> Variant types are typically implemented by having a "type" field - an
>> integer that says which of the allowed types is currently valid.  In
>> C++, this is std::variant.  In Pascal, it is a "tagged union" or
>> "variant record".
>>
>> In C, you might have :
>>
>>     typedef struct {
>>         enum { T_is_int, T_is_float } type_index;
>>         union {
>>             int int_value;
>>             float float_value;
>>         }
>>     } T;
>>     
>>     switch (t.type_index) {
>>         case T_is_int :
>>             // Use t.int_value
>>             break;
>>         case T_is_float :
>>             // Use t.float_value
>>             break;
>>     }
>>
>
> No one has yet explained exactly what kind of variant they are talking
> about.
>
> You're assuming it is just a tagged union or sumtype, where all you can
> do is write explicit code to extract one of the possible values.

That is almost exactly what a variant /is/. But you are missing a few
operations - you can also read which type is contained in some manner
(perhaps by reading a field, perhaps by pattern matching or a special
type of switch, perhaps by trial-and-error and exceptions), and of
course you can assign values to it.

You seem to be mixing up variants with dynamic typing. Perhaps you have
been playing with Visual Basic, and copied MS's misuse of the term.

>
> Or if you try and use one of those values directly (t.int_value) the
> compiler will perform a behind the scenes check that it is an int.
>
> The C++ variant might do a little bit more.
>
> The kind of variant I've used in dynamic code is considerably more
> powerful:
>
>    for x in (100, 23.4, "cat", 50..60, [7,8,9], (100,110,120)) do
>        println x.type, "\t", x
>    end
>

It is not "more powerful". It is /different/. You can do some things
with it that you can't do with a real variant (as the term is normally
used), but it has other limitations.

Basically, what you are talking about is a void* pointer. That is
flexible, but has severe disadvantages in being sure your code is
correct. (Python uses a similar idea - it is great for writing quick
and dirty scripts or simple code, but terrible when you want to work
with large code bases and where you need to /know/ the code is correct,
not just run some tests.)

On 2021-09-23 15:47, Bart wrote:

> This is the proposed feature in action:
>
>    type T = int | real | string
>
>    function biggerof (T a, b)=>T =
>        if a>b then
>           return a
>        else
>           return b
>        fi
>     end

Type inference, when the interfaces of the class members are somehow
combined = non-starter.

It is impossible to infer semantics from interfaces. No need to discuss.

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

On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
> On 2021-09-23 15:47, Bart wrote:
>
>> This is the proposed feature in action:
>>
>>     type T = int | real | string
>>
>>     function biggerof (T a, b)=>T =
>>         if a>b then
>>            return a
>>         else
>>            return b
>>         fi
>>      end
>
> Type inference, when the interfaces of the class members are somehow
> combined = non-starter.
>
> It is impossible to infer semantics from interfaces. No need to discuss.
>

I don't really know what you're talking about. Such a feature works fine
in dynamic code:

function biggerof (a, b) =
if a>b then
return a
else
return b
fi
end

println biggerof(100, 200) ! 200
println biggerof(pi, 2) ! 3.14159...
println biggerof("two","three") ! two (alphatical ordering)
println biggerof(23, "45") ! error (runtime or compiletime)

Output is:

200
3.141593
two
PC Error:
Types not supported: comparemixed : int/string

What it doesn't do is restrict the types to int/real/string. I'd have to
do that manually to emulate my proposal more closely:

var T := (int, real, string) # just a list, not a type

function biggerof (a, b) =
unless a.type in T and b.type in T then
abort("Illegal types")
end
...

Now a call like: 'println biggerof(10..20, 30..40)' will fail ('range'
is not one of int, real, string).

So it is viable in static. But in my view not practical without
implementing most of a dynamic type system.

(Note that my biggerof() function does the same job as the built-in
max() operator; I couldn't think of a better example off-hand.)

On 2021-09-23 16:31, Bart wrote:
> On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
>> On 2021-09-23 15:47, Bart wrote:
>>
>>> This is the proposed feature in action:
>>>
>>>     type T = int | real | string
>>>
>>>     function biggerof (T a, b)=>T =
>>>         if a>b then
>>>            return a
>>>         else
>>>            return b
>>>         fi
>>>      end
>>
>> Type inference, when the interfaces of the class members are somehow
>> combined = non-starter.
>>
>> It is impossible to infer semantics from interfaces. No need to discuss.
>
> I don't really know what you're talking about. Such a feature works fine
> in dynamic code:

You just have illustrated the point by providing a broken program that
has a type error at run time.

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

On 23/09/2021 15:48, Dmitry A. Kazakov wrote:
> On 2021-09-23 16:31, Bart wrote:
>> On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
>>> On 2021-09-23 15:47, Bart wrote:
>>>
>>>> This is the proposed feature in action:
>>>>
>>>>     type T = int | real | string
>>>>
>>>>     function biggerof (T a, b)=>T =
>>>>         if a>b then
>>>>            return a
>>>>         else
>>>>            return b
>>>>         fi
>>>>      end
>>>
>>> Type inference, when the interfaces of the class members are somehow
>>> combined = non-starter.
>>>
>>> It is impossible to infer semantics from interfaces. No need to discuss.
>>
>> I don't really know what you're talking about. Such a feature works
>> fine in dynamic code:
>
> You just have illustrated the point by providing a broken program that
> has a type error at run time.
>

It has an /error/ at runtime. Lots of programs have errors which occur
then, such as input errors. The language might deal with that by
generating an exception, which can be checked for, or just checking the
inputs, then it can issue a message, or do something else.

The program below does arithmetic on user input, so the compiler won't
know what types are being added (since they are dynamic).

Are you saying this program is broken?

const expr_error=10

do
print "Enter A and B> "
readln a, b # a,b can be numbers, or strings
stop when a=""

try
c := dosum(a,b)
fprintln "# + # is #", a, b, c

except expr_error then
fprintln "Can't add # and #", a, b

end
od

function dosum(a,b)=
unless a.isnumber and b.isnumber then
raise exprerror
end
return a+b
end

(This language can actually add strings or numbers, but it can't mix
them. The example allows only numbers.)

On 2021-09-23 17:23, Bart wrote:
> On 23/09/2021 15:48, Dmitry A. Kazakov wrote:
>> On 2021-09-23 16:31, Bart wrote:
>>> On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
>>>> On 2021-09-23 15:47, Bart wrote:
>>>>
>>>>> This is the proposed feature in action:
>>>>>
>>>>>     type T = int | real | string
>>>>>
>>>>>     function biggerof (T a, b)=>T =
>>>>>         if a>b then
>>>>>            return a
>>>>>         else
>>>>>            return b
>>>>>         fi
>>>>>      end
>>>>
>>>> Type inference, when the interfaces of the class members are somehow
>>>> combined = non-starter.
>>>>
>>>> It is impossible to infer semantics from interfaces. No need to
>>>> discuss.
>>>
>>> I don't really know what you're talking about. Such a feature works
>>> fine in dynamic code:
>>
>> You just have illustrated the point by providing a broken program that
>> has a type error at run time.
>
> It has an /error/ at runtime.

Not an error, a type error = the language's type system is broken, as
expected.

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

On 23/09/2021 16:47, Dmitry A. Kazakov wrote:
> On 2021-09-23 17:23, Bart wrote:
>> On 23/09/2021 15:48, Dmitry A. Kazakov wrote:
>>> On 2021-09-23 16:31, Bart wrote:
>>>> On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
>>>>> On 2021-09-23 15:47, Bart wrote:
>>>>>
>>>>>> This is the proposed feature in action:
>>>>>>
>>>>>>     type T = int | real | string
>>>>>>
>>>>>>     function biggerof (T a, b)=>T =
>>>>>>         if a>b then
>>>>>>            return a
>>>>>>         else
>>>>>>            return b
>>>>>>         fi
>>>>>>      end
>>>>>
>>>>> Type inference, when the interfaces of the class members are
>>>>> somehow combined = non-starter.
>>>>>
>>>>> It is impossible to infer semantics from interfaces. No need to
>>>>> discuss.
>>>>
>>>> I don't really know what you're talking about. Such a feature works
>>>> fine in dynamic code:
>>>
>>> You just have illustrated the point by providing a broken program
>>> that has a type error at run time.
>>
>> It has an /error/ at runtime.
>
> Not an error, a type error = the language's type system is broken, as
> expected.
>

The language has one type: a 'variant'. A and B will ALWAYS be variants,
so they can never have the wrong type.

The tagged type-code is effectively runtime data.

You clearly don't like it, and anything you don't like, is broken in
your eyes.

On 2021-09-23 18:05, Bart wrote:
> On 23/09/2021 16:47, Dmitry A. Kazakov wrote:
>> On 2021-09-23 17:23, Bart wrote:
>>> On 23/09/2021 15:48, Dmitry A. Kazakov wrote:
>>>> On 2021-09-23 16:31, Bart wrote:
>>>>> On 23/09/2021 14:57, Dmitry A. Kazakov wrote:
>>>>>> On 2021-09-23 15:47, Bart wrote:
>>>>>>
>>>>>>> This is the proposed feature in action:
>>>>>>>
>>>>>>>     type T = int | real | string
>>>>>>>
>>>>>>>     function biggerof (T a, b)=>T =
>>>>>>>         if a>b then
>>>>>>>            return a
>>>>>>>         else
>>>>>>>            return b
>>>>>>>         fi
>>>>>>>      end
>>>>>>
>>>>>> Type inference, when the interfaces of the class members are
>>>>>> somehow combined = non-starter.
>>>>>>
>>>>>> It is impossible to infer semantics from interfaces. No need to
>>>>>> discuss.
>>>>>
>>>>> I don't really know what you're talking about. Such a feature works
>>>>> fine in dynamic code:
>>>>
>>>> You just have illustrated the point by providing a broken program
>>>> that has a type error at run time.
>>>
>>> It has an /error/ at runtime.
>>
>> Not an error, a type error = the language's type system is broken, as
>> expected.
>
> The language has one type: a 'variant'. A and B will ALWAYS be variants,
> so they can never have the wrong type.

They do since you infer operations from member types. That cannot work
and it does not.

Properly designed languages inherit interfaces rather than infer them.
Interface lists operations applicable to the type.

This allows to ensure existence of implementations of all operations at
compile time, statically, so that no type error (AKA "operation not
understood") may ever occur.

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