Oxygen Basic
Programming => Problems & Solutions => Topic started by: Arnold on April 28, 2019, 02:29:11 AM
-
Hi Charles,
I compare some console demos that contain keywords from different BASIC dialects and how they could be developed in Oxygenbasic. Unfortunately I have only learned GW-Basic in the past and still suffer from it, though I have probably made some progress in this respect thanks to O2.
In this example (derived from BCX) I apply the use of `:` to concatenate several statements in one line. This works qute nice with one exception in line 53: Oxygenbasic refuses to accept :cls: (:cls : or :cls(): will work):
':cls: does not work?
dim a:setcolor 7,0:cls :for a=1 to 23:print "This is line number "a:print cr:next:print "This is line number "a++:print " Enter ...":call panel(5,10,20,20,15,1,32,0):locate 1,50,0:waitkey:call panel(5,10,20,20,15,4,32,1):locate 1,1,0:waitkey:cls
The error message is:
ASSEMBLER:
ERR: cls!! Unidentified instruction: cls
LINE: 53
FILE: "main source"
At first I thought O2 would see :cls: as a label. But on the other hand :next: and :waitkey: are accepted. Could there be another reason why :cls: throws an error message?
Roland
-
Roland,
While This is only my personal opinion (I have programmed in many versions of BASIC) I NEVER use colons to concatenate several statements in one line. It makes it too hard to follow and to tell the truth I never really saw the reason behind it?
I also never use single line if statements for the same reason.
James
-
Hi James,
I know I am exaggerating a bit. I personally use colon with spaces left and right if I use two or three statements in a line.
But you certainly noticed that I started to port the BCX console demos to Oxygenbasic (there are still about 80 examples left) and this works remarkably well until now. I want to see which library functions of Oxygenbasic I can use to create the apps and what functions / subs need wrapping. I think BCX is very complete in using the console.
My only purpose is to notify Charles if I find a discrepancy. I do not expect a solution at any rate. Most of the time there are alternative ways. Yet perhaps a finding at one point could help with another problem. It is just a guess.
Roland
-
I made a further test, replaced waitkey with getkey and got also an error message. So I now understand what happens. It is not a big problem, but it is helpful to know that there is a difference sometimes between functions/subs and macros. And if I think more about it, I come to the conclusion that getkey() and cls() is actually the correct notation.
-
Hi Roland,
I will restrict label identification to avoid confusion with unspaced colons as statement separators.
-
Hi Charles,
personally I think there is some logic in the error message of Oxygenbasic, I only did not see the reason at the first moment. ProcName() is the correct way, ProcName is for convenience, which will not work in all cases. By porting some of the demos with basic like syntax I found similar cases like function name$() ... which will work sometimes with $, sometimes not, also sometimes calling ProcName a,b,c does not work, but using parenthesis solves the problem. Probably there are some more cases, but I did not check extensively. I think the error messages can really be helpful, they only need to be interpreted correctly.
Perhaps it is possible to add a section in the Oxygen Helpfile about some differences to other languages, about error messages and the possible causes and solutions? Over time, this chapter could be expanded. Other programming languages which are a lot stricter in the syntax rules than Oxygenbasic and by far not so flexible also need to explain their error codes, and sometimes it takes some time nevertheless to find out what went wrong.
Roland
-
By porting some of the demos with basic like syntax I found similar cases like function name$() ... which will work sometimes with $, sometimes not, ...
NB: In BCX and its derivatives, somename$() (string args and/or return) and somename() (numeric args and/or return) are distinct functions or language keywords rather than in situ casts of the same function. You can't mix them at will. You're supposed to match an appropriate function variation with the data you're feeding it. Unlike O2, BCX & Co. wouldn't attempt transparent automatic conversion for you in such cases.
-
As this seems to be a persistent issue, I can make !#$%& word endings significant instead of ignoring them.
-
... I can make !#$%& word endings significant instead of ignoring them.
If you go the BCX way, that will make O2 type checking much stricter than it is now, and as such, much farther away from what a classic BASIC-er would expect. BCX is only a B2C translator and it does only what is more natural for the target language. I'd do that only if I weren't absolutely sure my code can efficiently handle all the implied conversions transparently to the user.
But granted it's also going to make life easier for the language developer, although harder and more error-prone, for the user. :)
OTOH if what you mean by your statement is going to be yet another cast scheme, then I'd vote for it because if 100% consistent and unambiguous throughout the language, it will then be the ultimate shorthand notation for forcible data type conversion I'm aware of.
-
Roland,
I'm not sure you are aware but many of the BCX runtime functions use optional parameters meaning the translated "c" can only be compiled with Pelles C. I don't remember if O2 is compatible?
James
-
Hi Mike,
I'm allowing these characters to be used anywhere in any name except for the first position, but not attributing any type-semantics to them.
For example, these names would be treated as distinct:
a
a%
a$
a$$
-
@Charles:
Oh, I see. You're just expanding the set of significant characters allowable in a name.
@James:
Yes, O2 supports optional parameters too.
-
There are a few parsing consequences.
Some expressions will now require spacing:
a=b&c
a=b & c
if a!=b
if a != b
Core string functions may need to be dollified:
def str$ str
def left$ left
def space$ space
...
-
My point is :
don't change anything... why ?
simply because i always get in trouble with when you made some changes >:(
;)
colon work for me fine
label:
mylabel:
I don't know if o2 have keyword label ?
...anyway ...because of unexpected changes i like to use stable version 043 :D
ps ...to be perfectly clear ..i don't use console for anything
-
Hopefully I will not be misunderstood. Nowadays I can solve so many tasks with Oxygenbasic, which I could not do before. I myself do not need the suffixes and will not use them. When I started with Oxygenbasic and did not know much about other Basics, I fortunately found in the O2 examples most of the time declarations like: int a, float b, string s etc and: function name, sub name. This was sufficient for me to understand what types were used and how they were processed.
But since I noticed that O2 is tolerant to some extent in syntax, I am tempted from time to time to find the limits. And there are already limits with dim:
dim a 'int/sys?
dim b% 'int/sys?
dim c!
dim d# 'int/sys?
dim e$ 'int/sys?
'freebasic $lang: "qb"
dim f&=4 : print f& ""
a=5
b%=6
'c! = 2.4 'error
d#=2.57
e$="Hi"
f&=7.6
print a ", " b% ", " d# ", " e$ ", " f& "" 'concatanation
Implicit declaration by adding a type character looks strange to me. Such a declaration should already be a bug in Oxygenbasic.
-
ps ...to be perfectly clear ..i don't use console for anything
I use the console for almost everything. Without console I am lost.
-
Hi Charles,
this is a small example where I think a programmer who is used to work with $ suffix for type string could get confused:
#lookahead
print Proper$("tRaNsLaToR")
Function Proper(string A$) as string 'Proper$ will throw an error, without: as string will throw an error
Local T$ as string 'without: as string will give result 0
T$ = Ucase$(Left$(A$,1)) & Lcase$(Mid$(A$,2,256))
Function = T$
End Function
I had to change: Function Proper$(A$) to: Function Proper(string A$) as string
and I had to change: Local T$ to: Local T$ as string
Local T$ alone assumes integer type?
Function Proper$(A$)
Function Proper$(string A$)
Function Proper$(string A$) as string
will always give the same errpr message (Unidentified instruction: returnvar), but it is not quite clear what is missing. I suppose, in the current stage of Oxygenbasic it would be easier to find a possible error without using the $ suffix?
Roland
-
Haha Roland,
That's an excellent example to show Charles that his innovations in this sphere bring BASIC-ers more harm and confusion than good!
(And I think his making the !#$%& glyphs significant not in the sense of real type specifiers or casters but rather allowable characters like any other chars in the _ABCDEF...Zabcdef...z0123...9 range isn't going to improve the situation a single bit...)
-
Yesh sometimes looking weird
but there is a simple rule:
$ string constant
% int constant
# float const
! ..well pointer ;D
& probably address
..i dont see any problem with $ .. it is ignored
-
This would work:
def ucase$ ucase
def lcase$ lcase
def left$ left
def mid$ mid
#lookahead
print Proper$("tRaNsLaToR")
Function Proper$(A$ as string) as string
Local T$ as string
T$ = Ucase$(Left$(A$,1)) & Lcase$(Mid$(A$,2,256))
Function = T$
End Function
Also, Aurel's Scintilla/AsciiEdit2, which uses some $-endings, only required 1 alteration. (mid$ to mid)
-
Another alternative is to break with the past and trap all $% endings, to enforce clean alphanumeric names. This would be the least confusing option.
-
Another alternative is to break with the past and trap all $% endings, to enforce clean alphanumeric names. This would be the least confusing option.
It was done in VB6 (literally) ages ago. :D
-
And ScriptBasic since 1997.
-
Perhaps some of the misinterpretation could be avoided, if dim could be forced to indicate the type? I can see that this is possible:
string a$
dim b$ as string
dim string c$
string s$[12]
dim ss$ [12] as string
dim string sss$[12]
function foo(string t$) as string
local string d$
local e$ as string
local string f$
static string g$
static h$ as string
static string i$
i$=t$
string r$=i$
return r
end function
c$="hello"
print foo(c$) & " World"
I always used int a, string b and then there was no ambiguity. I understand that declaring function repeat$() is different than function repeat(), and I think it would be ok if declaring function repeat$() is not allowed, only the error message does not fit. Calling the function in the app as repeat$() would then also work for convenience.
Roland
-
Hi Charles,
after checking some of my apps I think there is not really the need to break with the past. The only real stumbling stone for me was the dim statement without type and I was not aware (or have forgotten) that the suffixes were used in old Basic times as a type qualifier. In RosettaCode I see that this is still applied with some Basic dialects. But I think this should not be done in Oxygenbasic, dim varname as type is unambiguous. If dim with type could be forced, this would be helpful, but even this is not absolutely necessary. If I know that dim name (without as type) defines an integer no matter which suffix is used (perhaps this could be noted in the HelpFile), then it is my responsibility to use the variable correctly.
Roland
-
Hi Roland,
Yes I can trap undefined types for dim.
There is a command for setting default types, which has proved to be unuseful over the years: #dim. I will excise it from o2.
-
Hi Aurel,
There is a conflict between the RTLs and Peter's GdiPlus library: GdiPlus\gdip.inc. It is fixed with a small change to o2, or by using more conventional declarations in the library. I'll do both in the next release.
-
Hi Charles
no problem just nice to know.. :)