* Record operations (Algebraic Data Types and printing) @ 2018-10-05 17:46 Henrik Härkönen 2018-10-05 17:58 ` AdaMagica 2018-10-05 18:32 ` Niklas Holsti 0 siblings, 2 replies; 43+ messages in thread From: Henrik Härkönen @ 2018-10-05 17:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 17:46 Record operations (Algebraic Data Types and printing) Henrik Härkönen @ 2018-10-05 17:58 ` AdaMagica 2018-10-05 18:11 ` Henrik Härkönen ` (2 more replies) 2018-10-05 18:32 ` Niklas Holsti 1 sibling, 3 replies; 43+ messages in thread From: AdaMagica @ 2018-10-05 17:58 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 17:58 ` AdaMagica @ 2018-10-05 18:11 ` Henrik Härkönen 2018-10-05 18:46 ` Niklas Holsti 2018-10-06 5:38 ` J-P. Rosen 2018-10-08 23:03 ` Randy Brukardt 2 siblings, 1 reply; 43+ messages in thread From: Henrik Härkönen @ 2018-10-05 18:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 18:11 ` Henrik Härkönen @ 2018-10-05 18:46 ` Niklas Holsti 2018-10-05 20:33 ` Henrik Härkönen 0 siblings, 1 reply; 43+ messages in thread From: Niklas Holsti @ 2018-10-05 18:46 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 18:46 ` Niklas Holsti @ 2018-10-05 20:33 ` Henrik Härkönen 0 siblings, 0 replies; 43+ messages in thread From: Henrik Härkönen @ 2018-10-05 20:33 UTC (permalink / raw) > 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. :) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 17:58 ` AdaMagica 2018-10-05 18:11 ` Henrik Härkönen @ 2018-10-06 5:38 ` J-P. Rosen 2018-10-06 7:08 ` Henrik Härkönen 2018-10-06 16:18 ` Jeffrey R. Carter 2018-10-08 23:03 ` Randy Brukardt 2 siblings, 2 replies; 43+ messages in thread From: J-P. Rosen @ 2018-10-06 5:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 5:38 ` J-P. Rosen @ 2018-10-06 7:08 ` Henrik Härkönen 2018-10-06 16:42 ` Lucretia 2018-10-06 16:18 ` Jeffrey R. Carter 1 sibling, 1 reply; 43+ messages in thread From: Henrik Härkönen @ 2018-10-06 7:08 UTC (permalink / raw) 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! :) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 7:08 ` Henrik Härkönen @ 2018-10-06 16:42 ` Lucretia 2018-10-08 23:08 ` Randy Brukardt 0 siblings, 1 reply; 43+ messages in thread From: Lucretia @ 2018-10-06 16:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 16:42 ` Lucretia @ 2018-10-08 23:08 ` Randy Brukardt 2018-10-09 1:12 ` Lucretia 0 siblings, 1 reply; 43+ messages in thread From: Randy Brukardt @ 2018-10-08 23:08 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 23:08 ` Randy Brukardt @ 2018-10-09 1:12 ` Lucretia 2018-10-09 22:20 ` Randy Brukardt 0 siblings, 1 reply; 43+ messages in thread From: Lucretia @ 2018-10-09 1:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-09 1:12 ` Lucretia @ 2018-10-09 22:20 ` Randy Brukardt 2018-10-10 7:17 ` Dmitry A. Kazakov 0 siblings, 1 reply; 43+ messages in thread From: Randy Brukardt @ 2018-10-09 22:20 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-09 22:20 ` Randy Brukardt @ 2018-10-10 7:17 ` Dmitry A. Kazakov 2018-10-10 18:13 ` G. B. ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Dmitry A. Kazakov @ 2018-10-10 7:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 7:17 ` Dmitry A. Kazakov @ 2018-10-10 18:13 ` G. B. 2018-10-10 18:36 ` Dmitry A. Kazakov ` (2 more replies) 2018-10-10 18:38 ` Shark8 2018-10-11 21:35 ` Randy Brukardt 2 siblings, 3 replies; 43+ messages in thread From: G. B. @ 2018-10-10 18:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 18:13 ` G. B. @ 2018-10-10 18:36 ` Dmitry A. Kazakov 2018-10-11 11:29 ` Björn Lundin 2018-10-11 21:32 ` Randy Brukardt 2 siblings, 0 replies; 43+ messages in thread From: Dmitry A. Kazakov @ 2018-10-10 18:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 18:13 ` G. B. 2018-10-10 18:36 ` Dmitry A. Kazakov @ 2018-10-11 11:29 ` Björn Lundin 2018-10-11 14:45 ` Jacob Sparre Andersen 2018-10-12 19:08 ` G. B. 2018-10-11 21:32 ` Randy Brukardt 2 siblings, 2 replies; 43+ messages in thread From: Björn Lundin @ 2018-10-11 11:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-11 11:29 ` Björn Lundin @ 2018-10-11 14:45 ` Jacob Sparre Andersen 2018-10-11 18:34 ` Björn Lundin 2018-10-12 19:08 ` G. B. 1 sibling, 1 reply; 43+ messages in thread From: Jacob Sparre Andersen @ 2018-10-11 14:45 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-11 14:45 ` Jacob Sparre Andersen @ 2018-10-11 18:34 ` Björn Lundin 0 siblings, 0 replies; 43+ messages in thread From: Björn Lundin @ 2018-10-11 18:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-11 11:29 ` Björn Lundin 2018-10-11 14:45 ` Jacob Sparre Andersen @ 2018-10-12 19:08 ` G. B. 2018-10-12 19:20 ` Randy Brukardt 1 sibling, 1 reply; 43+ messages in thread From: G. B. @ 2018-10-12 19:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-12 19:08 ` G. B. @ 2018-10-12 19:20 ` Randy Brukardt 0 siblings, 0 replies; 43+ messages in thread From: Randy Brukardt @ 2018-10-12 19:20 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 18:13 ` G. B. 2018-10-10 18:36 ` Dmitry A. Kazakov 2018-10-11 11:29 ` Björn Lundin @ 2018-10-11 21:32 ` Randy Brukardt 2 siblings, 0 replies; 43+ messages in thread From: Randy Brukardt @ 2018-10-11 21:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 7:17 ` Dmitry A. Kazakov 2018-10-10 18:13 ` G. B. @ 2018-10-10 18:38 ` Shark8 2018-10-11 8:36 ` Dmitry A. Kazakov 2018-10-11 21:35 ` Randy Brukardt 2 siblings, 1 reply; 43+ messages in thread From: Shark8 @ 2018-10-10 18:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 18:38 ` Shark8 @ 2018-10-11 8:36 ` Dmitry A. Kazakov 0 siblings, 0 replies; 43+ messages in thread From: Dmitry A. Kazakov @ 2018-10-11 8:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-10 7:17 ` Dmitry A. Kazakov 2018-10-10 18:13 ` G. B. 2018-10-10 18:38 ` Shark8 @ 2018-10-11 21:35 ` Randy Brukardt 2018-10-12 7:14 ` Dmitry A. Kazakov 2 siblings, 1 reply; 43+ messages in thread From: Randy Brukardt @ 2018-10-11 21:35 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-11 21:35 ` Randy Brukardt @ 2018-10-12 7:14 ` Dmitry A. Kazakov 2018-10-12 19:16 ` Randy Brukardt 0 siblings, 1 reply; 43+ messages in thread From: Dmitry A. Kazakov @ 2018-10-12 7:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-12 7:14 ` Dmitry A. Kazakov @ 2018-10-12 19:16 ` Randy Brukardt 0 siblings, 0 replies; 43+ messages in thread From: Randy Brukardt @ 2018-10-12 19:16 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 5:38 ` J-P. Rosen 2018-10-06 7:08 ` Henrik Härkönen @ 2018-10-06 16:18 ` Jeffrey R. Carter 2018-10-06 17:19 ` Dmitry A. Kazakov 1 sibling, 1 reply; 43+ messages in thread From: Jeffrey R. Carter @ 2018-10-06 16:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 16:18 ` Jeffrey R. Carter @ 2018-10-06 17:19 ` Dmitry A. Kazakov 0 siblings, 0 replies; 43+ messages in thread From: Dmitry A. Kazakov @ 2018-10-06 17:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 17:58 ` AdaMagica 2018-10-05 18:11 ` Henrik Härkönen 2018-10-06 5:38 ` J-P. Rosen @ 2018-10-08 23:03 ` Randy Brukardt 2018-10-09 6:22 ` Henrik Härkönen 2 siblings, 1 reply; 43+ messages in thread From: Randy Brukardt @ 2018-10-08 23:03 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 23:03 ` Randy Brukardt @ 2018-10-09 6:22 ` Henrik Härkönen 2018-10-09 7:32 ` Paul Rubin 0 siblings, 1 reply; 43+ messages in thread From: Henrik Härkönen @ 2018-10-09 6:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-09 6:22 ` Henrik Härkönen @ 2018-10-09 7:32 ` Paul Rubin 2018-10-09 7:38 ` Henrik Härkönen 2018-10-09 22:25 ` Randy Brukardt 0 siblings, 2 replies; 43+ messages in thread From: Paul Rubin @ 2018-10-09 7:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-09 7:32 ` Paul Rubin @ 2018-10-09 7:38 ` Henrik Härkönen 2018-10-09 22:25 ` Randy Brukardt 1 sibling, 0 replies; 43+ messages in thread From: Henrik Härkönen @ 2018-10-09 7:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-09 7:32 ` Paul Rubin 2018-10-09 7:38 ` Henrik Härkönen @ 2018-10-09 22:25 ` Randy Brukardt 1 sibling, 0 replies; 43+ messages in thread From: Randy Brukardt @ 2018-10-09 22:25 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 17:46 Record operations (Algebraic Data Types and printing) Henrik Härkönen 2018-10-05 17:58 ` AdaMagica @ 2018-10-05 18:32 ` Niklas Holsti 2018-10-05 18:43 ` Henrik Härkönen 2018-10-05 19:41 ` Simon Wright 1 sibling, 2 replies; 43+ messages in thread From: Niklas Holsti @ 2018-10-05 18:32 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 18:32 ` Niklas Holsti @ 2018-10-05 18:43 ` Henrik Härkönen 2018-10-05 19:41 ` Simon Wright 1 sibling, 0 replies; 43+ messages in thread From: Henrik Härkönen @ 2018-10-05 18:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 18:32 ` Niklas Holsti 2018-10-05 18:43 ` Henrik Härkönen @ 2018-10-05 19:41 ` Simon Wright 2018-10-06 6:17 ` Henrik Härkönen 1 sibling, 1 reply; 43+ messages in thread From: Simon Wright @ 2018-10-05 19:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-05 19:41 ` Simon Wright @ 2018-10-06 6:17 ` Henrik Härkönen 2018-10-06 16:04 ` Stephen Leake 0 siblings, 1 reply; 43+ messages in thread From: Henrik Härkönen @ 2018-10-06 6:17 UTC (permalink / raw) > 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. :) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 6:17 ` Henrik Härkönen @ 2018-10-06 16:04 ` Stephen Leake 2018-10-06 16:56 ` Simon Wright 0 siblings, 1 reply; 43+ messages in thread From: Stephen Leake @ 2018-10-06 16:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 16:04 ` Stephen Leake @ 2018-10-06 16:56 ` Simon Wright 2018-10-08 6:44 ` briot.emmanuel 0 siblings, 1 reply; 43+ messages in thread From: Simon Wright @ 2018-10-06 16:56 UTC (permalink / raw) 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, ... ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-06 16:56 ` Simon Wright @ 2018-10-08 6:44 ` briot.emmanuel 2018-10-08 14:09 ` Simon Wright 0 siblings, 1 reply; 43+ messages in thread From: briot.emmanuel @ 2018-10-08 6:44 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 6:44 ` briot.emmanuel @ 2018-10-08 14:09 ` Simon Wright 2018-10-08 14:21 ` Bill Findlay 0 siblings, 1 reply; 43+ messages in thread From: Simon Wright @ 2018-10-08 14:09 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 14:09 ` Simon Wright @ 2018-10-08 14:21 ` Bill Findlay 2018-10-08 14:42 ` Simon Wright 0 siblings, 1 reply; 43+ messages in thread From: Bill Findlay @ 2018-10-08 14:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 14:21 ` Bill Findlay @ 2018-10-08 14:42 ` Simon Wright 2018-10-08 16:46 ` Bill Findlay 0 siblings, 1 reply; 43+ messages in thread From: Simon Wright @ 2018-10-08 14:42 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Record operations (Algebraic Data Types and printing) 2018-10-08 14:42 ` Simon Wright @ 2018-10-08 16:46 ` Bill Findlay 0 siblings, 0 replies; 43+ messages in thread From: Bill Findlay @ 2018-10-08 16:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2018-10-12 19:20 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-05 17:46 Record operations (Algebraic Data Types and printing) Henrik Härkönen 2018-10-05 17:58 ` AdaMagica 2018-10-05 18:11 ` Henrik Härkönen 2018-10-05 18:46 ` Niklas Holsti 2018-10-05 20:33 ` Henrik Härkönen 2018-10-06 5:38 ` J-P. Rosen 2018-10-06 7:08 ` Henrik Härkönen 2018-10-06 16:42 ` Lucretia 2018-10-08 23:08 ` Randy Brukardt 2018-10-09 1:12 ` Lucretia 2018-10-09 22:20 ` Randy Brukardt 2018-10-10 7:17 ` Dmitry A. Kazakov 2018-10-10 18:13 ` G. B. 2018-10-10 18:36 ` Dmitry A. Kazakov 2018-10-11 11:29 ` Björn Lundin 2018-10-11 14:45 ` Jacob Sparre Andersen 2018-10-11 18:34 ` Björn Lundin 2018-10-12 19:08 ` G. B. 2018-10-12 19:20 ` Randy Brukardt 2018-10-11 21:32 ` Randy Brukardt 2018-10-10 18:38 ` Shark8 2018-10-11 8:36 ` Dmitry A. Kazakov 2018-10-11 21:35 ` Randy Brukardt 2018-10-12 7:14 ` Dmitry A. Kazakov 2018-10-12 19:16 ` Randy Brukardt 2018-10-06 16:18 ` Jeffrey R. Carter 2018-10-06 17:19 ` Dmitry A. Kazakov 2018-10-08 23:03 ` Randy Brukardt 2018-10-09 6:22 ` Henrik Härkönen 2018-10-09 7:32 ` Paul Rubin 2018-10-09 7:38 ` Henrik Härkönen 2018-10-09 22:25 ` Randy Brukardt 2018-10-05 18:32 ` Niklas Holsti 2018-10-05 18:43 ` Henrik Härkönen 2018-10-05 19:41 ` Simon Wright 2018-10-06 6:17 ` Henrik Härkönen 2018-10-06 16:04 ` Stephen Leake 2018-10-06 16:56 ` Simon Wright 2018-10-08 6:44 ` briot.emmanuel 2018-10-08 14:09 ` Simon Wright 2018-10-08 14:21 ` Bill Findlay 2018-10-08 14:42 ` Simon Wright 2018-10-08 16:46 ` Bill Findlay
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox