[Info-vax] System implementation languages, was: Re: RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[David Froble]

Craig A. Berry wrote:
> On 6/23/16 11:26 AM, David Froble wrote:
>> Simon Clubley wrote:
>>> On 2016-06-22, David Froble <davef at tsoft-inc.com> wrote:
>>>> Paul Sture wrote:
>>>>> On 2016-06-22, Simon Clubley
>>>>> <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>>> On 2016-06-21, David Froble <davef at tsoft-inc.com> wrote:
>>>>>>> John Reagan wrote:
>>>>>>>> RMS wins the trifecta of languages. You'll find Macro, BLISS, and C
>>>>>>>> in the source directory.
>>>>>>> WHAT !!!
>>>>>>>
>>>>>>> No Basic ???
>>>>>> Sorry David, but Basic is not a system implementation/programming
>>>>>> language. :-)
>>>>>>
>>>>> My memories of RSTS suggest that BASIC got used *everywhere*... :-)
>>>>>
>>>> Good one!
>>>>
>>>
>>> Not really. :-)
>>>
>>> You can't use any version of Basic I've come across to write a kernel
>>> mode device driver or the kernel itself.
>>>
>>>> Take that Simon, who just recently mentioned RSTS/E ....
>>>>
>>>> Ok, back to reality.  I do believe the RSTS/E OS was Macro-11
>>>
>>> True. Examples of what I consider to be a system implementation
>>> language (SIL) are C, Ada and the odd version of Pascal (such as the
>>> version used to write VAXELN).
>>>
>>> Examples of languages which are not SILs are Basic, COBOL and PHP.
>>>
>>> Simon.
>>>
>>> PS: If DEC had fixed up some issues with Pillar and implemented it,
>>> that would have made a good SIL (better than C IMHO). Unfortunately,
>>> DEC never followed through with Pillar.
>>>
>>
>> Any language, if appropriate capabilities are implemented, can be so
>> used.  I seem to recall that DEC's C needed some work before it could be
>> used.  Put the same capabilities in Basic, and it would do just as
>> well.  Well, maybe even better.
>>
>> It's all just 1's and 0's ....
> 
> You're missing quite a bit there. For one thing, with BASIC and most
> (all?) other HLLs on VMS, you are making RTL calls without realizing it.
> In other words, the compiler uses things like OTS$CVT_L_TB or
> STR$GET1_DX and friends to implement language statements that are not
> explicitly calling functions or subroutines. Unless all the RTLs
> involved satisfy all the necessary requirements for reentrancy, thread
> safety, atomicity, and probably other things I'm forgetting, then you
> can't safely write inner mode code in such a language.
> 
> Could a BASIC be implemented that satisfied the requirements? Possibly,
> but you might not want to use it. I don't know exactly what would go
> missing, but as a hypothetical, say you had a BASIC that had no WHEN
> ERROR clause, could not do dynamic strings, and had no language-level
> support for I/O such that you had to use more primitive interfaces to do
> all I/O. Would you still be advocating for such a language?
> 
> 
> 

Without getting into the details, a version / subset / whatever of any language 
could be implemented with the necessary capabilities and restrictions.  Would it 
be simple?  No.

The current Basic uses RTL calls extensively.  They are there, and it's simple 
enough.  Is that the only way to do things?  Of course not.  But it's adequate 
for the current uses of Basic.

Is it worth doing with Basic at this time?  No, not really.  There would be the 
satisfaction of rubbing some noses in it (Hi Steve), but, that would be some 
really labor intensive satisfaction.

Sometimes some things just don't mix well.  Not sure why I've had such a problem 
with C.  But I do.  I'd have an easier time doing something in Macro-32 than C. 
  I'm sure I'm in a very small minority.  But, that's where I am.

Also note, it's my impression that not all parts of C can be used in kernel mode 
work.  Could be wrong.  Don't think so.