From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,80b3e504140e89fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-29 05:23:37 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp4.savvis.net!uunet!dfw.uu.net!an02.austin.ibm.com!geraldo.cc.utexas.edu!not-for-mail From: "Bobby D. Bryant" Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal {long} Date: Sat, 29 Jun 2002 06:17:21 -0600 Organization: dis- Message-ID: References: NNTP-Posting-Host: dial-27-4.ots.utexas.edu Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: geraldo.cc.utexas.edu 1025353053 11662 128.83.128.196 (29 Jun 2002 12:17:33 GMT) X-Complaints-To: abuse@utexas.edu NNTP-Posting-Date: Sat, 29 Jun 2002 12:17:33 +0000 (UTC) User-Agent: Pan/0.11.3 (Unix) X-Comment-To: "Bobby D. Bryant" Xref: archiver1.google.com comp.lang.ada:26790 Date: 2002-06-29T06:17:21-06:00 List-Id: On Sat, 29 Jun 2002 05:03:17 -0600, Bobby D. Bryant wrote: > Finally, if I may say so without stepping on any toes, I would > like to call attention to the curiously "flat" examples that you > have for the Java and XML sections on your Web page, and the > emphasis on data types rather than on semantics. After taking my morning walk I think I can elaborate on this usefully. First, regarding the "flatness" of some of the examples. Notice that the apparent depth of the Java and XML examples arises from the fact that you have given the path names through the Ada package hierarchy to the Ada type definitions as "structure" in the config file. But if you replaced those path names with aliases and then used those aliases in your config file, it would immediately become apparent that in those two examples the data is just a flat list of {type, name, value} tuples (with a huge pile of useless syntax thrown in for the XML implementation, to boot). Compare that to the X example, where the nesting in the config file actually represents some structure in the data. Sure, you *could* represent the X data as a flat list, but presumably it is intended to be isomorphic to some nested data structure that has nested meaning in the actual program. In fact Ada will let you nest record structures to an (ideally) unbounded depth, and in practice I do find myself going several layers deep from time to time. And for ease of comprehension I think it important to represent nested structures as nested structures in the config file. Accordingly, please consider changing - "15. At least one layer of key hierarchy is supported." with - "15. At unbounded depth of key hierarchy is supported." Also, if you want people to look at the examples on your Web page to help them decide which syntactic system is best for the job, then I would think that the following would be absolutely essential - (a) Level the playing field: Each example needs to specify identical data. (b) Raise the bar: For the examples, use the most demanding example rather than a simpler one. (Solicit to see what people feel that config files must support, and use that feedback to construct a 'wicked' example.) I suspect you will find that if you level the playing field and raise the bar, some suggested syntaxes will rule themselves out immediately. Also, by working with a 'wicked' example you can ensure that we're not here revisiting the syntax question again in 2-3 years when people discover that the standard only supports the most rudimentary data representation problems and does not actually meet the requirements of complex programs. Notice that I'm not commenting on the specification of data types in the config file. If that's necessary or desirable then it should be done, but it should be an "also" added to the structured representation of structured data, not an "instead of". The key, IMO, is to get the representation of the structured data right, after which type-tagging should be a relatively minor detail. When I say "structured data" I mean, minimally, support for records, iterative structures (arrays or lists, possibly with identical representation in the config file), 2-D tables, etc., including unbounded nesting of structures. later, Bobby Bryant Austin, Texas p.s. - Wandering yet farther from my main point... For arrays it would be nice if the API had a function call that would let your proram peek to see how long an array was in the config file, so that you could peek, allocate the array, and then load it, with two calls to the API and a "new" statement in between. For lists, there needs to be some mechanism for easily saying "OK, now give me the next one."