Re: System.Address_to_Access_Conversions

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Matthew Heaney <matthew_heaney@acm.org> writes:
>
>"Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM> writes:
>
>>     This made tagged records a major nuisance to
>>     me when trying to utilize them in a communications situation where
>>     I wanted to beam the bits down a wire.
>
>If something is a "major nuisance" to do, then you should interpret that
>to mean that you shouldn't be doing it.

    Actually there is a good reason to try to do this. When writing
    software to do communication of messages down a wire, you really
    want to "have it both ways" You want strongly typed data so that
    you can properly interpret the messages, yet you also want the
    ability to treat them as raw bytes when doing the actual
    transmit/receive. Without going into it in too much depth, what I
    was trying to do was something that is easily done in assembly or
    other weakly typed languages (without any protection) but has been
    traditionally hard to do in Ada without introducing major
    inefficiencies. Tagged records provide a mechanism with which to
    do it reasonably well, but you have to go through some gyrations
    with streams to strip out the tags. (And most folks wouldn't care,
    but when you're trying to do this on a schedule, the extra layers
    of data motion become a "major nuisance".)

>
>Do not try to send a tagged type directly across an external interface.
>You must first convert the object to an external format, preferably
>using the streams facility and/or the DSA.

    Never tried to. Unless you can control *all* of the data you are
    sending, you shouldn't be trying to send it because you don't know
    what will be at the other end. The "stream" business provides an
    answer, (maybe) but not as good a one as I would like. It would
    have been better if I had the ability to control the placement and
    content of the tag, which would mean I could strip it out or
    otherwise get the raw bits I wanted with Unchecked_Conversion. Or
    barring that, at least be able to use the tag as a message ID or,
    with known size and placement, have it "reserved" in the message
    catalog so the other side knows to ignore it.

    It would take pages to try to explain exactly what I am doing with
    tagged records in this particular situation. They can be used and
    they do provide an answer for internal architectural problems. You
    just have to beg and plead with the compiler or find a way to deal
    with double buffering timing delays because of the lack of control
    over representation issues.
>
>>     There is a way to use streams to get rid of the tag information if
>>     you need to do it, but if you are in some way interested in
>>     utilizing tagged records to overlay physical hardware, etc., you
>>     will find there are no good answers.
>
>No good answers, becuase the question itself is all wrong.

    Which, as I recall, was the original poster's question about
    tagged records. I'm not sure why he wanted to overlay tagged
    records onto hardware, but (given that I've been there myself in
    embedded applications) I will reserve judgement on it being a good
    or bad idea. Often you have some slick software architecture plan
    and then you get down to having to connect to physical hardware
    that was designed by guys who are mostly familiar with assembly
    language programming - maybe Fortran - but have no concept of what
    you'd like to do in software. So you have to look for a way to
    connect up your slick software design with the physical
    characteristics of the hardware. (Consider that you'd like to
    apply the latest ideas of Object Oriented Programming to an
    embedded application - "Tagged records, let me introduce you to
    Hardware...") Maybe that's where he was at.

    I'd agree that it is not a desirable place to be, because you have
    so little control over the representation of tagged records. But
    that doesn't necessarily mean that a tagged record (or
    discriminated record or plain vanilla record) might not be the
    best logical representation of the problem.

>
>>     If you come across information that suggests a solution to
>>     controlling representation of tagged record types that sounds
>>     standard and portable, I'd be interested in hearing about it.
>
>Please don't fight the language, as there are "standard and portable"
>ways to get the job done.  That the representation of a tagged type
>isn't under programmer control is a feature, not a flaw.
>
    Not being completely dim, I seldom tilt at windmills anymore and
    don't generally want to "fight the language". Still, I've needed
    control over tagged records and to date, the only mechanism that
    works completely is to know exactly what a given compiler produces
    and rely on those assumptions. Dangerous, volatile, and not
    standard or portable, but it has been known to work. It may be
    your only choice unless the project can afford to buy some
    compiler writers and eat the time needed to get the changes made.

    "Standard and portable" can be vastly overrated. In the embedded
    world, you quite often are looking at a situation where you are
    going to freeze the hardware and the compiler and it will remain
    thus for many years to come. In the event of "new" hardware or a
    similar system, you are almost always back at ground zero anyway,
    so you can forget "portability" without modification. (Yes, you do
    get to reuse software, but either a) it is at an abstract enough
    level where you don't care about representation anymore or b) it
    is at a sufficiently low level that you are going to have to
    change everything for hardware differences anyway, so the
    representation will have to be revisited no matter what you do.)
    Besides, a change in hardware typically means such a huge
    investment in other things that to develop the software again
    completely from the ground up is so far down in the weeds that
    nobody cares.

    I'd have to respectfully disagree about the lack of control of the
    representation of tagged types being a "feature" instead of a
    "flaw". Here's where I come from on that topic: Either a) I have
    no interest in how the bits are ordered, or b) I do. If the
    situation is A, then the compiler is free to do what it likes and
    I need no representation clause for a tagged record. If the answer
    is B, then I can look to the representation clause - which legally
    applies to tagged records - to get the control I want. If,
    however, the introduction of the representation clause only allows
    me to control the ordering of *some* of the bits, then I might
    just as well not have it at all, because that original condition
    is bistable: I either need control or I don't. So the fact that
    the representation clause won't let me deal with the tag, or the
    alignment as I extend a tagged type or in any other respect where
    the compiler is going to refuse a legitimate specification of
    representation, then there might just as well have been a rule in
    the language that said "representation clauses cannot be applied
    to tagged types".

    A prime example of this is when you have to build software which
    must respond to messages defined long ago and may be sent from
    anywhere. The bit ordering is what it is and you are not free to
    change it. So either you can control the representation of your
    data structures and take advantage of modern programming concepts
    (enumerations, discriminated/tagged records, abstract data types,
    etc.) or you can't control the representation and have to program
    at the lowest level of bit-twiddling to deal with reality.
    Naturally, I'd prefer to use the more advanced concepts and leave
    the shifting & masking of bits to the compiler.

    I've had reasons in the systems I design to use representation
    clauses for just about every kind of data type imaginable. If for
    no other reason than to guarantee the assumptions on which a
    system is founded, just in case someone tries to port the code or
    a compiler switch is made midstream. I appreciate it when the
    compiler notices that I've specified some representation is
    logically impossible. It would be nice if the compiler would warn
    you of potential inefficiencies in the representation you choose.
    It would be even nicer if the compiler were to spit out a pictorial
    memory layout of the representation you specified. But in all
    cases where I've specified what should be a legal specification
    and had it rejected by the compiler, I've cursed the developers
    for second-guessing me. The representation clause is supposed to
    be a "Trust me, I know what I'm doing" sort of thing similar to
    Unchecked_Conversion.

    Sorry for going off on a harangue - it's one of my favorite
    things to get frustrated about with compilers!

    MDC
Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "The race is not always to the swift, nor the battle to the
    strong - but that's the way to bet."
        --  Damon Runyon
=============================================================================