[Info-vax] DCL's flaws (both scripting and UI)

[Bob Gezelter]

On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
> On 2015-01-19, Craig A. Berry <craigberry at nospam.mac.com> wrote:
> >
> > New data types and automatic data conversions would be difficult to do
> > compatibly, but if the new types were all objects and there were a
> > distinct object notation, it might be possible to eliminate any ambiguities.
> >
> 
> I'm not seeing that as a real problem.
> 
> For example, if the lexicals start returning objects containing a set
> of items instead of individual items as is currently done with the
> lexicals, there's no reason why the new lexicals could not be placed in
> their own package and referenced as such.
> 
> The fact the new lexicals will be returning entire objects instead of
> individual strings means the calling sequence is going to change anyway.
> 
> For example, consider f$parse().
> 
> You would keep f$parse for compatibility with existing DCL code and
> it would continue to return individual strings, but you could also
> have a (say) sys package with a differently named f$parse returning an
> object containing all the parsed fields in one go.
> 
> For example:
> 
> $ ! Old way
> $	oname = f$parse(fname, , ,"NAME")
> $	odir  = f$parse(fname, , ,"DIRECTORY")
> $	otype = f$parse(fname, , ,"TYPE")
> $	write sys$output "name = ", oname, " dir = ", odir, " type = ", otype
> $
> $ ! New way
> $	oparse = sys.o$parse(fname)
> $	write sys$output "name = ", oparse.name, " dir = ",oparse.dir, -
> 		" type = ", oparse.type
> 
> oparse would have a type of object (and a specific type of object).
> However the variables within the oparse object would be of type string
> and could be used as normal.
> 
> Furthermore, one could move objects around by assigning them to other
> variables and the new variable would take on the type of the object
> just as happens at the moment when a variable which was originally an
> integer has a string assigned to it.
> 
> The above behaviour is totally compatible with existing DCL code and
> you can mix-and-match old style and new style code in the same command
> procedure.
> 
> In the above example, there's no reason why you could not say
> 
> $	if oname .nes. oparse.name
> $		then
> $ ! Do something
> $	endif
> 
> as you would be comparing two string variables. The fact one of them
> is contained within an object simply does not matter.
> 
> You may not be able to use string/integer operator names within objects
> in order to avoid ambiguity when parsing multi-level objects, but apart
> from that, I don't see any problem with the above approach.
> 
> It would also be nice to be able to write something like:
> 
> $	queue_list = sys.o$getqui(<whatever>)
> $	for queue in queue_list
> $		write sys$output "queue_name = ", queue.name
> $	end for
> 
> That's a _lot_ cleaner than the current mess which is f$getqui()
> especially when you start working on the entries within those queues
> as well.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Gentlemen,

Actually, I would rather NOT debate a new or better language. Instead, I would be looking towards documenting and cleaning up the interface between the command line interpreter (CLI) and base system. I suspect that the last thing needed is yet another scripting language.

Cleaning up the interface might provide a better option than a particular language.

There are many languages for which immediate execution modes exist or can be developed (e.g., JavaScript, Python, Ruby, BASIC). The LIB$ routines already underlie the lexical functions. Cleaning up/documenting the CLI interface would allow other languages to be used as CLIs.

The distinction between scripting and programming languages has long since become a distinction without a difference.

- Bob Gezelter, http://www.rlgsc.com