Using ThinBasic to emulate the old HP Basic for GPIB Instrument Control

[peralta_mike]

I'm thinking of using ThinBasic as a front end Basic intrepreter
for GPIB instrument control -- just like the old Rocky Mountain Basic.

Anyway my question (suggestion) is as follows:
Is there anyway a user defined function can be called without having to preface it with CALL?
And can it assign the return value in the following way: y=sin(x)

- Mike Peralta
peralta_mike@hotmail.com

[Michael Clease]

Mike is this what you are after.


Dim z As DWord

z = Dothings(2,1)

MsgBox 0, z

Function Dothings(x As DWord, y As DWord)

Return x+y

End Function

[peralta_mike]

Thanks Michael,

That is what I needed.

- Mike

[ErosOlmi]

Hi Mike,

as Michael already replied, you can call sub and functions the way you like.
CALL statement it absolutely optional when calling a Sub or a function.

CALL statement can be handy when you need to call a function whose name is not know but you can compose it dynamically at runtime using a string expression.


Dim z As DWord

Dim FunctionNumber As Long

FunctionNumber = 1
'---Call a function name whose name is composed at runtime
Call "Dothings" & Format$(FunctionNumber, "00") (2, 3) To z

MsgBox 0, z

Function Dothings01(x As DWord, y As DWord)

Function = x + y

End Function

Function Dothings02(x As DWord, y As DWord)

Function = x * y

End Function



On returning a value from a function you can use different ways:
FUNCTION = <...value...>
RETURN <...value...>
NameOfTheFunction = <...value...>


Function Dothings(x As DWord, y As DWord)

'---All thinBasic valid ways to return a value from a function
Function = x + y '---Execution will continue to the next line
Return x + y '---Execution of function will stop and value returned. Following line(s) will never be executed
Dothings = x+y '---Execution will continue to the next line

End Function

Also remember you can pass parameters BYREF so changes to a parameter value will be applied to passed variable.

[peralta_mike]

Thanks.

One of the primary goals in porting Rocky Mountain Basic (RMB) code to thinBasic is that any code (or as much as possible) of the RMB code works under thinBasic without any modification.

Over time this may mean some redundancy in thinBasic but hopefully this will not be too troublesome for the thinBasic developers. Ultimately (as much as possible) I would like to see the RMB language be a subset of the thinBasic language whereby any code in RMB can be run "as is" within thinBasic.

- Mike

[ErosOlmi]

If you drive me where I can get a RMB I can check syntax and see what I can do.

[zak]

a commercial HTBasic provides the Rocky Mountain BASIC integrated program development environment including a syntax-sensitive, full screen editor and interactive execution and debugging statements.
http://www.htbasic.com/products/software/htbasic/development/

http://www.techsoft.de/documents/htbasic.html

demo download:
http://www.htbasic.com/index.asp 27 MB

Limitations of the Demo version:

- Save / store of program files not possible

- Demo quits after 30 minutes (can be restarted)
i am downloading now ( slow 512 KB/s)

[Michael Hartlef]

Thanks.

One of the primary goals in porting Rocky Mountain Basic (RMB) code to thinBasic is that any code (or as much as possible) of the RMB code works under thinBasic without any modification.

Over time this may mean some redundancy in thinBasic but hopefully this will not be too troublesome for the thinBasic developers. Ultimately (as much as possible) I would like to see the RMB language be a subset of the thinBasic language whereby any code in RMB can be run "as is" within thinBasic.

- Mike











:roll:

This is definately something I would not like to see. If Eros wants to go that way then we can throw in some other Basic dialects. FreeBasic, BlitzBasic, DarkBasic, LibertyBasic. What the hell. Put it all in.

[Michael Clease]

I'm with you Mike H. this is ThinBasic and not VB,Scriptbasic, Pascal,C if it was going to be compatible with anything then PowerBasic is the product of choice for obvious reasons.

Why have 10 different ways of doing the same thing ;--)

I think the interest HTbasic users has got something to do with the really poor support for customers of HTBasic i.e last update 2007 and I suspect Mike P is looking for an enviroment that is being developed, I dont want to speak for him I'm only guessing.

All that being said it is for Eros to decide its his baby.

Regards

Mike C

[ErosOlmi]

Be sure I'm not going into RMB direction.

What I can do is to have more constructs without changing current syntax.
If this means changing current syntax, I will not add it.
If this means adding new control flow like the quite intuitive REPEAT ... UNTIL ... why not? It will not break any previous thinBasic compatibility and if not used will not change anything.
If this means just making a keyword optional (for example from SELECT CASE ... to SELECT [CASE] ...) than why not?

Haven't we added all C assignment statement (*=, -=, ...) and few month later PB developed them?
Haven't we added all UI controls specific keywords and again few month later PB developed most them?

All programming languages must evolve possibly not breaking compatibility with previous versions.
thinBasic evolved so much in recent years thanks to the requests all of you have asked. Why now we have to stop in this evolution?

[Michael Hartlef]

Evolution is great. But we have to make sure that beginners can see a clear line on how to use thinBasic.
Having different ways of doing a select case structure for an example could be confusing.

But maybe if the documentation will point these differences out so they jump into your face, then maybe it is ok.

[ErosOlmi]

I think many of you are still here not just because you love my bad face ( :D ) but because thinBasic has evolved and has been supported in those many years (thanks to all of you of course). How many programming languages we have faced to see the light and to die? How one can put such an effort in learning a programming language and then discover it was a partial waste of time? (I say "partial" because learning in never a waste of time)

Sometimes evolution is done by little steps, sometimes with great jump.

What I'm trying to do in this thread are just little steps that do not change anything to the language but add few more ways of doing the same thing. More ways of doing the same thing is more freedom for the programmer to express his passion and less impositions from the language.

Someone think more freedom = less control = more errors = bad programs.
I can partially agree but I also know that good programs made by passionate programmers who think not only to themselves but also to those will read their sources are always very well recognisable.

PS: in any case I'm considering request by request. I do not know if I will be able to add or not any request or if adding it will change to much the syntax.
For example while I was writing this post I was checking SELECT CASE and making CASE optional is not that simple because it is used in many error checking during pre-parsing.

[peralta_mike]

Whatever can be done to accommodate rmb is greatly appreciated. Thinbasic has all the basic constructs already. For any syntax differences b/w rmb & thinbasic I can make help pages in my rmb to thinbasic help library detailing any port conversion that are necessary. My aim (to whatever extent seems reasonable to the thinbasic community) is that the syntax that needs changes is minimal for rmb programmers. I don't expect or desire for thinbasic developers to bend over backwards or distort thin basic's simplicity and elegance for rmbs sake. Rmb is a very minimal language and I think only a few accommodations are needed by thinbasic. Most of the differences will be in rmb functions and those will be in external library modules that I will create and make available for free for all.

[PupcoDevel]

Since I could not find an introduction thread (not that I usually have anything worthwhile to say in one..) I wanted to post here. I see it has been quite some time since anyone has discussed a RockyMountainBasic implementation for ThinBASIC.

I am very excited to become a part of the community with HP-IB GBIB control as my primary focus. I about lost my lunch when looking at HTBasic - my God! Yes I want to run automation with 40 year old HP test equipment - and yeah it "might be" pretty neat, but I don't want to land my workbench and instruments on another planet as is suggested on their shiny new site! And the cost? Just for me essentially to just revisit something learned and forgotten over the years to poll equipment today. I suppose I was about 5 years old when I learned to program M$'s BASIC on a machine that came factory with 8K of RAM and a Moss 6502 processor.

My plans and time I have to divide anymore these days between so/too many projects likely will slow the process of learning (and from the looks of it a lot of "re-learning") ThinBASIC. So - be forewarned I may have some very obvious questions that come about. Additionally, my time-frame on this project is VERY wide open as HP instrument measuring and control for me is a practical and personal matter only for personal enrichment and not financial or commercial gain and I am purposely staying away from solutions like Labview or similar solutions. Anyway, I am glad to be here and excited for the day when I can answer other people who have rung the rain out of their umbrella's full of multi-thousand dollar HTBasic water and filled it back in with something practical. I would guess many like myself even with lots of really spectacular yet old gear around will be as dismayed as I was looking up old RMB and finding out the current vendor is selling the language at price higher than all the instruments we could control with it.

Thank you all in advance for your patience and I hope to start working real exercises within about the six month time frame, so look out for the silly questions are likely to abound!

Kind regards,
Douglas

[Petr Schreiber]

Douglas,

feel free to flood us with questions!

We try to keep ThinBASIC BASIC, but we try to overcome the problems original BASICs had as well. So we hope you will find many situations, when adapting the code to be more thinBasicish will be something you will see as a benefit for maintainability and/or performance.


Petr

[PupcoDevel]

Thank you for the warm welcome Petr. If time grew on trees I would be knee deep in ThinBASIC today, but alas I am sure we all know of that. I spent maybe an hour going through some samples and writing some sloppy code last night - which sort of brought back old memories. What some here may not know is that while ThinBASIC is now an object oriented capable language. No kidding the guardians of this project likely have little idea how much it has in common with the very first BASIC interpreters! This is good for I think it will mean I need to relearn some syntax usage and add the element that original M$ BASIC never had and that is mainly graphics and such. We had a very limited number of sprites that were hard coded and the letters of the alphabet and 0-9 were using most of them. 38 years later I have not forgotten the PRINT CHAR$(63) character sting command - wow that makes me sound very old!

Again thanks for the welcome. I am looking at this year's workload and seeing other than reading or writing code with my lunch sandwich in my mouth is likely to be most of what I can spare time-wise until about the middle of the year, so everyone be forewarned. And thanks not only for welcoming me here, but equally as important keeping BASIC in any form alive. People who have never programmed in BASIC should be forced to give it a run - I know 75% of the programmers and developers I know that are not familiar with ThinBASIC would be mind blown by the capabilities of BASIC.

Thanks and look for me to be lurking!

Douglas

[ErosOlmi]

Ciao Douglas,

welcome to our little but warm community.
We all love BASIC language and all its dialects. We try our best to keep it alive.
Hope you will find what you search, otherwise just ask.

Ciao
Eros