Is it (he said, to stir up trouble)? Isn't END just another flow-control statement, that returns control to a lower level of code (the runtime)?

We do

Pardon? Are you saying there is a "begin" statement after all?

If not "begin" what's the other half of the pair which ends with "end"?

I think you misunderstood my comment.

Edit

he said, to stir up trouble

Too late for that.

He means that the pairs are "do" with "loop", "while" with "endwhile", etc. They function identically to begin/end or { } in other languages.

He means that the pairs are "do" with "loop", "while" with "endwhile", etc.

I know. But since he was replying to me surely what I meant is what's important, not his misunderstanding of it?

Ah I see. Well DC was saying that end is a function (which technically it is in DBPro as it calls the function "?Quit@@YAKXZ" in dbprocore.dll). However, due to the way AppGameKit will work (with a bytecode) the equivalent to "end" will most likely no longer be a function call so there is no issue

the equivalent to "end" will most likely no longer be a function call so there is no issue

Er, in terms of DC's original point there is, i.e. if non-function code requires indentation what about "end"? It obviously should if we were required to put a "begin" at the beginning.

My preference is that the main program should have a clearly defined start and end. But I can happily live without it.

Well technicalities aside, 'end' is the equivalent of a 'goto' statement that jumps to the end of the program, both aren't structured control flow constructs unlike everything else, so there would of course be no indentation. Looking back on my post, I did say 'Basically' , but yea those two are exceptions, and in other languages, switch/select would be too, to an extent.

And if it matters, I think 'end' is a stupid feature to begin with, and goto should be gimped to only work within the current function.

I think 'end' is a stupid feature to begin with

To end with, perhaps?

All my programs require the need for one goto and one end.
They generally have a similar layout to this one:


... and somewhere there will be a

Why?

Because large programs with lots of media take a long time to release control after ending - 'Concentric' being a prime example. Adding that code speeded up the process dramatically, so now I always use it as a matter of course.

Adding that code speeded up the process dramatically, so now I always use it as a matter of course.

Is that still true? I remember it was a big problem about 3 years ago. If it still is it might be worth raising with Lee or IanM or even a Bug Report.

'Concentric' being a prime example

Memories ...

Is it still available? If so, I might give it a go on my main PC. [Hmm? I wonder if it's lurking on my hard drive somewhere. I'm probably still useless at it though. ]

Although I think it might be an initial culture shock, I think we're all leaning towards having brackets for all commands/functions/calls (whatever you would like to call them wee beasties). So I guess we best get used to seeing things like Sync() End() and WaitKey()

So I guess we best get used to seeing things like Sync() End() and WaitKey()

Brilliant. I love my parameters being separated by brackets. This should be nice.

@Dark Coder
You have made me realize that I'm not against case-sensitivity but I'm FOR having to declare variables before using them. The reason I didn't want case-sensitivity is typos that would create new variables.

I totally disagree with you about END though, how would you avoid running into functions without it?

I totally disagree with you about END though, how would you avoid running into functions without it?

By designing the language to make sense, I don't even know why it causes an error in DBPro.

I cannot stand multi-word commands with white space!

No white space for commands!

I remember back in student days, teachers would ban us from using GOTO long before we realised why. It is a dangerous command, capable of bringing the biggest and best programs to their knees!

The reason for an END command is due to the freeform way you can structure your code, i.e:

Gosub _MySub
End

Function MyFunc()
EndFunction

_MySub:
Return

_MyOtherSub:
Return

Function MyFuncTwo()
EndFunction

Crazy layout, but someone is bound to end up with something similar to this, and if you follow the instruction pointer down you will see you hit Function MyFunc() if the 'End' command did not exist. Originally in DBP, I forced an END when the instruction pointer hit a function header, but this would hide some logic errors and so an error message was added to let users know they had fell off the end of their program into a function (sometimes from a subroutine where an Return command was missing). The solution was an End command, and it also became a useful tool when teaching new coders that every program at some point has to end

Eh? You press Esc to end your program Maybe I've been spoiled by DBP