Author Topic: Oddity with colon  (Read 3270 times)

0 Members and 1 Guest are viewing this topic.

Arnold

  • Guest
Re: Oddity with colon
« Reply #15 on: May 01, 2019, 10:48:45 AM »
Quote
ps ...to be perfectly clear ..i don't use console for anything

I use the console for almost everything. Without console I am lost.

Arnold

  • Guest
Re: Oddity with colon
« Reply #16 on: May 02, 2019, 07:53:45 AM »
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:

Code: [Select]
#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

Mike Lobanovsky

  • Guest
Re: Oddity with colon
« Reply #17 on: May 02, 2019, 11:00:05 AM »
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...)

Aurel

  • Guest
Re: Oddity with colon
« Reply #18 on: May 02, 2019, 01:36:26 PM »
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

Charles Pegge

  • Guest
Re: Oddity with colon
« Reply #19 on: May 02, 2019, 01:38:00 PM »
This would work:

Code: [Select]
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)
« Last Edit: May 02, 2019, 06:33:58 PM by Charles Pegge »

Charles Pegge

  • Guest
Re: Oddity with colon
« Reply #20 on: May 02, 2019, 06:33:10 PM »
Another alternative is to break with the past and trap all $% endings, to enforce clean alphanumeric names. This would be the least confusing option.

Mike Lobanovsky

  • Guest
Re: Oddity with colon
« Reply #21 on: May 02, 2019, 07:29:21 PM »
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

JRS

  • Guest
Re: Oddity with colon
« Reply #22 on: May 02, 2019, 10:41:54 PM »
And ScriptBasic since 1997.

Arnold

  • Guest
Re: Oddity with colon
« Reply #23 on: May 03, 2019, 01:24:46 AM »
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
« Last Edit: May 03, 2019, 03:58:15 AM by Arnold »

Arnold

  • Guest
Re: Oddity with colon
« Reply #24 on: May 03, 2019, 05:22:54 AM »
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
 

Charles Pegge

  • Guest
Re: Oddity with colon
« Reply #25 on: May 03, 2019, 11:36:53 PM »
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.

Charles Pegge

  • Guest
Re: Oddity with colon
« Reply #26 on: May 03, 2019, 11:48:35 PM »
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.
 

Aurel

  • Guest
Re: Oddity with colon
« Reply #27 on: May 04, 2019, 07:10:10 AM »
Hi Charles

no problem just nice to know..  :)