| 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.
 |