Record operations (Algebraic Data Types and printing)

Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

Hi! (Very) Slowly getting my Ada wheels rolling, didn't get the book yet etc. but anyway...

I'm coming from Scala world most recently and I like to leverage Algebraic Data Types (through sealed traits), or Discriminated Unions, as they were called in F#. I was happy to find out that Ada has Variant Record, which I believe pretty much covers the same thing. Maybe in a bit more verbose way. :) I'm somehow fascinated by the possibility to carry state as the type, thus with different data items for each state.

Now as I'm playing with the records, I'd like to print them out, just for "debugging" purposes. Is there any convenient way to splash them out in console? Some sort of default string representation? Seems that 'Image attribute works only for scalar types.

-Henrik

Re: Record operations (Algebraic Data Types and printing)

[AdaMagica]

Am Freitag, 5. Oktober 2018 19:46:32 UTC+2 schrieb Henrik Härkönen:

> Now as I'm playing with the records, I'd like to print them out, just for "debugging" purposes. Is there any convenient way to splash them out in console? Some sort of default string representation? Seems that 'Image attribute works only for scalar types.

Do it yourself... There is no such default.

A record may have private (even limited) components. What should a default for these look like?

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

On Friday, 5 October 2018 20:58:30 UTC+3, AdaMagica  wrote:
> Do it yourself... There is no such default.

Yes, I was coming to this conclusion quite quickly as well. Thought to ask, just in case. :)

> A record may have private (even limited) components. What should a default for these look like?

I have to say, I don't have any idea. As stated above, coming from Scala (and JVM) world, and having worked also with Python for years, Ada seems to be _quite_ a different world (to me at least). There you'd just toss an object to println() and get members listed as well with the values. But I guess we're not in Kansas anymore... :D 

I do have professional C background as well, but that's so low level stuff that I wouldn't expect anything fancy like that...

-H

Re: Record operations (Algebraic Data Types and printing)

[Niklas Holsti]

On 18-10-05 21:11 , Henrik Härkönen wrote:
> On Friday, 5 October 2018 20:58:30 UTC+3, AdaMagica  wrote:
>> Do it yourself... There is no such default.
>
> Yes, I was coming to this conclusion quite quickly as well. Thought
> to ask, just in case. :)

I suppose most Ada programmers have at some time wished for an 'Image 
attribute for records. And arrays.

> ... As stated above, coming from
> Scala (and JVM) world, and having worked also with Python for years,
> Ada seems to be _quite_ a different world (to me at least).

Ada has essentially no means for run-time reflection, such as 
programmatic access to the type structure of the running program.

The ASIS library provides off-line (post-compilation) access to such 
information, and could be used to create source code for Image functions 
for the record types, which could then be added to a recompilation of 
the original program.

> I do have professional C background as well, but that's so low level
> stuff that I wouldn't expect anything fancy like that...

Regarding reflection it seems to me that C and Ada are equally null.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

> Regarding reflection it seems to me that C and Ada are equally null.

Yes, it seems I've been with these heavy runtime languages too long, my mindset needs adjusting. :)

Re: Record operations (Algebraic Data Types and printing)

[J-P. Rosen]

Le 05/10/2018 à 19:58, AdaMagica a écrit :
> Do it yourself... There is no such default.
Yet. There is a proposal for Ada 202X, see AI12-0020

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

On Saturday, 6 October 2018 08:39:01 UTC+3, J-P. Rosen  wrote:
> Yet. There is a proposal for Ada 202X, see AI12-0020

Indeed, "AI12-0020-1 'Image for all types", sweet! :)

Re: Record operations (Algebraic Data Types and printing)

[Lucretia]

On Saturday, 6 October 2018 08:08:38 UTC+1, Henrik Härkönen  wrote:
> On Saturday, 6 October 2018 08:39:01 UTC+3, J-P. Rosen  wrote:
> > Yet. There is a proposal for Ada 202X, see AI12-0020
> 
> Indeed, "AI12-0020-1 'Image for all types", sweet! :)

Shame this doesn't seem to have made it into the latest standard :(

This is something that should've been in the language from the start or at least 95, this can be used for converting data, in a standard way, to XML, JSON, YAML or TOML, etc.

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:8903c94f-efc7-4a2c-9513-ee17890b49d2@googlegroups.com...
On Saturday, 6 October 2018 08:08:38 UTC+1, Henrik Härkönen  wrote:
> On Saturday, 6 October 2018 08:39:01 UTC+3, J-P. Rosen  wrote:
>> > Yet. There is a proposal for Ada 202X, see AI12-0020
>>
>> Indeed, "AI12-0020-1 'Image for all types", sweet! :)
>
>Shame this doesn't seem to have made it into the latest standard :(

It's (the Standard) not done yet. This is expected to make it in. Check back 
after the October ARG meeting.

>This is something that should've been in the language from the start or at
>least 95, this can be used for converting data, in a standard way, to XML,
> JSON, YAML or TOML, etc.

There's no 'Value proposed at this time. That is a much bigger problem for 
limited and private types (how does one get the value of a task or protected 
object?), it's messier for user-defined 'Image, etc. It's on the radar, but 
not likely for Ada 2020.

                                 Randy.

                                            Randy. 

Re: Record operations (Algebraic Data Types and printing)

[Lucretia]

On Tuesday, 9 October 2018 00:08:05 UTC+1, Randy Brukardt  wrote:
> "Lucretia" <> wrote in message 
> news:8903c94f-efc7-4a2c-.com...
> On Saturday, 6 October 2018 08:08:38 UTC+1, Henrik Härkönen  wrote:
> > On Saturday, 6 October 2018 08:39:01 UTC+3, J-P. Rosen  wrote:
> >> > Yet. There is a proposal for Ada 202X, see AI12-0020
> >>
> >> Indeed, "AI12-0020-1 'Image for all types", sweet! :)
> >
> >Shame this doesn't seem to have made it into the latest standard :(
> 
> It's (the Standard) not done yet. This is expected to make it in. Check back 
> after the October ARG meeting.

Ok.

> 
> >This is something that should've been in the language from the start or at
> >least 95, this can be used for converting data, in a standard way, to XML,
> > JSON, YAML or TOML, etc.
> 
> There's no 'Value proposed at this time. That is a much bigger problem for 
> limited and private types (how does one get the value of a task or protected 
> object?), it's messier for user-defined 'Image, etc. It's on the radar, but 
> not likely for Ada 2020.

Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in the package. Surely, it's not that hard.

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...
On Tuesday, 9 October 2018 00:08:05 UTC+1, Randy Brukardt  wrote:
...
>> >This is something that should've been in the language from the start or 
>> >at
>> >least 95, this can be used for converting data, in a standard way, to 
>> >XML,
>> > JSON, YAML or TOML, etc.
>>
>> There's no 'Value proposed at this time. That is a much bigger problem 
>> for
>> limited and private types (how does one get the value of a task or 
>> protected
>> object?), it's messier for user-defined 'Image, etc. It's on the radar, 
>> but
>> not likely for Ada 2020.
>
>Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in 
>the
> package. Surely, it's not that hard.

What package? We're talking about (in part) the default representation for a 
type. Stream attributes use a complex concept called "availability" to deal 
with limited types, and they don't worry about privacy breakage at all. 
'Value would need something similar at a minimum, and the question of 
privacy breakage also would have to be addressed (a package would not want 
some outside force constructing values for its types; they might not meet 
the [implied] invariants and other assumptions - remember, there would be no 
way to control what input was given to such an operator -- it would 
definitely be a new form of vunrability.). Contrast that to 'Image, which is 
defined for all types; they do in fact break privacy, but only for a reader; 
for a human reader, they can do the same privacy breakage by inspecting the 
source code. (And if inspecting the source code isn't allowed, the 
implementation can always use a user-defined Put_Image to eliminate any 
leakage.)

It's certainly not impossible (which is why it's considered for the future), 
but it's significantly harder than 'Image. The group as a whole seemed to 
think that if 'Image was tied to 'Value, it wasn't important enough for the 
substantial work. (I personally am closer to your position, but no one gets 
everything they want in Ada. And it would be a tough call as to what else to 
drop - this is a zero-sum game, there is only so much work time available.)

                                                   Randy.

Re: Record operations (Algebraic Data Types and printing)

[Dmitry A. Kazakov]

On 2018-10-10 00:20, Randy Brukardt wrote:
> "Lucretia" <laguest9000@googlemail.com> wrote in message
> news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...

>> Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in
>> the package. Surely, it's not that hard.
> 
> What package? We're talking about (in part) the default representation for a
> type.

What have T'Image and T'Value to do with the type representation?

> Stream attributes use a complex concept called "availability" to deal
> with limited types, and they don't worry about privacy breakage at all.

Limited types should have no stream attributes at all. Same applied to 
'Image/'Value. Returning limited object was a language design bug. This 
cannot be fixed but it can be contained.

> 'Value would need something similar at a minimum, and the question of
> privacy breakage also would have to be addressed (a package would not want
> some outside force constructing values for its types; they might not meet
> the [implied] invariants and other assumptions

[...]

Safe default is to generate publicly visible 'Image and 'Value 
propagating Use_Error for all types with private components. The package 
provider could override them in the public part with bodies renaming the 
private default implementations of which have full visibility.

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

Re: Record operations (Algebraic Data Types and printing)

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2018-10-10 00:20, Randy Brukardt wrote:

>> What package? We're talking about (in part) the default representation for a
>> type.
> 
> What have T'Image and T'Value to do with the type representation?

I suppose that if “for a type” here is to mean given type T one may apply
T’Image to an object (directly), then the result represents an object of
type T. Not in the sense of representation clauses, but in the sense of
printed value.

But are all Ada debuggers and simulators in such a state? I find staring at
trace logs unproductive in comparison.  Maybe, though, some programmers
like the challenge.

Re: Record operations (Algebraic Data Types and printing)

[Dmitry A. Kazakov]

On 2018-10-10 20:13, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2018-10-10 00:20, Randy Brukardt wrote:
> 
>>> What package? We're talking about (in part) the default representation for a
>>> type.
>>
>> What have T'Image and T'Value to do with the type representation?
> 
> I suppose that if “for a type” here is to mean given type T one may apply
> T’Image to an object (directly), then the result represents an object of
> type T. Not in the sense of representation clauses, but in the sense of
> printed value.

It does not. It represents an object of the type String. The value of 
the string may correspond to an object of the type T or can be used to 
create an object of the type T. Corresponds /= represents. Represents 
means substitutable.

Image/Value could represent T if String were a sub-/supertype of T. This 
is not possible in Ada. The litmus test is inheritance of the interface 
of T. If you could write something like this

    1'Image + 2 = "3"

You could say that 1'Image represents Integer'(1). And "3" represents 
Integer'(3).

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

Re: Record operations (Algebraic Data Types and printing)

[Björn Lundin]

On 2018-10-10 20:13, G. B. wrote:
> But are all Ada debuggers and simulators in such a state? I find staring at
> trace logs unproductive in comparison.  Maybe, though, some programmers
> like the challenge.

When a system is deployed, and there is no debugger attached,
and an incident occur (malfunction/crash/whatever),
I am very happy to look at the logs.
Debugging is then not an option, since it occurred in the past,
and may be very difficult - if not impossible -  to reproduce.

-- 
--
Björn

Re: Record operations (Algebraic Data Types and printing)

[Jacob Sparre Andersen]

Björn Lundin wrote:

> When a system is deployed, and there is no debugger attached, and an
> incident occur (malfunction/crash/whatever), I am very happy to look
> at the logs.

Same here.

> Debugging is then not an option, since it occurred in the past, and
> may be very difficult - if not impossible - to reproduce.

Actually, you can connect "gdb" to an already running process, but it is
of course limited what that can tell you about what went wrong before
you connected "gdb" to the process.

Greetings,

Jacob
-- 
"Don't get me wrong, perl is an OK operating system, but it
 lacks a lightweight scripting language."

Re: Record operations (Algebraic Data Types and printing)

[Björn Lundin]

On 2018-10-11 16:45, Jacob Sparre Andersen wrote:
> Actually, you can connect "gdb" to an already running process, but it is
> of course limited what that can tell you about what went wrong before
> you connected "gdb" to the process.

Yes, of course.
But that is of little use if the process crashed.
Then I need the log, and the stacktrace (found in the log)

-- 
--
Björn

Re: Record operations (Algebraic Data Types and printing)

[G. B.]

Björn Lundin <b.f.lundin@gmail.com> wrote:
> On 2018-10-10 20:13, G. B. wrote:
>> But are all Ada debuggers and simulators in such a state? I find staring at
>> trace logs unproductive in comparison.  Maybe, though, some programmers
>> like the challenge.
> 
> When a system is deployed, and there is no debugger attached,
> and an incident occur (malfunction/crash/whatever),
> I am very happy to look at the logs.
> Debugging is then not an option, since it occurred in the past,
> and may be very difficult - if not impossible -  to reproduce.
> 

(Side note: interpreting messages and stack traces, foreign and own, of
various qualities is part of my job description.)

Technical impossibility of debugging a failure from the past is  beside the
point, IMHO, as ‘Image would, by default, just dump textual representations
of internal data structures. Potentially including all kinds of information
that may be private in at least two senses, unless... First, minor
issue(?), Ada structures that you don’t want partners in business to know,
that you don’t want them to build something around, based on knowledge
gleaned from traces. I don’t like that kind of secrecy myself but you know
what programmers do when they take some implementation for granted,
ignoring the interface. Plus, there are business reasons. In any case,
these are called internal data structures for a reason. Second, if private
components become visible, that’s generous, but even technically the
correspondence with ‘Value should not be a victim of  supporting lazy
programmers’ easy ‘Image. I/O just isn’t, even for trace analysis.

So, unless you start “overriding” ‘Image ... — But! For which of those use
cases? Dmitry, should ‘Image be capable of MD as needed per use case?

It is easy to be tempted by ease of use of ‘Image!

 ‘Image turns us into a human interpreters of haphazard Lisp like symbols
in the end. Some programmers enjoy themselves doing this kind of
recreational symbolic mathematics.

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

"G. B." <nonlegitur@nmhp.invalid> wrote in message 
news:ppqrfp$7ct$1@dont-email.me...
...
> 'Image turns us into a human interpreters of haphazard Lisp like symbols
> in the end. Some programmers enjoy themselves doing this kind of
> recreational symbolic mathematics.

??

The default 'Image proposed is of course an Ada aggregate for the type. It 
only gets a bit weird for access values, task types, and protected types --  
but hopefully no one is looking much at the latter two and for the former 
one typically overrides with something meaningful (that's based on my 
experience doing this manually).

So "decoding" this is essentially the same as reading Ada code. If that's a 
hardship, you're in the wrong business. ;-)

                                              Randy.

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

"G. B." <nonlegitur@nmhp.invalid> wrote in message 
news:pplfgr$63i$1@dont-email.me...
...
> But are all Ada debuggers and simulators in such a state? I find staring 
> at
> trace logs unproductive in comparison.  Maybe, though, some programmers
> like the challenge.

Debuggers have their place, but a lot of problems either don't lend 
themselves to using a debugger (because they're not reproducible) or don't 
need it (because the failure itself gave enough information to fix it). In 
both of these cases, trace information can be very valuable. And (IMHO) in a 
well-designed program, you aren't recompling to add it because it is already 
there (almost all of my programs have a way - GUI box, command line option, 
etc. - to get additional tracing/logging from the norm).

The "don't need it" case might need a bit of explanation: failure of 
language-defined checks in Janus/Ada have always contained information about 
the failures and a call walkback with line numbers and subprogram names. (No 
wacky tools needed to get that!) That's also triggerable from program code, 
so we use the same mechanism for internal errors. (Also to note: for servers 
like our web server and spam filter, we can log that information into the 
usual server log.)

With information like that, it's possible at least 75% of the time to figure 
out what the actual problem was and how to fix it. Turning on the existing 
tracing for the affected subsystems will figure out many of the remaining 
cases. So I tend to use debuggers only when reproducible (it's always going 
to take more than one attempt to figure out what is going wrong, 'cause 
backwards execution isn't a realistic option) and mysterious.

The top case of that is when a hardware fault occurs rather than a 
language-defined check failure. Those are generally considered bugs in the 
Janus/Ada compilation system (although users can write erroneous code that 
will cause them, thru interfacing, unchecked_conversion, or streaming), and 
thus one can't really trust what was *supposed* to happen - the generated 
code is likely wrong and needs fixing.

Image for all types should make it easier to construct those logs and give 
better information in exception messages for user-defined exceptions. So 
that seems like a net win, regardless of whether a debugger could have given 
somewhat similar information.


                                                                Randy.

Re: Record operations (Algebraic Data Types and printing)

[Shark8]

On Wednesday, October 10, 2018 at 1:17:51 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-10-10 00:20, Randy Brukardt wrote:
> > "Lucretia"  wrote in message
> > news:fb2af9cb-5317-4f1c-867c-8876212d303b...
> 
> >> Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in
> >> the package. Surely, it's not that hard.
> > 
> > What package? We're talking about (in part) the default representation for a
> > type.
> 
> What have T'Image and T'Value to do with the type representation?

Well, T'Value would need two things: (1) to read from the stream, and (2) produce the proper value of the type. This might require knowing the representation, such as a set of flags modeled by an "Array(1..8) of Boolean" [with Size => 8] being packed into a single byte.

T'Image is related *only* in that it's supposed to be the inverse of T'Value.

> 
> > Stream attributes use a complex concept called "availability" to deal
> > with limited types, and they don't worry about privacy breakage at all.
> 
> Limited types should have no stream attributes at all. Same applied to 
> 'Image/'Value. Returning limited object was a language design bug. This 
> cannot be fixed but it can be contained.

I'm not sure about this. There's a good argument for it if you're (eg) modeling/interfacing into hardware... but there's argument against it if your purpose is merely controlling data. -- An example I could think of is some sort of keyed-index ownership-scheme where there's only one value of that particular type at a time, and some need for persistence across program runs. (Wherein the values are saved to disk in program-shutdown, and restored in program-start-up.)

> 
> > 'Value would need something similar at a minimum, and the question of
> > privacy breakage also would have to be addressed (a package would not want
> > some outside force constructing values for its types; they might not meet
> > the [implied] invariants and other assumptions
> 
> [...]
> 
> Safe default is to generate publicly visible 'Image and 'Value 
> propagating Use_Error for all types with private components. The package 
> provider could override them in the public part with bodies renaming the 
> private default implementations of which have full visibility.

Or, we could just let the attributes [functionally] act as callbacks, albeit statically rather than dynamically assigned. Thus you could invoke T'Image for anything w/ the attribute and have a good compile/run (even if the default provided by the compiler is USE_ERROR)... then add in an implementation, use "For T'Image Use ..." or " with Image => ..." (perhaps in the private section) and compile/run it w/o having altered the public/visible interfacing.

Re: Record operations (Algebraic Data Types and printing)

[Dmitry A. Kazakov]

On 2018-10-10 20:38, Shark8 wrote:
> On Wednesday, October 10, 2018 at 1:17:51 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2018-10-10 00:20, Randy Brukardt wrote:
>>> "Lucretia"  wrote in message
>>> news:fb2af9cb-5317-4f1c-867c-8876212d303b...
>>
>>>> Like what 'Read/'Write/'Input/'Output do, they call a defined subprogram in
>>>> the package. Surely, it's not that hard.
>>>
>>> What package? We're talking about (in part) the default representation for a
>>> type.
>>
>> What have T'Image and T'Value to do with the type representation?
> 
> Well, T'Value would need two things: (1) to read from the stream, and (2) produce the proper value of the type. This might require knowing the representation, such as a set of flags modeled by an "Array(1..8) of Boolean" [with Size => 8] being packed into a single byte.

Whatever way the implementation chooses. Full visibility of the type or 
some of its parts might be required or not required. The default 
implementation could respect visibility or ignore it.

>>> Stream attributes use a complex concept called "availability" to deal
>>> with limited types, and they don't worry about privacy breakage at all.
>>
>> Limited types should have no stream attributes at all. Same applied to
>> 'Image/'Value. Returning limited object was a language design bug. This
>> cannot be fixed but it can be contained.
> 
> I'm not sure about this. There's a good argument for it if you're (eg) modeling/interfacing into hardware... but there's argument against it if your purpose is merely controlling data. -- An example I could think of is some sort of keyed-index ownership-scheme where there's only one value of that particular type at a time, and some need for persistence across program runs. (Wherein the values are saved to disk in program-shutdown, and restored in program-start-up.)

The question is whether this behavior is safe to provide by default. The 
answer is no, most of the time it is unsafe and meaningless. The rest 
can be easily covered without using streaming attributes.

BTW, in practice they would not work anyway. I implemented what you 
described on several occasions. Each time I ended up with reading from 
the stream not the limited object but a handle to it instead. The 
handle's 'Read attribute read the object parts from the stream, 
allocated the new object, constructed it in place and then returned a 
handle to it.

Limited return+aggregates simply do not work when you have derived types 
and private parts.

>> Safe default is to generate publicly visible 'Image and 'Value
>> propagating Use_Error for all types with private components. The package
>> provider could override them in the public part with bodies renaming the
>> private default implementations of which have full visibility.
> 
> Or, we could just let the attributes [functionally] act as callbacks, albeit statically rather than dynamically assigned. Thus you could invoke T'Image for anything w/ the attribute and have a good compile/run (even if the default provided by the compiler is USE_ERROR)... then add in an implementation, use "For T'Image Use ..." or " with Image => ..." (perhaps in the private section) and compile/run it w/o having altered the public/visible interfacing.

Yes, this is how stream attributes were forced into the language. But 
the question was about what to do with default implementations without 
full visibility.

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

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ppk92s$4ht$1@gioia.aioe.org...
> On 2018-10-10 00:20, Randy Brukardt wrote:
>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>> news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...
>> What package? We're talking about (in part) the default representation 
>> for a
>> type.
>
> What have T'Image and T'Value to do with the type representation?

Sorry about the sloppy language, I was referring to the default Image string 
representation for a type.

The proposal for 'Image defines such a representation for all types (for a 
task, it is the task id and discriminants, for instance). It's not clear how 
to define 'Value usefully for such a representation (most likely it would 
not be).

In any case, it is a non-trivial problem, substantially harder than the 
matching problem for 'Image.

                                          Randy.

Re: Record operations (Algebraic Data Types and printing)

[Dmitry A. Kazakov]

On 2018-10-11 23:35, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ppk92s$4ht$1@gioia.aioe.org...
>> On 2018-10-10 00:20, Randy Brukardt wrote:
>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>> news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...
>>> What package? We're talking about (in part) the default representation
>>> for a
>>> type.
>>
>> What have T'Image and T'Value to do with the type representation?
> 
> Sorry about the sloppy language, I was referring to the default Image string
> representation for a type.
> 
> The proposal for 'Image defines such a representation for all types (for a
> task, it is the task id and discriminants, for instance). It's not clear how
> to define 'Value usefully for such a representation (most likely it would
> not be).
> 
> In any case, it is a non-trivial problem, substantially harder than the
> matching problem for 'Image.

Another difficult problem is to define rules how 'Image and 'Value of a 
composite type should use or not use 'Image and 'Value of the components 
and ancestors. Say Image of a component gets overridden. Does it have 
effect and when? Does it change the behavior later on or only newly 
compiled modules, only those where overriding is visible, directly? etc. 
I.e. is any call to Image is always "dispatching"?

This is why do not like all these language hacks. Image/Value must be an 
interface inherited, standard rules apply.

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

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ppphli$l29$1@gioia.aioe.org...
> On 2018-10-11 23:35, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:ppk92s$4ht$1@gioia.aioe.org...
>>> On 2018-10-10 00:20, Randy Brukardt wrote:
>>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>>> news:fb2af9cb-5317-4f1c-867c-8876212d303b@googlegroups.com...
>>>> What package? We're talking about (in part) the default representation
>>>> for a
>>>> type.
>>>
>>> What have T'Image and T'Value to do with the type representation?
>>
>> Sorry about the sloppy language, I was referring to the default Image 
>> string
>> representation for a type.
>>
>> The proposal for 'Image defines such a representation for all types (for 
>> a
>> task, it is the task id and discriminants, for instance). It's not clear 
>> how
>> to define 'Value usefully for such a representation (most likely it would
>> not be).
>>
>> In any case, it is a non-trivial problem, substantially harder than the
>> matching problem for 'Image.
>
> Another difficult problem is to define rules how 'Image and 'Value of a 
> composite type should use or not use 'Image and 'Value of the components 
> and ancestors. Say Image of a component gets overridden. Does it have 
> effect and when? Does it change the behavior later on or only newly 
> compiled modules, only those where overriding is visible, directly? etc. 
> I.e. is any call to Image is always "dispatching"?

Hardly difficult; it has to work like streaming and thus it always applies.

Perhaps you ought to take a look at AI12-0020-1. We eventually concluded 
that directly overriding 'Image was never going to work (for reasons like 
those you give above). So 'Image is now defined to be constructed out of a 
new stream-like attribute Put_Image. Like the stream attributes, the default 
implementation of these compose (for components, parent parts, etc.). (And 
for scalar types, it's defined to produce the results as expected for 
current Ada.)  We already have the needed rules for doing that, so it's 
relatively easy.

Presumably, 'Value will define a similar attribute Get_Image. The problem 
(as noted) is deciding what it should do by default for various limited and 
private types.

                                              Randy.

Re: Record operations (Algebraic Data Types and printing)

[Jeffrey R. Carter]

On 10/06/2018 07:38 AM, J-P. Rosen wrote:
> Le 05/10/2018 à 19:58, AdaMagica a écrit :
>> Do it yourself... There is no such default.
> Yet. There is a proposal for Ada 202X, see AI12-0020

Seems to me allowing 'Image by default for a private type is a violation of privacy.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Record operations (Algebraic Data Types and printing)

[Dmitry A. Kazakov]

On 2018-10-06 18:18, Jeffrey R. Carter wrote:
> On 10/06/2018 07:38 AM, J-P. Rosen wrote:
>> Le 05/10/2018 à 19:58, AdaMagica a écrit :
>>> Do it yourself... There is no such default.
>> Yet. There is a proposal for Ada 202X, see AI12-0020
> 
> Seems to me allowing 'Image by default for a private type is a violation 
> of privacy.

Why? If you don't see the type T you cannot use T'Image.

---------------
The problem with the proposal is same as with 'Image itself. It is a hack.

There simply should be an interface with a primitive operation to 
convert object into a string (Image) and another to construct the object 
from string (Value). You want string formatting? Inherit from the 
interface, that is. Clean, manifested, no distributed overhead, not a 
compiler vendor problem anymore. [All types must have interfaces, yes]

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

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:00285ebf-6ede-44da-848f-456930dc7475@googlegroups.com...
>Am Freitag, 5. Oktober 2018 19:46:32 UTC+2 schrieb Henrik Härkönen:
>
>> Now as I'm playing with the records, I'd like to print them out, just for
>> "debugging" purposes. Is there any convenient way to splash them out
>> in console? Some sort of default string representation? Seems that
>> 'Image attribute works only for scalar types.
>
>Do it yourself... There is no such default.
>
>A record may have private (even limited) components. What should a default 
>for these look like?

Well, AI12-0020-1 attempts to answer that question, so it can't be 
impossible. ;-) [Wait a day or two before looking at it, Steve B. just sent 
a new version that isn't posted yet.]

For the OP: Ada 2020 most likely will have a mechanism to do what you want. 
But you probably don't want to wait for that to show up in your favorite 
compiler. So you do in fact have to do it yourself.

                              Randy.

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

On Tuesday, 9 October 2018 02:03:28 UTC+3, Randy Brukardt  wrote:
> For the OP: Ada 2020 most likely will have a mechanism to do what you want. 
> But you probably don't want to wait for that to show up in your favorite 
> compiler. So you do in fact have to do it yourself.

Yeah, I'll do it by myself in the meanwhile. :) Exciting this new version though. 

And interestingly, what got me initially checking more about Ada, was this Wikipedia page about Dependent Types, where "Ada 202x" was listed to be supporting those: 

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

But I'm not sure did I see such things on the Ada 2020 development page, maybe I have to read those more thoroughly.

-Henrik

Re: Record operations (Algebraic Data Types and printing)

[Paul Rubin]

Henrik Härkönen <heharkon@gmail.com> writes:
> And interestingly, what got me initially checking more about Ada, was
> this Wikipedia page about Dependent Types, where "Ada 202x" was listed
> to be supporting those:
>
> https://en.wikipedia.org/wiki/Dependent_type

I don't think that can be right, in the sense in which that term is
normally used.  But, I think C++ uses it to mean something different, so
maybe Ada 202x does as well.

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

On Tuesday, 9 October 2018 10:32:12 UTC+3, Paul Rubin  wrote:
> Henrik Härkönen <heharkon@gmail.com> writes:
> > And interestingly, what got me initially checking more about Ada, was
> > this Wikipedia page about Dependent Types, where "Ada 202x" was listed
> > to be supporting those:
> >
> > https://en.wikipedia.org/wiki/Dependent_type
> 
> I don't think that can be right, in the sense in which that term is
> normally used.  But, I think C++ uses it to mean something different, so
> maybe Ada 202x does as well.

Maybe so, yes. Ada has other tools for provability etc. Maybe they go along with those lines.

Re: Record operations (Algebraic Data Types and printing)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87d0sj379h.fsf@nightsong.com...
> Henrik Härkönen <heharkon@gmail.com> writes:
>> And interestingly, what got me initially checking more about Ada, was
>> this Wikipedia page about Dependent Types, where "Ada 202x" was listed
>> to be supporting those:
>>
>> https://en.wikipedia.org/wiki/Dependent_type
>
> I don't think that can be right, in the sense in which that term is
> normally used.  But, I think C++ uses it to mean something different, so
> maybe Ada 202x does as well.

The Wikipedia article references "Subtype predicates" (and I would add "Type 
invariants" to that) to provide this capability. Which means the reference 
really should be to Ada 2012, since that is where those were introduced. It 
also references SPARK to get static proofs.

                                         Randy.

Re: Record operations (Algebraic Data Types and printing)

[Niklas Holsti]

On 18-10-05 20:46 , Henrik Härkönen wrote:
> Hi! (Very) Slowly getting my Ada wheels rolling, didn't get the book
> yet etc. but anyway...
>
> I'm coming from Scala world most recently and I like to leverage
> Algebraic Data Types (through sealed traits), or Discriminated
> Unions, as they were called in F#. I was happy to find out that Ada
> has Variant Record, which I believe pretty much covers the same
> thing. Maybe in a bit more verbose way. :) I'm somehow fascinated by
> the possibility to carry state as the type, thus with different data
> items for each state.
>
> Now as I'm playing with the records, I'd like to print them out, just
> for "debugging" purposes. Is there any convenient way to splash them
> out in console? Some sort of default string representation?

Nope, and too bad. That's something that would often be useful at the 
program development stage. But not so useful when the program is in 
production runs, for typical Ada applications.

One way to get something like this is to run the program under a 
debugger, and ask the debugger to display the record variable. Debuggers 
can usually show "component-name = value" pairs.

> Seems that 'Image attribute works only for scalar types.

Indeed.

I seem to remember seeing a posting here, a few years ago, offering a 
tool that would construct an Image function for a given record type. The 
tool was possibly based on ASIS, and possibly not. Sadly I did not find 
any links to this, but perhaps someone else has a better memory or 
better search methods.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

On Friday, 5 October 2018 21:32:59 UTC+3, Niklas Holsti  wrote:
> Nope, and too bad. That's something that would often be useful at the 
> program development stage. But not so useful when the program is in 
> production runs, for typical Ada applications.
> 
> One way to get something like this is to run the program under a 
> debugger, and ask the debugger to display the record variable. Debuggers 
> can usually show "component-name = value" pairs.

Yes, actually my second option was to look at the real debugger. It seems that GPS is nicely equipped with gdb interface and after adding the debug and symbol flags to the compilation, I can step on the debugger and hover with mouse cursor on the record instance to see the components and values. Very nice!

> I seem to remember seeing a posting here, a few years ago, offering a 
> tool that would construct an Image function for a given record type. The 
> tool was possibly based on ASIS, and possibly not. Sadly I did not find 
> any links to this, but perhaps someone else has a better memory or 
> better search methods.

That would be cool, but honestly, after using the debugger, the prints are just too much to bother with. :) Perhaps in plain text console environment that would play it's part, but now I think I'll just go with the debugger.

-Henrik

Re: Record operations (Algebraic Data Types and printing)

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> I seem to remember seeing a posting here, a few years ago, offering a
> tool that would construct an Image function for a given record
> type. The tool was possibly based on ASIS, and possibly not. Sadly I
> did not find any links to this, but perhaps someone else has a better
> memory or better search methods.

Auto_Text_IO in Stephe's Ada Library[1]: might need some fixups for
newer compilers/standards.

[1] http://stephe-leake.org/ada/sal.html

Re: Record operations (Algebraic Data Types and printing)

[Henrik Härkönen]

> Auto_Text_IO in Stephe's Ada Library[1]: might need some fixups for
> newer compilers/standards.
> 
> [1] http://stephe-leake.org/ada/sal.html

Alright, seems that there's other nice stuff too, thanks. :)

Re: Record operations (Algebraic Data Types and printing)

[Stephen Leake]

On Friday, October 5, 2018 at 11:17:39 PM UTC-7, Henrik Härkönen wrote:
> > Auto_Text_IO in Stephe's Ada Library[1]: might need some fixups for
> > newer compilers/standards.
> > 
> > [1] http://stephe-leake.org/ada/sal.html
> 
> Alright, seems that there's other nice stuff too, thanks. :)

That has some packages that were generated by or support auto_text_io, but not the actual auto_text_io code, which you need to generate a Text_IO package for your record types.

I stopped supporting the auto_text_io tool, mostly because ASIS was not ported to the newer language versions.

These days the best way to reimplement auto_text_io is to start with libadalang (https://github.com/AdaCore/libadalang). If anyone wants to try that, I can probably dig up the auto_text_io code.

-- Stephe

Re: Record operations (Algebraic Data Types and printing)

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> On Friday, October 5, 2018 at 11:17:39 PM UTC-7, Henrik Härkönen wrote:
>> > Auto_Text_IO in Stephe's Ada Library[1]: might need some fixups for
>> > newer compilers/standards.
>> > 
>> > [1] http://stephe-leake.org/ada/sal.html
>> 
>> Alright, seems that there's other nice stuff too, thanks. :)
>
> That has some packages that were generated by or support auto_text_io,
> but not the actual auto_text_io code, which you need to generate a
> Text_IO package for your record types.

Oh, sorry for misleading people.

> I stopped supporting the auto_text_io tool, mostly because ASIS was
> not ported to the newer language versions.

AdaCore's ASIS still works, their own implementation to deal with modern
language versions.

> These days the best way to reimplement auto_text_io is to start with
> libadalang (https://github.com/AdaCore/libadalang). If anyone wants to
> try that, I can probably dig up the auto_text_io code.

I find libadalang a bit distressing, mostly because of the extensive
reliance on external Python utilities: from REQUIREMENTS.dev,

Mako==1.0.1
PyYAML==3.11
Sphinx==1.3.1
coverage==3.7.1
enum==0.4.6
enum34==1.1.2
psutil==3.4.2
sphinx-rtd-theme==0.1.9
funcy==1.7.1
-e git+https://github.com/AdaCore/langkit.git#egg=langkit
docutils==0.12
autopep8==1.2.4
yapf==0.16.0

and Quex.

Of course, the libraries required for GPS make a long list too.

Also, there are also difficulties using the latest Github libadalang,
which relies on a recent libgpr (more recent than the one I included
with the macOS GCC 8.1.0, but OK with GNAT CE 2018).

I suppose I just have to man up, bite the bullet, ...

Re: Record operations (Algebraic Data Types and printing)

[briot.emmanuel]

> I find libadalang a bit distressing, mostly because of the extensive
> reliance on external Python utilities: from REQUIREMENTS.dev,

AdaCore just announced they would be packaging libadalang with
the compiler with the 19.1 pro release in February. So maybe also
with the GPL later this year (which, from memory, is based on the x.1
release). That will indeed make things easier, since indeed right now
everyone has to develop their own scripts to recompile all dependencies.

Re: Record operations (Algebraic Data Types and printing)

[Simon Wright]

briot.emmanuel@gmail.com writes:

>> I find libadalang a bit distressing, mostly because of the extensive
>> reliance on external Python utilities: from REQUIREMENTS.dev,
>
> AdaCore just announced they would be packaging libadalang with the
> compiler with the 19.1 pro release in February. So maybe also with the
> GPL later this year (which, from memory, is based on the x.1
> release). That will indeed make things easier, since indeed right now
> everyone has to develop their own scripts to recompile all
> dependencies.

I was being purist|picky|annoying really, having wanted to think of
AdaCore as an Ada shop.

That said, I pulled the latest libadalang.git: there are instructions in
README.md. It's easy enough to fetch and install all the Python parts.

It's not that it's difficult to build the compiled parts of libadalang,
which I guess you'd only do if you wanted to use the latest version from
Github for whatever reason; at which point you encounter the sort of
problem I found, where it uses a new interface in a library (turned out
to be libgpr in this case). OK, I was using FSF GCC 8.1.0.

May I say at this point how very much I agree with Randy about not using
'use' if at all possible! If an interface isn't present in your version
of a library then no amount of searching in GPS/Emacs via your project
file is going to find where it ought to be.

GNAT CE 2018 includes libadalang; not sure what scripts are included.

Maybe I should consider (for my Mac friends) a GCC 8.2 release including
libadalang!

Re: Record operations (Algebraic Data Types and printing)

[Bill Findlay]

Simon Wright <simon@pushface.org> wrote:

> Maybe I should consider (for my Mac friends) a GCC 8.2 release including
> libadalang!

As I hope I fall into that category 8-), 
please excuse my ignorance.
What does libadalang do for me?

-- 
Bill Findlay

Re: Record operations (Algebraic Data Types and printing)

[Simon Wright]

Bill Findlay <findlaybill@blueyonder.co.uk > writes:

> Simon Wright <simon@pushface.org> wrote:
>
>> Maybe I should consider (for my Mac friends) a GCC 8.2 release including
>> libadalang!
>
> As I hope I fall into that category 8-), 
> please excuse my ignorance.
> What does libadalang do for me?

Hi Bill!

From the README.md (https://github.com/AdaCore/libadalang):

--------------------------------

Libadalang is a project to build a high performance semantic engine for
the Ada programming language. It is meant to provide a basis to write
Ada tooling, including tools working on potentially changing and
incorrect code, such as IDEs. Its goals encompass, but are not limited
to:

* Full support for parsing the Ada 2012 syntax, plus SPARK extensions.

* Error tolerant parsing: the parser must be able to recover from simple
  errors and provide a "best-guess" tree.

* Error tolerant semantic analysis: it must be possible to create a tool
  that works only on syntax, and completely ignores semantic issues.

* Full symbol resolution respecting Ada 2012 – and prior Ada versions –
  semantics.

* Bindings to a variety of languages, including Ada, C, Python and Java,
  so that tools can be written from various ecosystems.

* Incremental processing of source files.

--------------------------------

[...] there are a few reasons you might eventually choose to use
Libadalang instead of ASIS:

1. The ASIS standard has not yet been updated to the 2012 version of
   Ada. More generally, the advantages derived from ASIS being a
   standard also means that it will evolve very slowly.

2. Syntax only tools will derive a lot of advantages on being based on
   Libadalang:

   * Libadalang will be completely tolerant to semantic errors. For
     example, a pretty-printer based on Libadalang will work whether
     your code is semantically correct or not, as long as it is
     syntactically correct.

   * Provided you only need syntax, Libadalang will be much faster than
     ASIS' main implementation (AdaCore's ASIS), because ASIS always
     does complete analysis of the input Ada code.

3. The design of Libadalang's semantic analysis is lazy. It will only
   process semantic information on-demand, for specific portions of the
   code. It means that you can get up-to-date information for a correct
   portion of the code even if the file contains semantic errors.

4. Libadalang has bindings to C and Python, and its design makes it easy
   to bind to new languages.

5. Libadalang is suitable to write tools that work on code that is
   evolving dynamically. It can process code and changes to code
   incrementally. Thus, it is suitable as an engine for an IDE, unlike
   AdaCore's ASIS implementation.

6. Libadalang is not tied to a particular compiler version. This
   combined with its staged and error tolerant design means that you can
   use it to detect bugs in Ada compilers/tools.

--------------------------------

HTH!

Re: Record operations (Algebraic Data Types and printing)

[Bill Findlay]

On 8 Oct 2018, Simon Wright wrote
(in article <lyk1msts7i.fsf@pushface.org>):

> Bill Findlay<findlaybill@blueyonder.co.uk >  writes:
>
> > Simon Wright <simon@pushface.org> wrote:
> >
> > > Maybe I should consider (for my Mac friends) a GCC 8.2 release including
> > > libadalang!
> >
> > As I hope I fall into that category 8-),
> > please excuse my ignorance.
> > What does libadalang do for me?
>
> Hi Bill!
>
> From the README.md (https://github.com/AdaCore/libadalang):

...

Many thanks.

-- 
Bill Findlay