Conference turris::languages

    There are a number of Forth implementations for VMS, but none of
    them are marketed/supported by DEC.  Although Forth can be block
    structured, the code looks a little "weird"; would they be willing
    to accept this?
    
    Steve
    

    DIBOL is a semi-interpreter: it compiles your source into an
    intermediate language, then interprets the intermediate language.
    APL is an interpreter, but it probably doesn't have the kind of
    structure they want.
    
    Why do they want an interpreter, anyway?  If what they really
    want is fast response to the RUN command, is VAX BASIC fast enough?
    It compiles your program into memory, then branches to it.
        John Sauter

    Like DIBOL, TPU compiles your TPU source code into an intermediate code
    and then executes the result.  We certainly consider it an
    interpreter... 
    
    	- Barry

    
       This may seem more like a hack, but how 'bout DCL?  With V5 of VMS
    it has more block-structuredness than before (i.e. IF-THEN-ELSE). 
    Personally, I wouldn't want to depend on the performance of anything
    WRITTEN in DCL, but it's definitely interpretive.
    
       Wouldn't LISP be considered to be interpretive?  (Simple yes/no --
    let's not mess up this topic with a discussion of "what is
    interpretive" and "what isn't".)
    
    					-mjg
    

	First, thanks for all your answers.

	The reason why they want an interpretive language is because they
intend to make some kind of measurements, and to be able to modify parameters
and re-do their measurements with the new parameters, and this practically "on
the fly".

	The problem they find with Basic is mainly performance : the system
load, and the time it takes to compile. Does anyone have experience of
"interpreted" Basic? (for example, what would be the compilation time of, say a
program of 100 lines on a uvax 3XXX?).

	I didn't thought about DCL. Perhaps it could be OK, if we had some DO
loops. Do you think it would be possible for a programmer to simulate it with a 
.cld command verb or perhaps with a command procedure?

	I will also talk them about LISP.

	Francis. 

    Re: DCL Do-loops:
    
       Well, it doesn't have the verb "DO" or "WHILE" in it, but..
    
    $TOP_LOOP_n:
    $ IF .NOT.(condition) THEN -
    $   GOTO EXIT_LOOP_n
    $ ! code goes here
    $ GOTO TOP_LOOP_n
    $EXIT_LOOP_n:
    
       is the correct semantics for a DO loop.  A "repeat"-style loop is
    obviously done by moving the conditional to the end.  That's not so
    bad?  I wouldn't want to talk about performance, BUT it's what you were
    asking for.
    
       Note that DCL can't be self-modifying like some BASICs are, in the
    sense that I've seen MicroSoft BASIC code that looks like:
    
    10 LET A = 5
    20 LET B = 10
    30 LET C = A+B
    40 LET C = C/2
    50 PRINT C
    60 DELETE 40
    70 B = B + 7
    80 GOTO 30
    
       And neither will VAX BASIC allow you to do such a thing.  You'll
    need to LISP if you're going to use the code to modify itself during
    execution.
    
    					-mjg
    

    Re .4:
    
    This can be done in both DCL and TPU by the simple device of modifying
    (or creating, or re-creating) some procedure other than you current
    one, then executing it, then returning, etc...
    
    Most DCL programmers make heavy use of this technique to, for instance,
    substitute symbol values into the input stream of programs that
    are to be run.

    --  Barry

    I'd certainly ask the BASIC people for more info.  If nothing else,
    there's a big difference in I/O operations between a compile, link,
    execute cycle (write obj, read obj, read libraries, write exe, activate
    exe) and BASIC's environment which I gather is a compile-and-go
    system.  I don't know whether BASIC recompiles the entire program
    if you change one line, or simply recompiles the line.
    
    Another option for them might be to change some constants from within
    the debugger.  If that would work, they wouldn't need to recompile at
    all. It's hard to say whether this tactic is appropriate for them, and
    they'd have to be careful that the compiler doesn't make assumptions
    about any values they modify. 
    
    Two questions just out of curiousity:  How are they measuring their
    program?  Why are they changing parameters that are hardwired, as
    opposed to making them run-time parameters?  (I can think of some
    valid reasons, but there are many invalid reasons as well.)
    
       Gary

    Re. .5 -
    
>The reason why they want an interpretive language is because they
>intend to make some kind of measurements, and to be able to modify parameters
>and re-do their measurements with the new parameters, and this practically "on
>the fly".

    The usual way to deal with this type of problem in VMS is via logicals.
    Instead of hard-wiring the parameters in the program and then
    re-writing the program, have the program use logical names instead.

    	You could try my version of FOCAL in
    VISA::SYS$KITS:[FOCAL]FOCAL030.A
    
    	It is an interpreter that is capable of having self-modifying
    programmes. It is small and fast. It runs beautifuly in a 20 page
    working set - I did most of the development when DEC was still selling
    VMS on 256kB machines. I suspect most of the DEC FOCAL manuals are
    out of print now, though.
    
    	But then you might try DSM too. That is also interpreted, and
    is a standard DEC product.

    	Thanks for all your suggestions.
    	At this point ,the prospect looks interested by DCL. I will
    try to tell him about DSM (I suppose FOCAL is no longer supported?).
    
    	As a preceding note mentioned, it is not sure that the reasons
    why they want an interpreted language are really valid; I will
    try to convince them to use logicals or some kind of run time
    parameters.
    
    	Francis.

    	FOCAL never was supported on VMS, though it was supported on
    several other DEC operating systems. The version for which I gave
    a net kit address is just a later version of what is in the DECUS
    catalogue as VAX-1.
    
    	However, he almost certainly does not need an interpreter. As
    an alternative to logical names, point out to him what he can do
    with LIB$GET_FOREIGN (or even a full DCL interface with a CLD file).

    I know this is rather late for this conversation, but don't overlook
    spreadsheets as a solution.  My wife (an independent consultant)
    recently did a job on the PC for someone who had a cut-and-try problem 
    (cost estimation) and the simplest, cheapest solution turned out to be 
    for her to set up a spreadsheet for him.  The customer came to her
    when his BASIC program became too large and complex to maintain.
    
    Your customer's situation sounds quite similar.  In many such cases, 
    spreadsheets are a better solution, and they are overlooked because
    they aren't a "programming language".  And, of course, DEC sells
    a spreadsheet for the VAX.
    
    							Ralph