Re: [Plplot-devel] Ada bindings: user no longer needs to incorporate the thin binding On Jul 3, 2007, at 7:51 AM, Alan W. Irwin wrote: On 2007-07-03 07:11-0700 Alan W. Irwin wrote: Added two new files to the bindings directory, plplot_auxiliary.adb and plplot_auxiliary.ads. This was necessary in order to make the PLplot_Thin bindings disappear to the user. These files contain a few basic declarations used by all of the bindings (which were formerly exported by PLplot_Thin) and some utility procedures used by several of the examples. Hi Jerry: I committed your Ada patch. After committing your patch I tried one further local change; removing all references to PLplot_Auxiliary from the examples because both the thick and traditional examples refer to Ada interfaces which in turn refer to PLplot_Auxiliary. However, that lead to the following type of error for both thick and traditional examples for both example 1 and example 12 (example 10 is so simplistic it doe sn't run into the problem): xthick01a.dir/xthick01a.o xthick01a.adb:39:14: "Real_Vector" is not visible (more references follow) xthick01a.adb:39:14: non-visible declaration at plplot_auxiliary.ads:26 xthick01a.adb:39:26: incorrect constraint for this kind of type xthick01a.adb:43:11: "String_80" is not visible xthick01a.adb:43:11: non-visible declaration at plplot_auxiliary.ads:68 I presume with the appropriate namespace commands in plplot_traditional.ad[bs] and plplot.ad[bs] all the PLplot_Auxiliary definitions (e.g., String_80, etc.) could be made visible to the examples without having to explicitly mention PLplot_Auxiliary in the examples. In sum, there should be no fundamental need to mention PLplot_Auxiliary in the examples but this appears to be currently required because of namespace issues. Getting such namespace concerns properly dealt with is always a bit of a struggle in any given language, but I hope you are able to figure this out for Ada with help from your Ada contacts/references. Alan Ada does not propagate the "with" clause as you discovered. I've worked in languages where this happens or can be optionally turned on. It seems that, as with most convenience features in programming, it comes back to bite you and ends up being more of a burden than a convenience. I gather that the designers of Ada knew this and also decided, in the Ada spirit of readability, that propagating "with" was obfuscating, and indeed it is nice to be able to look at any package and see all of the other packages that it uses, without having to backchain through source files to discover them all. I don't know how to overcome the specific problem that you mention, and I tried to do it. The utility functions can be put into the bindings but that would be sort of polluting the bindings since I included them only for convenience in writing the examples. The C and Fortran examples, I notice, include these functions in the example files themselves--I was j ust trying to save effort. I would do so, but that still leaves the 2-4 declarations that are used by all of the bindings. These were previously part of the thin binding and with-ed by the thick and traditional bindings, and that with-ing went away at the decision to make the thin binding more or less invisible. They can't be put directly into the thick and traditional binding because the thin binding needs them also. (I don't think Ada lets two packages both "with" each other, but that might have changed with Ada 2005. However, I don't want to require Ada 2005 to run these bindings, as that would cut the user base to approximately zero. The actual standard was just settled in 2007 and so it should be called Ada 2007 (and sometimes is).) I should note that in Ada, a type declaration in one package that is declared exactly the same in another package are actually different types. The main thing that all three bindings need is Real_Vector and Real_Matrix which are supplied b y Ada 2005 but not otherwise. That is why I've put in some comments indicating that certain lines (1 or 2 in maybe 5 files) can be commented out or in depending on whether the compiler supplies these types. What bothers me the most about this is that the user may well have a suitable type declaration in his calling program and would appreciate the types declared in PLplot_Auxiliary getting out of the way. I'll scratch my head on this a bit more and maybe ask the gurus at comp.lang.ada. Jerry


Thread view