Syntax question?

[bigtunacan]

I'm curious why do some of the built in commands work in the same manner as a function call using the brackets like

Code (glbasic) Select Expand


SPRCOLL (5, 0, 0, 6, 0, 0)


but then others only work without the brackets like

Code (glbasic) Select Expand


DRAWSPRITE 6, 0, 0


This seems very inconsistent and I don't see a clear reason why/when each is being used?

[Omadan]

The only thing I can think of there is that the SPRCOLL is a comparison. if(xxxx) then do xxxxxxx
whereas the DRAWSPRITE is just a simple draw command. Not 100% sure though, its better to let Gernot shed some light here

[Moebius]

Functions with return values need brackets (by convention at least), but it almost makes sense to have commands that don't return values specified without brackets.  It's BASIC, not C++ 

[Moru]

What I learned about Basic when I started was that functions that returns values has (), functions (or commands) that don't return values has no ().

eg:
x=ASL(y)
PRINT "hello"

[bigtunacan]

@Moru,

If that was consistent it would at least then make some sense systematically; however if I define a function in my code I must always call it using bracket notation as far as I can tell, so still this does not seem consistent.

[MrTAToad]

Dont forget that all user-defined GLBasic functions return a value - you can choose to ignore it or not...

[Moru]

Functions - Returns value
Subs - Does not return value

Function call:
x = my_function()

Sub call:
GOSUB my_function

Perfectly consistent to me. If you choose to ignore the return value it's up to you to write it differently.

[bigtunacan]

@Moru,

See my original post using DRAWSPRITE as an example.  It s not called using GOSUB, but it uses non-bracket notation.

[AMateus]

Hi,

I don't see any inconsistency in GLB syntax wise.

Every command that return a value has brackets, any command that doesn't return a value, doesn't have brackets. It's the difference between Functions ans Procedures.

It's a basic concept: Procedures execute an action and that's it, Functions executes an action and return something. For example, by Visual Basic 6 uses this approach.

DRAWSPRITE doesn't return a value, so it's not supposed to have brackets. DRAWSPRITE executes an action and that's it. If it returned, for example, a success of failure result, then you had to use brackets.

António

[matchy]

It's a good point and I don't usually don't create subroutines in glb either because they could also return useful errors. For example, DOESFILEEXIST() could be incorporated into LOADSPRITE(), which is the function that I end up using/creating anyhow.

[Moru]

@Moru,

See my original post using DRAWSPRITE as an example.  It s not called using GOSUB, but it uses non-bracket notation.

The post I commented was talking about functions you yourself defined and called. DRAWSPRITE is an internal command to draw a sprite. Does not return anything so has no brackets.

[erico]

interesting subject,

I never really bothered for it or even notice it. I only ever used basic and veeery little assembler.
But now I remember trs80color basic, line command had brackets for coordinates...? Line(0,0)(10,40),1 Draw command didn´t.

really curious!

[bigtunacan]

My original  post specifically called out the internal commands.  Taking it a step further however, IMHO, the style used for internal commands and user defined commands should always match.  I have no issue with the difference between a user defined function and a user defined sub.  That is consistent and causes no confusion.  The one that will cause me to stumble from time to time is the internal commands.  I will be happily coding away and then I get a compile error because I called something internal using a standard functional notation.  While these things are by no means deal breakers, it causes you to stumble for a second and can get you out of the zone.  In most languages I have worked with there is no difference between how internal and user defined functions are called from the code. 

If the issue truly is that you don't need brackets if a value is not returned as a couple of people stated that would at least then make some sense, but it would beg the question why I am unable to do the same thing with a user defined function?  There are times when I have functions that are executing based on my parameters provided and I have no care about anything returned.

I was surprised to get so many responses on this, but I'm glad to see that at least other people care about this as well whatever your opinions may be.

[Slydog]

As mentioned by AMateus, Visual Basic 6 uses the same method as GLBasic.
What's even more confusing, VB6 allows both, depending on the context you call the function.
If using MsgBox() to only prompt the user you don't need the brackets, but if you want to check the button clicked, you NEED the brackets!

GLBasic user functions ALWAYS return something (whether you check for it or not), because when you don't specify a return type, float (#) is assumed.  Well, that's my guess anyways.

However, I would personally prefer ALWAYS needing brackets, to make my code consistent.
I occasionally use the DEBUG command (no brackets) but also use my own custom 'Log()' function and always get the brackets mixed up between the two!

[matchy]

interesting subject,

I never really bothered for it or even notice it. I only ever used basic and veeery little assembler.
But now I remember trs80color basic, line command had brackets for coordinates...? Line(0,0)(10,40),1 Draw command didn´t.

really curious!

Oh yeah! I have noticed that during some coco graphics coding recently. It also remind me of good ol' "m=peek(n)" and "poke n, m"