I am taking some stuff from Arev to OI, to see if it is feasible.

There are 105 arev programs in my source library which have no passed arguments.

Like -

SUBROUTINE SEND.A.MESSAGE

. CALL MSG('Gday Paul', , , ) RETURN To get this to compile and achieve the exact same functionality in OI, I have to get the converter program to add a dummy argument - like this - SUBROUTINE SEND_A_MESSAGE (DUMMY) . CALL MSG('Gday Paul', , , )

RETURN

I am interested to know the reason that there has to be a rule in OI that there must be at least one argument.

When work started on OI the the developers were enamoured with a language called Eiffel. Despite lengthy internal representations from concerned developers some of the more obscure implications of this fixation (compulsory data typing, compulsory conditional paragraphs et al) were not removed/made optional for several releases. The requirement to have an argument was never removed.

The Sprezzatura Group

World Leaders in all things RevSoft

Now that sets me a wondering.

Many of us 'know' that whatever the structure of Revelation and its sister products is, it appears always in practice to achieve better solutions than other languages.

I can understand anybody becoming enamoured with Eiffel, Smalltalk etc. but I never see anybody spouting the inate qualities of the structure of Revelation et al.

Why is this so?

What is the 'structure' of Revelation. I would start with the Basic+ language (though I have trouble with that name - DEC RSTS used to have an excellent language called Basic Plus), and say that the structure of the language is encompassed in this -

 Result= Process (Data)

 These are examples of the structure -

   Price=Get_Price(Product_Code)

   Unlock_All

   Save_Customer_Row(Customer_Code, Row)

Now how do we make this look complex and pseudo-scientific to capture the rest of the market

Thanks for the memory - my first commercial programming was done on a PDP11 with RSTS and RT11 (?) (and CoBOL with an XEKB compiler). I loved Basic+ - lovely language - even a nice "On Error". In fact I still have a program listing in my "personal file" I used to get my first Rev job! And how I was envious of the management who had VT Gold Terminals (I had a line printer with a keyboard). I wrote a flexitime program for the labs in the UK Office of Squibb & Sons… arghhh, more than 20 years ago….

The Sprezzatura Group

World Leaders in all things RevSoft

Do you mean that it isintended that the extra, superfluous, dummy, redundant, confusing, misleading argument is to stay?

Was this intended to be rhetorical, oratorical, theatrical, booming, melodramatic?

The Sprezzatura Group

World Leaders in all things RevSoft

Personally I often use dummy arguments to avoid conflicts between other arguments. I remember particularly well the time I made a function SubString_Search( SubString, TargetString ) for the purpose of scanning the TargetString argument for occurrences of SubString. The function consistently failed, for no obvious reason. It turned the two arguments couldn't agree which one should be first, and the larger TargetString managed to bully SubString into second place at runtime.

I resolved the problem by placing a dummy argument between them: function SubString_Search( SubString, Dummy, TargetString ). Out of sight, out of mind, it seems.

- Oystein -

I am sorry to hear of your experience with the idiosyncracies of a language - I assume it was not Revelation code.

While I am happy to cater for an extra argument if that is necessary, I reckon the OI implementors are interfering with the basic elegance of Revelation's Basic language by changing the calling syntax. The currently defined process structures are PERFECT, they indicate to the programmer and the operating system what is being used.

Changing them for any purely internal technical reason is a retrograde step.

Pragma ahead of quality killed IBM software and it is starting to kill Microsoft.

I cant believe that I am the only one who doesnt like this change.

It was intended to be serious - I was using shorthand for my opinion of the change.

Sorry Peter it was difficult to conceive that a situation that has existed since OI 2.0 nearly ten years ago and has become just a minor annoyance to most could still move someone to such prolixity. Whilst accepting it is a pain when converting from AREV the change was requested so frequently during the earlier years and not implemented that it was assumed it was either fundamentally embedded or just not worth pursuing.

The Sprezzatura Group

World Leaders in all things RevSoft

Peter ..

You are quite correct in another way. Now all I/O operations require a THEN or ELSE construct in OI which wasn't required in AREV. Someone said that the Windows engine required this construct although for the life of me I don't understand why since the run-time engine is an interpreter anyway so it could do whatever it wants. Maybe one of the Microsoft whiz-bangs that RTI hired at one point did it.

Don M.

C3 Inc.

I dont mind those changes - while I would prefer another method of exception handling, the then/else on data access is OK.

And the changes are consistent with already existing structures like reads.

Don

Well AREV 3.12 was inconsistent in that it required conditional clauses on Opens and Reads but not Writes. At some stage TPTB obviously decided to enforce certain conventions for OI. This is just software - I find it difficult to believe that this has anything to do with anything other than a design decision (Like removing the "Stop" statement in OI). If the worst came to the worst the precompiler could add an "Else Null" clause…

The Sprezzatura Group

World Leaders in all things RevSoft

Yes .. there were many *conscience* (and I use the term loosely) decisions made inside. Some of the convesations were .. instructive

And don't forget .. this aint Arev for Windows

dsig@teleport.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 503-639-4240

Quite true. I think the problem lies more with the lack of consistency AREV / OI. I'm certain that the pre-compiler could easily correct the source code. It's like the error in terminating a label inside a GOTO, GOSUB, etc. with a colon. What's objectionable is that this condition stops further compilation and detecting other errors until it's fixed. No biggie, but if AREV code is being converted with a lot of COLONS, then the process is very tedious.

One of the joys of REV / AREV was the fact that the implementation of BASIC was both powerful and forgiving.

Anyway .. I'll stop the rant ..

Don M.

Oh well

Any,

Must confess I like dummy parameters. Is the following possible?:

function My_Func( Dummy, Dummy, Dummy )

Or must I do

function My_Func( Dummy, Dummier, Dummiest )

?

- Oystein -

View this thread on the forum...