Re: Text_IO, was: Re: Something I don't understand

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:

> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:

>> To me text buffer, stream, file, string are all instances of the class of
>> types over which Put dispatches. OK, we can call the abstract root type of
>> the class "Text."
> 
> Perhaps Put would just be overloaded for these types. It depends if you
> consider the types a class, or not. I'm not sure what is best.

When you overload you get an explosion of variants which is especially
extreme in the case of MD, because you have N x M x L variants. It is
exponential to the number of independent hierarchies. For I/O it is at
least 3: medium, data, aggregated parameters. Fourth candidate could be
transaction state for complex I/O.

Another and even more serious issue is that ad-hoc polymorphism prevents
code reuse. You cannot inherit, you cannot write class-wide code because
you cannot have class-wide objects. Yet a typical usage of Text_IO is
class-wide. When designing a text processing or text rendering application
you don't want to deal with concrete types of medium. E.g. writing an
interpreter you want it working with whatever type of input, not just
string or just File_Type.

>>> The final
>>> "Put" would then render according to the output medium.
>> 
>> Yes, that Put would be an implementation of the primitive operation defined
>> for the class Text.
> 
> I would make Text a type, not a class. This would avoid the need for
> multiple dispatch on a controlling Text parameter.
> 
> I'm thinking of two levels of "Put":
> 
>    Put (To : in out Text, Item : in String);
>       Add items to a Text, building a logically structured Text,
>       but without rendering it yet. This wil probably need
>       some concept of "points in a Text where more stuff can
>       be inserted" so that the Put can preserve or extend the
>       logical Text structure.
> 
>    Put (To : in out File; Item : in Text);
>       Render the Text into some external File.
> 
> The Text buffer intermediary means that each level of Put can (if
> desired) be dispatching on one of the parameters, without needing
> multiple dispatch.

This was attempted before, many many times, actually. From PostScript to
HTML, an intermediate language that would take care of separating higher
level formatting from lower level rendering. It never worked how many times
tried.

And for sure, it will be even more hated than Text_IO page formatting is,
because the overhead will be far bigger. Imagine describing the semantics
of, say, conversion of File, Stream, String to Text and backward.

>> This search for other "ways" (aspects, generics etc) is really damaging the
>> language.
> 
> I don't agree. I see aspects as strengthening or broadening the type
> concept, and generics as a meta-type level.

Either is a parametrization. Parametrization does not broaden anything,
when held at the meta level. You can parametrize type, statement, object,
package, source code itself, you could even do the object code. It is
completely orthogonal to what is being parametrized and by which entities.

Parametrization is bad when the parametric entity is itself not a language
entity. E.g. discriminaned type is OK, because it is still a type. Generic
type is not OK, because it is not a type but something else. The latter is
an erosion of the type system not broadening.

> But I must admit that I have
> lately been using generics less often and have instead used classes and
> dispaching more often. However, I think that generics are useful and are
> not entirely subsumed by classes.

Both are classes, the means of constructing these classes are different and
so are the properties and usage of these classes.

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