Possible Alpha BASIC 1.6 compiler problem?

[Neil Rieck]

This week I ran into a problem which I caused three weeks ago (typo) but the Alpha BASIC compiler did not catch. (See the comment "typo"
below). However, the call still failed at run time when triggered by customer data.

So here is my question:
1) Since I was using "option type=explicit" is the compiler at fault?
2) should I have declared "dt_stamp" as "dt_stamp()" ?
3) will using "dt_stamp()" be future-proof?

Neil Rieck
Waterloo, Ontario, Canada.

1000 !============================================================
! title : alpha_basic_16_compiler_problem.bas
! author : Neil Rieck
! created : 2010-02-19
! note : tested using "Alpha BASIC V1.6-000"
! dcl : $bas/optim=level=0/lis -
! alpha_basic_16_compiler_problem.bas
!============================================================
option type=explicit !
!
! should this next line be changed to: "dt_stamp()"
! and will it be future proof?
!
external string function dt_stamp !
ccyymmddhhmmss
external string function html_escape(string) !
external string function html_unescape(string) !
!
declare string buff1$, buff2$, buff3$ !
!
2000 while 1 !
print "enter something (blank to exit)"; !
linput buff1$ !
goto fini if buff1$ = "" ! exit on
blank
print "date+time>"; dt_stamp !
buff2$ = html_escape(buff1$) !
!~~~ buff3$ = html_unescape(buff2$) x intended
line
!
! this next line is not what I intended...
! ...but the compiler did not complain
!
buff3$ = dt_stamp(buff2$) ! typo line
if buff2$ <> buff3$ then !
print "-e- conversion error" !
print " Org: "+ buff1$ !
print " Esc: "+ buff2$ !
print " Une: "+ buff3$ !
end if !
next !
!
30000 fini: !
print "-i-exiting" !
end !

[Hein van den Heuvel]

This question is a cross-post from comp.os.vms.

The question itself was not clear to me on first reading, but was later clarified in c.o.v.
The key is question #2.

Declaring a function without argument list, allows any argument list.
Declaring a function with an empty argument list, only allows it to be called without argument. If the program does provide an argument it'll get the error:

%BASIC-E-PAREXPFOR, 0 parameters expected for DT_STAMP

This is NOT documented, but seems perfectly natural.

1) Since I was using "option type=explicit" is the compiler at fault?

No, you did not articulate arguments, or the lack thereof, suggesting freedom of choice.

2) should I have declared "dt_stamp" as "dt_stamp()" ?

Yes, if it should not have an argument and you'd like the compiler to ensure that.

3) will using "dt_stamp()" be future-proof?

Yes.
a) the behavior makes sense.
b) there is no active development.

Basic has been in maintenance mode of a decade or more best I can tell.

Like you indicate in c.o.v, maybe an official HP person will give and unofficial answer here. That could happen, but I doubt it.

Cheers,
Hein

[John Gillings]

Neil,

When you want to report a problem, it's a good idea to post the actual behaviour you're observing, and what you're expecting.

Having done language support for several decades, I can tell you that it's fairly rare (but not impossible) that perceived misbehaviour is a compiler error. Compiler bugs therefore fall into the Carl Sagan category of "extraordinary claims".

Of all the languages available on OpenVMS, C and Basic tend to generate the most "compiler bug" reports, when it's really a misunderstanding of the language. Basic, although it's supposed to be a simple language, does LOTS of extra stuff you probably don't know about. Even the most innocuous statement can generate along sequence of type conversions and apparently extraneous operations. In almost all cases it's necessary to conform to the language definition, but it's not always what the programmer intended.

Next time you find something like this, please strip it down even further. Eliminate all I/O statements (they generate LOTS of code), and examine the output of /LIST/MACHINE to see what the compiler is really doing.

I don't have a Basic compiler, so I can't check, but I'd have thought something like:

1000 option type=explicit
external string function dt_stamp
declare string buff1$, buff2$
buff1$=dt_stamp
buff2$=dt_stamp(buff1$)
end

should show you what the compiler is really doing.

"BASIC compiler did not catch."

Don't expect BASIC to "catch" errors. The language is far more oriented towards "do what I (think you) mean" than "make sure the program is correct". If you want a compiler which keeps you on the straight and narrow, switch to Pascal or Ada.

[Neil Rieck]

When this project started way-back-when, I suggested Pascal but was over-ruled so my only option is to make BASIC much more strict.

To your question, since the external string function "dt_stamp" was declared without a parameter list -AND- I had invoked "option=type=explicit", I mistakenly assumed that the compiler would complain whenever I called this function with parameters. This did not happen which means I eventually encountered a run-time error.

From the feedback on comp.os.vms I think the only way out is to declare a null parameter list like so:

external string function dt_stamp()

and assume it will always be future proof.

[Robert Brooks_1]

I don't have a Basic compiler, so I can't check, but I'd have thought something like:

--

Then let me take this opportunity to suggest you get an account at eisner.decus.org

The signal-to-noise ration cannot be beat, although the signal count isn't really high these days

-- Rob

[Jon Pinkley]

This is a pointer to the comp.os.vms thread:

http://groups.google.com/group/comp.os.vms/browse_thread/thread/50ae37fbba5bc8a0/499391ac94515b99

[Jonathan Cronin]

(More in reply to Hein than Neil)

Your explanation is correct, but in fact there is an exceptional case which I believe ought be caught by the compiler and is not.

Given:
! BUG.BAS
external string function external_function( string )

declare string s

s = external_function()

end


function string external_function( string s )
end function s

I 'd expect to get a compiler error about the wrong number of arguments. Instead I get a run-time memory management error.

If I add an argument to the external function:

! BUG2.BAS
external string function external_function( string, string )

declare string s

s = external_function()

end


function string external_function( string s, string s2 )
end function s

I get the expected compiler error:

s = external_function()
............^
%BASIC-E-PAREXPFOR, 2 parameters expected for EXTERNAL_FUNCTION
at line number 5 in file BUG2.BAS;3

I SPR'ed this, but the response interpreted my SPR as complaining about the run-time error, not the failure of the compiler to report the error. My mail explaining this got no response...

Jonathan

[Neil Rieck]

If you insert "option type=explicit" at the top of your program, it will enforce parameter data types and numbers.

[Jonathan Cronin]

Neil said: "If you insert "option type=explicit" at the top of your program, it will enforce parameter data types and numbers."

Nope, that makes no difference. I always use type=explicit, I just was trimming the bug code to the minimal code that produced the bug.

AFAIK, type = explicit only affects whether BASIC will assume variable type information, including individual parameters, but not parameter type checking. That is, it checks using the assumed types.

Jonathan

[Neil Rieck]

What is the version number of your complier? (and is it VAX, Alpha, or Itanium?)

[John Gillings]

Nature of the beast! Basic was never intended to be a strongly typed language.

"option type=explicit"

was added to give rudimentary protection against typos in variable names, but explicit typing doesn't imply anything about argument list checking. What might be of use here is another option, perhaps "arglists=strict" (or similar). However, the chances of that happening, given the support status of the product, are vanishingly small.

Unfortunately there are too many places where the Basic syntax for defining argument lists can't deal with all the possibilities, especially for routines in languages other than Basic. Thus, there has to be an escape mechanism to allow unchecked argument lists.

Basic was intended to be an "easy" programming language (oxymoron!). The reality is programming is never, and can never be "easy" for non-trivial programs.

I've found that the very features intended to make Basic easy, actually have the reverse effect! You need to be very careful about what you write, because the compiler makes many assumptions on your behalf.

[Jonathan Cronin]

re: compiler versons,

I tested the one-argument version with Itanium 1.7, Alpha 1.7 and Vax 3.9 and got consistent results. I tested the two argument version with both 1,7 compilers and again got consistent results.

Jonathan

[Neil Rieck]

Same with me. While compiling with BASIC v1.6 Alpha, I get the correct behavior for testing paramater lists (param numbers as well as data types). But I do need to append a null list to functions with no expected parameters. (but as others have already suggested, this is probably the recommended technique)