T.R | Title | User | Personal Name | Date | Lines |
---|
212.1 | One other thing... | ULTRA::WRAY | John Wray | Sun Nov 20 1988 21:08 | 5 |
| Oh, I forgot a major requirement:
Automatic storage reclamation (garbage-collection).
John
|
212.2 | LISP comes close | SAUTER::SAUTER | John Sauter | Mon Nov 21 1988 15:58 | 2 |
| Except for strong typeing I think VAX LISP does what you want.
John Sauter
|
212.3 | ADA | GENRAL::HEINTZE | | Mon Dec 05 1988 11:12 | 4 |
| VAX Ada comes close. Some claim that you cannot pass the address
of a routine as a parameter in ADA. This is not true. The problem occurs
when you want to call the routine however. This can be done with
lib$callg - or your own home grown version of lib$callg.
|
212.4 | Oh well... | ULTRA::WRAY | John Wray | Mon Dec 05 1988 21:04 | 32 |
| Well, it looks like I'll be adopting VAX Ada as the language that best
meets my requirements. I thought that this would probably be the case
before I entered the base note (some of you may even have detected the
resulting anti-Ada bias in the wording of some of my requirements :-).
As there are some extremely annoying (at least to me) restrictions to
VAX Ada (Ada in general) - poor list-processing capability, no
automatic garbage collection, subprograms aren't objects (even tasks
aren't fully general objects), other silly restrictions on the
generality of language constructs, etc.) - I hoped that somebody could
point me towards something better. I looked at LISP, but was put off by
its apparent lack of modularity. Modula-2 might have held some promise,
but as the DECWRL compiler isn't properly supported, I didn't look much
further. Algol 68 would have been nice (the Algol 68-RS dialect
satisfies almost all my requirements), were it available for a
reasonable price in the US.
I must say I'm fairly disappointed with the results of this ad-hoc
survey of mine. I'd have thought that, after 30 years of language
development, someone would have come up with something that
incorporated all the features that I was looking for. Maybe my
requirements are atypical - maybe COBOL, C and FORTRAN really are all
that the world really needs.
On a positive note, I have discovered VAX SCAN, an excellent language
for writing parsers in. I congratulate you folks at TLE on producing an
excellent special-purpose language. This obviates my requirement that
my chosen implementation language should be able to construct a
recursive-descent parser whose structure reflects the BNF - I've
already written my parser as a SCAN procedure. Now if only you guys
would document the structure of SCAN 'Tree' data-structures, so that I
wouldn't have to waste time flattening them before I return them to a
conventional language....
|
212.5 | | TLE::HOBBS | | Tue Dec 06 1988 09:27 | 1 |
| SCAN was not developed in TLE. It was developed by Steve Greenwood in CLT.
|
212.6 | CLT::SCAN | CLT::ROLFHAMRE | Mikael Rolfhamre - VAX BASIC & SCAN | Tue Dec 06 1988 09:52 | 4 |
| For more on SCAN see the notes conference CLT::SCAN. Press KP7 to
add CLT::SCAN to your note book.
- Mikael
|
212.7 | Modula-2 is available from other sources | MJG::GRIER | In search of a real name... | Tue Dec 06 1988 12:08 | 13 |
|
I like your choice of Ada and SCAN personally, but your comment
about Modula-2 isn't entirely correct. If purchasing a 3rd party
compiler was an option (which it evidently was for Algol,) several
companies produce VMS Modula-2 compilers. Logitech comes to mind
offhand, but I know there are others. (If an Ada compiler wasn't so
expensive, it'd be my portable language of choice, but I'm not ready
to spend $3000-$4000 for a language on my PC/XT at home when I can get
a Modula-2 which produces better code supposedly than any other PC
compiler, and still costs under $100...)
-mjg
|
212.8 | Trellis & Owl ? | DWOVAX::YOUNG | Great Cthulu Starry Wisdom Band | Tue Dec 06 1988 12:54 | 2 |
| Theres also the Trellis/Owl stuff done by SRC. Probably has almost
everything that you want, except the implied "Official" support.
|
212.9 | Trellis and Modula-2 not currently supported | COOKIE::DOUCETTE | Chuck, DBS/CCAS/Vortex/Babelfish | Tue Dec 06 1988 21:23 | 19 |
| Trellis was developed by a group of people who used to call themselves ERL
(Eastern Research Lab) or the Object Based Systems Group (not SRC). We work
with them. It is an excellent OO language (although I'm not sure it does
everything you want). The appropriate conference is PBSVAX::TRELLIS (press KP7
to select). Currently it runs on VMS and has lots of associated documentation
(such as a language reference manual). My only complaint about the Trellis
language is that operations are not first class objects (like the PROCEDURE
data type in Modula-2). There is no concept of "pointers" in Trellis like
in Modula-2 or C.
I think the comment about Modula-2 was meant about DEC WRL Modula-2 which
isn't currently supported (esp. on VMS). I hope Logitech Modula-2 has gone
much farther than the Hamburg Modula-2 compiler on VMS (I'm under the
impression that the original Logitech compiler was derived from the Hamburg
sources). For more details about the Hamburg Modula-2 compiler on VMS which is
available internally - see TURRIS::MODULA.
Chuck
|
212.10 | | AITG::VANROGGEN | | Sat Dec 10 1988 20:14 | 8 |
| re: .4
I'm curious as to how Common Lisp appeared to lack modularity.
It supports the ability for users to create their own namespaces
and to explicitly (or implicitly) export or import symbols, and
to shadow symbols.
Or was another meaning of the word "modularity" assumed?
|
212.11 | All hypothetical | CAIRN::HARRIS | | Wed Mar 08 1989 10:33 | 3 |
| This is frustrating. I have never heard of any application that requires this
combination of features. Can you enlighten.
-Kevin
|
212.12 | | ULTRA::WRAY | John Wray, Secure Systems Development | Wed Mar 08 1989 12:12 | 105 |
|
I don't understand why you find it frustrating, but anyway here's
a brief description of the application -
I'm writing an interactive toolset that will be used to analyze and
annotate information-flow properties of software. This toolset
requires the features that I mentioned as follows:
>Strong typing
Because I can't stand languages that are half-hearted about typing. If
typing is worth having at all, then it's worth having strong typing
(personal prejudice, based on several unpleasant encounters with C, a
language that only seems to know about types when you're deliberately
trying to do something where typing gets in the way :-)
>Perform list-processing (no silly restrictions on pointers to
> stack-based data)
The application has to do a large amount of list-processing, concerned
with storage and manipulation of information flow relations. These
relations are really sparse boolean arrays, and it is much more
efficient to store them as lists rather than array data. The
stack-based data restrictions are a reference to Pascal and Ada which
don't allow you to create pointers to named objects (in particular
fields of records), thus forcing the programmer to jump through hoops
to manipulate lists. Also, automatic garbage collection would have
been real handy.
>Writing a syntax analyser (must allow functions to take 'OUT'-mode
parameters so that a recursive-descent
parser actually looks like the syntax
being parsed)
Well, since I discovered SCAN, this requirement vanished, as all
I had to do was to describe my syntax and SCAN built the syntax
analyzer for me. This is needed because one of the inputs that
my toolset can accept is an interface flow-specification of a piece
of software. When I was drawing up my "language wishlist", I
remembered running into this problem several years ago when writing
a recursive descent parser in Ada. Because of the Ada restriction
that functions can't modify their parameters, what started off as
a simple coding-up of the bnf as a set of "recognition functions"
turned into a messy set of procedure calls and status return tests.
>Array manipulation (must be able to declare operators and functions
that take arrays as parameters, and deliver
them as results; Provide built-ins for finding
out the bounds of arrays, and performing slicing
and trimming operations; Must be able to assign
an array value to an array variable without knowing
the bounds of the value ahead of time)
The representation I chose for my flow relations is in fact a
combination of arrays and lists, and the arrays basically need to be
flexible. In Ada I kludged things to satisfy this requirement partly
by using pointers to arrays everywhere, and partly by writing dynamic
array handling packages. It'd be nice if the language had these things
as built-ins, though.
>Procedures as objects (I want to be able to put procedures in data
structures)
Also I want to be able to pass procedures as parameters. This is
required, both by DECwindows and by my own preferences in programming
style. In Ada I can satisfy the DECwindows requirements (sometimes
at the cost of having to design my package structure specifically
to allow this, rather than on the basis of functional separation).
Ada does have the generic mechanism, which is better than nothing,
but is no real substitute for genuine procedure objects.
>Separate compilation (inter-module type-checking etc.)
This goes hand-in-hand with the strong-typing requirement above. In a
large system, there is little point in having intra-module typing
support, if types are forgotten across module boundaries. Ada
satisfies this requirement well.
>Ability to call procedures written in other (VAX) languages
Numerous uses. DECwindows. RMS. Common RTL procedures. As it turned
out, SCAN, a little bit of macro, and Ada. Ada is pretty good at
this.
>Support for multi-programming on VMS
(either by tasking within the language, or by
allowing AST routines to be written so I can
roll my own)
This is because not all the functionality I required from my user
interface is available from DECwindows. In particular, I want to be
able to call TPU to provide a portion of my user-interaction, without
having the rest of the application seize up. This can be done either
by genuine language-supported multiprogramming, or by running TPU in a
sub-process and using a mailbox and attention ASTs to communicate
asynchronously between the processes. Also, some of the manipulations
I do can take a considerable amount of time, and I don't want the
user-interface to freeze-up whenever the application does a bit of
processing.
Hope this shows that these are real requirements, and not just a
"wouldn't it be nice if..." question. Even if that were the case,
there are applications that could use subsets of these requirements, so
it'd be nice if there were a language that could satisfy them all.
|