Re: Discriminants of tagged types

[Shark8 <onewingedshark@gmail.com>]

On Oct 31, 3:06 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 31 Paź, 19:36, Shark8 <onewingedsh...@gmail.com> wrote:
>
> > I got one for you; I was using tagged types to implement the typing-
> > system for a PostScript interpreter.
>
> Yes, this is a good example.
> But then - do we consider assignment to be part of the "copyability"
> property?
> That is, it might be meaningful for your objects to be cloned
> (duplicated), but is it also meaningful for them to be assigned to one
> another?

The assignability of PostScript objects is, IMO, a non-issue.
Most objects are created via PostScript commands, and those that
aren't are the ones which [arguably] are the PostScript interpreter
(the stacks and dictionaries of the interpreter).

While PostScript does have 'arrays' and procedures/functions (which
are merely executable arrays) they are produced by pushing a Mark
object and then zero-or-more PostScript objects, and a terminal-mark
object (which pops everything to-and including the mark off the stack,
packages them, and pushes the newly-created array-object onto the
stack); so it is somewhat similar to the Mark/Release dynamic memory
management paradigm.

You can put a name-object into one of the dictionary-objects and
associate it with some object from the stack; this is how procedures
are done. {Then when the interpreter encounters a name-object it looks
through the dictionaries to execute the associated object.}

So, in as far as the PostScript interpreter is concerned, I don't see
any particular reason assignments would be needed, excepting to class-
wide types.

> Is the assignment meaningful only within the same type, or across the
> hierarchy as well?
>
> The reason for the above question is that even though at the language
> level copy initialization and assignment are somewhat mixed together
> by the type being either limited or not, they are in fact distinct
> concepts and not that much similar.
>
> In the tutorial analogy of famous shapes, it might be perfectly
> reasonable to duplicate an arbitrary Shape'Class (whatever it is), but
> it will be completely unreasonable to assign Square to some existing
> Circle.

Interesting you mention that; I was working on a bit of a vector-
graphic program for a computer graphics class and I was kicking around
the idea of allowing such 'assignments' as being the equivalent of
"make a shape of this new type which has the same bounding rectangle."
I eventually decided against it because:
1 - The existence of an arbitrary and complex polygon would gum up the
works,
and
2) I'm lazy.

;)

> This problem alone would be sufficient for me to make
> everything limited.
> Similarly with the interpreter objects, states in FSMs, and so on.
>
> Thus, for the purpose of modeling clarity I prefer to distinguish
> between:
> - copyability, which means support for copy-initialization *and*
> assignment
> - cloneability, which is always deep

I can see how such is a useful distinction.

>
> So - even though my tagged types are typically limited, in some
> particular cases they can be also cloneable. It does not apply to
> files, sockets, database connections and similar things that are
> associated with some resources that exist outside of the physical
> representation of the object, but it might apply to self-contained
> data entities like interpreter instructions, document elements, states
> in FSMs, etc.
>
> I hope that the above clarification makes my rule of thumb more
> understandable and not really conflicting with your examples.

Hm, I see that it doesn't conflict... though one thing that was
bugging me was that Tasks cannot return values from their entries:
this means that I couldn't separate the parsing/object-generation from
the actual interpreter internals. {I was hoping to make it in such a
way that some server could run the parsing/object-creation possibly on
a different machine than the one the PostScript-objects would reside
on -- This would also allow for a single parser to serve multiple
PostScript interpreters on the same machine.}

And out parameters on a class-wide type wouldn't work because you need
to initialize a class-wide variable.
Today I found how to bypass the limitation by using a representation
clause.

[...]
  -- Inside the Parser-task, which may or may not be remote.
  -- Input is of In Out because a passed string may contain more than
one object,
  -- in that case the unconsumed portion of the string should be
returned to the client.
  Accept Parse( Output : Out PostScript_Object'Class; Input : In Out
String ) do
    Declare
      -- Because initialization of class-wide types are allowed,
      -- whereas assignments thereunto are not, unless the tags
      -- of both match. The class cannot be known until AFTER it is
parsed though.
      Temp : PostScript_Object'Class:= Parse_String( Input );
      For Temp'Address use Output'Address;
    Begin
        Null;
    End;
  end Parse;
[...]

So, I may be able to do it after all.
I'll just have to look at ensuring that the space used in the client-
side of portion is no less than the maximum size of a 'basic'
PostScript object.
>
> --
> Maciej Sobczak *http://www.inspirel.com