Re: [bug #62147] Expanded classes not printable

[Raphael Mack]

You raised an interesting question...

Am Montag, dem 07.03.2022 um 16:27 +0100 schrieb Paolo Redælli:
> I'm quite puzzled by this issue so I think it is better to discuss it
> in the mailinst list.

It's always good to discuss questions here :-)

> out_in_tagged_out_memory
>           -- Append terse printable representation of current object
> in 
> `tagged_out_memory'.
>        require
>           locked: tagged_out_locked
>        local
>           like_current: like Current
>        do
>           tagged_out_memory.append(generating_type)
>  >>>>>HERE         if like_current = Void then
>              -- Not an expanded type:
>              tagged_out_memory.extend('#')
>              to_pointer.append_in(tagged_out_memory)
>           end
>           tagged_out_memory.extend('[')
>           fill_tagged_out_memory
>           tagged_out_memory.extend(']')
>        end
> 
> because an expanded class could never be compared to Void, which is
> the 
> default reference (aka NULL for people accostumed to C). That piece
> of 
> code prints the address (pointer) of the object.
> 
> The compiler is right - Void does not conform to any expanded object 
> which are compared by value and not by reference.
> 
> I see three scenario:
> 
> 1) we remove the feature altogether from ANY.

I don't like it that much, as sometimes I found it handy to use the
shown addresses in a "printf-debug-session".

> 2) we keep it for reference objects but then ANY should have some 
> external "built_in" features such as is_reference:BOOLEAN and 
> is_expanded: BOOLEAN

Back in SmartEiffel times these features have been there with a
comment:
 This feature is obsolete: Since june 2007 this feature is obsolete
(see its definition in ANY to see how to work around). 

But to be honest I don't have the old source from then anymore here,
but I could imagine that the workaround would be to do the "= Void"
trick - which in a sense also is not clean.

> 
> 3) we want to print the address of each and every object, even
> expanded 
> one, so there must be a a function in the runtime but I fear it will
> be 
> far from simple to implement.

Printing the address for expanded types is even in a ugly-printf-
debugging not really meaningful, so this option is also not very nice.

> I wonder how such a issue has never been encountered before. It seem 
> that people do not print expanded classes.

And if, they will probably overwrite out.

I could also think of
4) make out_in_tagged_out_memory a built_in feature
which would be a quite handy time to also implement a generic version
of fill_tagged_out_memory in the compiler, there is should be easy to
check the type for it's expandedness. But this might not solve the
issue completely, as for example in ITERABLE we have the same trick
again.

5) check what other compilers do - I didn't find anything in ECMA to
check an object for its expanded state, but also I wonder whether the
comparison between reference and expanded types like in "3 = Void" is
and should be allowed.



@Eric do you remember trouble to check a type for its expandedness (or
use cases for this check) in gobo? What is implemented in ISE and gec?

Cheers,
Rapha