1

Although programming using the CLI$ routines is not very hard, it would be nice if there were a code generator for the basic stuff based on the CLD file. Does anyone have something like that, or is there anyone interested in it?

Peter Hofman
  • 673
  • 4
  • 17
  • What kind of code would you want generated? Something that saves you the trouble of asking for parameters by inflicting them through an AST? – HABO Jan 19 '12 at 15:35
  • I don't quite get what you mean. From the CLD you can derive what parameters you can ask for. The idea is to generate code from the CLD to save you the trouble of coding the whole getting/storing the parameters/qualifiers. If you have a large CLD, it can be a boring job. – Peter Hofman Jan 25 '12 at 12:24
  • 1
    It's been a few years, but I don't recall it being a challenge after sorting things out the first time. Using CLI$DISPATCH to get to the right handler and then picking up the appropriate parameters and qualifiers is rather tidy. To some extent it depends on the complexity of your language, e.g. positional qualifiers. Depending on the programming language you're using, you might be able to use some clever tricks like enumerated types that provide a list of parameter and qualifier names: P_InputFile, Q_Delete, P_OutputFile, Q_Full, Q_Xref, ... . – HABO Jan 25 '12 at 13:23
  • I got the idea when I was going through some old code I am maintaining, written by people who had no clue what they were doing on OpenVMS, which resulted in a tool set for binding command line parameters to routines for parsing and so on. I would rather use CLI$, but since there are too many of those I rather generate most of the code for obtaining the values from the command line. Rewriting the command difinitions in CLD files will not be the biggest problem. – Peter Hofman Feb 01 '12 at 08:54
  • `CLI$DISPATCH` handles getting from verbs in the CLD to routines in the application. Each routine need only call `CLI$GET_VALUE` to pick up the expected parameters and qualifiers. `CLI$DCL_PARSE` and `LIB$GET_INPUT`, with an optional `LIB$GET_FOREIGN` (IIRC), handle the rest. Most of the heavy lifting as to what is required or optional should have been handled by the DCL parser, as well as handling oddities like `/SINCE=YESTERDAY`. You can make table-driven routines or use other tricks, but sooner or later the code needs to do something with the commands. – HABO Feb 01 '12 at 13:59
  • I use the routines mentioned, but I would like generating code for getting the actual data, and empty routines for additional actions. Of course, I don't need it very badly, but I just do not like doing similar things over and over again for each application. Just me being a lazy developer. – Peter Hofman Feb 13 '12 at 11:47
  • Are you only using a very small subset of the functionality available in CLDs? A full parser and code generator that appreciates all of the subtleties of qualifier placement and varied syntaxes based on parameter values is a bit of work. If you only use verbs and parameters, it is a more approachable problem. – HABO Feb 13 '12 at 15:22
  • I use verb, parameters, qualifiers and list qualifiers with values. My CLDs are very restrictive. Whenever I do not feel like implementing handling of negation of qualifiers, I add nonnegatable. I also often use disallow to further restrict the combination of parameters and qualifiers. – Peter Hofman Feb 14 '12 at 07:14

2 Answers2

1

There is a code generator of sorts at http://www.tomwade.eu/software/vmsarg.html

This is designed for when you're porting a C program onto VMS that is set up to use the typical terse and unfriendly qualifiers like

$ mumble -f -l foo.txt

that Unix loves. It generates code that allows the program to accept

$ mumble /fast /log=foo.txt

and translates it into the hieroglyphics that the program expects. Add CLD like functionality to the program with minimal C coding.

menjaraz
  • 7,551
  • 4
  • 41
  • 81
Tom Wade
  • 11
  • 1
0

It sounds like you have used enough of the features of CLDs that it would be a project to write a TECO macro to massage the CLD into the corresponding MUMPS code. (Sorry, wrong language?) Even LIB$TPARSE, or its Alpha replacement, would take some time to wrangle. Sounds like you have a "boring job" ahead of you, or a co-op. (Named for the sound it makes when it hits the wall.) Or find a YACC guru or someone with facility at various other parsing tools and turn them loose.

HABO
  • 15,314
  • 5
  • 39
  • 57
  • D'oh! That was intended to be another comment, not an answer. Sorry about that. – HABO Feb 15 '12 at 20:55
  • no problems. MUMPS? Does not ring a bell. Never used TECO. Anyway, thanks for all comments. Even though there is no real answer, I think this question should be closed. I have enough leads, and looking at the number of participants, it seems there is no real need for this kind of code generation. Maybe when I have my AlphaStation at home set up with OpenVMS 8.3 or 8.4, and when I find the time, I might have a go at it. In that case it will be an open source project, of course with a permissive license like Apache 2.0, MIT or BSD. – Peter Hofman Feb 20 '12 at 13:34