Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Author
Message
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 19th Jan 2011 19:58
I don't understand why anyone would want case-sensitivity, surely having variables called astring$ and aString$ would be very confusing.

Quote: "
Brackets around all functions! - This just makes the language far more consistent, in DBPro it made no sense that commands that returned nothing didn't require brackets, but user functions that also returned nothing did. Also, not having brackets could maybe be used to pass functions around in variables? This would allow for callbacks.
"

Do you mean instead of this
print "Hello World!"
You'd write it like this
print("Hello World")

I agree with everyone that there needs to be more consistency in the language than DB had.


Everything worthwhile requires effort.
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 19th Jan 2011 20:46 Edited at: 19th Jan 2011 21:00
Quote: "I don't understand why anyone would want case-sensitivity, surely having variables called astring$ and aString$ would be very confusing."


So would naming your variables aaaaaaaaaaaaaaaaaa and aaaaaaaaaaaaaaaa, why would you do it?

And now that you mention it, the $ from commands that return strings needs to go, same when used for variables, along with the # for floats. Those both add complexity with no benefit.

The only reason to be against case-sensitivity is if you dislike the chosen capitalisation standard, right? Because all the arguments against it I can think of are identical to the situation of you making a typo in a command name(and that issue will always exist). But then again, it's not like converting ANSI to a certain case is difficult, it's just one 256byte lookup table, so I suppose it doesn't really matter. It's not like I read other people's code that often!

Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 19th Jan 2011 21:11
If it is going to be case sensitive, make an IDE that updates the source code (hidden from the user) prior to sending it to the compiler. That way, every body can use whatever naming conventions they want and not have to worry about it.

I prefer Java conventions, thisIsAFunction(). Just please, if you make it case-sensitive, don't make it all capitals. That will drive me nuts.

"Only the educated are free" ~Epictetus
"Imagination is more important than knowledge..." ~Einstein
thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 19th Jan 2011 21:15
I think it should be case insensitive, because everyone has their own style and convention system they like using.

swissolo
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 19th Jan 2011 22:51
Quote: "I think it should be case insensitive, because everyone has their own style and convention system they like using."


Exactly! It also makes it really picky ImageOne or Imageone? It's such a simple mistake and so easy to catch. It's an IDE thing, but an alternative to auto-completeing, that shows all the possible functions and such from what you've typed is something I've been really wanting somewhere, plus such a thing is easily disabled, if you do it right I guess.

Ex)

make obje
__________________________
make object ()
make object sphere()
...
__________________________

Helps with spelling too.

swis
Yodaman Jer
User Banned
Posted: 19th Jan 2011 23:08
Quote: "...the $ from commands that return strings needs to go, same when used for variables, along with the # for floats. Those both add complexity with no benefit."


I agree wholeheartedly!

It's much easier to write variables like this:



After learning some of C++/C#, I do that so often anymore and yet also still assign the "#" and "$" to floats/string variables. Dark Coder's right in that it offers no true benefits. If it was dropped from AppGameKit that would be a great improvement in my opinion.

And about case sensitivity, I think making it so that any case was accepted would be the smartest move. That way, it's up to the programmer how their code looks. Just like DBPro.

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 19th Jan 2011 23:18
- Yes spaces (if the goal is to remain consistent with DBPro)
- Yes brackets (if the same change is made to DBPro (for consistency))
- case-insensitive (it should be an IDE thing. the compiler shouldn't care about case)

Just don't let this become yet another language that aspires to be like C++. There's enough of those already.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 20th Jan 2011 04:30
Great feedback so far on the primary issues facing AGK. Keep them coming and at some point we might run a pole to count the factions (space vs no space, bracket vs no bracket) Should be fun!

I drink tea, and in my spare time I write software.
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 20th Jan 2011 04:54
Quote: "Just don't let this become yet another language that aspires to be like C++. There's enough of those already."


Yes, but consistency between IDE's makes it easier to code in different languages. Just saying.
SoftMotion3D
AGK Developer
19
Years of Service
User Offline
Joined: 24th Aug 2005
Location: Calgary,Alberta
Posted: 20th Jan 2011 05:52
why cant it be both?

it cant be that hard to test after a comma if there is a space first before the value...

I know when im speed coding i never throw spaces in.... but again i do like the look of clean code.

my vote is both!

Development & Editting
BillR
21
Years of Service
User Offline
Joined: 19th Mar 2003
Location: United States
Posted: 20th Jan 2011 06:10 Edited at: 20th Jan 2011 06:17
No spaces within commands
Always brackets around command parameters
cap first letter in each command word like: LoadImage
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 20th Jan 2011 12:55
Quote: "it cant be that hard to test after a comma if there is a space first before the value..."


I think you misunderstood the question. It is whether to have spaces in command names, not spaces between parameters

eg.
If we chose to use upper camel-case and brackets, the two options would be the following.

With spaces:


Without spaces:


[b]
DMXtra
22
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 20th Jan 2011 13:10
1) No Spaces
2) No object numbers
3) Case insensitive

Here is an example of what I mean:



Why use spaces and object numbers when you can use variables?
Now, I know that myimage is storing "yourimage.png" inside of it.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
Fatal Berserker
14
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 20th Jan 2011 13:28
@DMXtra that will only work if u can control myimage OO.
eg
myimage.Width = 100;

dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 20th Jan 2011 14:29
Quote: "@DMXtra that will only work if u can control myimage OO.
eg
myimage.Width = 100;"


Not really, myimage could be an integer. I imagine there will be functions like PasteImage no matter what, and these would take images in the form of whatever LoadImage returns, of course I would prefer them to be objects, that way you can write functions that only allow you to pass images, this requires less checking and makes it harder to break your code by passing the wrong thing.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Jan 2011 14:44
Huh? The code could simply return an integer or a pointer. It doesn't have to be an object at all.


darkvee
19
Years of Service
User Offline
Joined: 18th Nov 2005
Location:
Posted: 20th Jan 2011 15:11 Edited at: 20th Jan 2011 15:13
Hi guys,

Very nice so far great idea's. Well here is my 2 cents.
How about something very easy that is really flexible something like this.



darkvee
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jan 2011 17:10
I've got rather confused by the brackets discussion. What exactly is being suggested? Which commands would require brackets? What about things like sync, repeat, end? What precisely is the defining characteristic of a function compared to a command?
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 20th Jan 2011 17:25
@GG
In DBPro there are two types of commands. Ones that return a value and ones that don't. Ones that return a value require you to use () to call them, ones that don't return a value require you to not use ().

What is being suggested here is to use () to call commands regardless of whether they return a value or not.
ie.


Statements like 'do' and 'loop' would not use () though as they are part of the language rather than a command.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jan 2011 17:55
Quote: "In DBPro there are two types of commands. Ones that return a value and ones that don't. Ones that return a value require you to use () to call them, ones that don't return a value require you to not use ()."


Yes I know.

Quote: "Statements like 'do' and 'loop' would not use () though as they are part of the language rather than a command."


That's precisely my question. What do you mean exactly? When is a piece of code defined to be a "command" rather than a "part of the language"? Why should, for example, "sync" be regarded as "part of the language" and not need brackets whereas "sync camera 0" presumably is a "command" and does need brackets. The two seem at face value to do essentially similar things and should have equal status (yes, I know sync does more).

Aren't all commands (or whatever you call them) all part of the language?
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 20th Jan 2011 19:22
No, there's a distinct difference between commands and statements

Statements are things which alter the flow of the program. Such as:


[b]
Sph!nx
15
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 20th Jan 2011 20:39
My personal preferences would be as close to DB-Pro as possible.

Regards Sph!nx
http://www.mental-image.net
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Jan 2011 23:01
Quote: "No, there's a distinct difference between commands and statements"


So "statements" have entered the discussion now? Anything else you'd like to mention that's been overlooked? Actually, I thought every line of code was a "statement"? Perhaps not? Who knows? What about sync? Would that now become sync()?

I'm sure there must be a simple rule which tells us which commands, statements, functions, reserved words, etc, etc, would have these superfluous brackets added to them. I'm not convinced that program flow is the defining rule, but it might be. If so then we'll have sync().
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 20th Jan 2011 23:22 Edited at: 20th Jan 2011 23:25
OK, simple rule: if it goes and runs some other code then it's a command, and would require brackets to call

Commands are just external functions which are called from DBPro, whereas things like do, loop, etc. do not run any external code, they ARE the code.

As for definitions, every logical line of code (ie. ignoring empty lines, comments, etc.) must be a statement.

The possible statements allowed are defined by the language, but for DBPro include:
- Assignment (a = 1, b = upkey(), etc.)
- Function call (sync, myfunction(), etc.)
- Variable declaration (myvar as integer)
- Flow control (do, loop, if, function, label, etc.)
- Data statement (data)

When I said "statement" I meant the flow control statements and data statements, as that is how they are usually referred to. (The do statement, the while statement, etc.)

I've used the term "Command" to mean functions from a dll in the plugins, plugins-user or plugins-licensed directories, ie. a built in function.

As for the reason behind having brackets around all commands: You have to use brackets when calling a user defined function in DBPro, even when it doesn't return a value. Why should it be any different for built in functions (commands).

[b]
Flatlander
FPSC Tool Maker
17
Years of Service
User Offline
Joined: 22nd Jan 2007
Location: The Flatlands
Posted: 21st Jan 2011 00:09
I have been a programmer since the early 70's. I started with Fortran and Pascal. Went to COBOL, then to C and ended up with C++ and finally VB. Every programming language as at least these structural components: Variables, Constants, arrays, subroutines, functions and control statements. Every programming language uses a command line. These elements are the basis for a programming language. It seems to me that "statement" and "command" have eventually become interchangeable. For example we can call, "Dim meters as integer" the Dim statement. We can also call "if..then..else" a control statement. This can make it confusing and Green Gandalf makes a good point in wanting to clarify exactly what should have brackets and what should not. Gosubs are also at times called "Gosub statements."

I am not sure how the original authors of such languages as FORTRAN, PASCAL, BASIC and C determined when to use brackets. It seems that one of the rules is that if a function returns a value then it will have brackets. However, this is not always the case. In VB6 there is a DATE function. varDate = DATE. There are no brackets. Then you have a DATE statement with DATE on the right side of the equation. Of course, no brackets here. Then you have arrays. dim varArray(1). Is this a statement or a function? No matter it does have brackets.

The consistency of a programming language has always been confusing to me. I sometimes think I have a handle on it and then my mind goes into a fog once again about it.

So now, should the developer of AppGameKit be consistent with DBPro? It sounds to me that it is more along the line of DBPro than C++. However, if some C++ programmers should be using it, then there has to be some facsimile to the rules of C++ without getting too confusing for the DBPro programmer, I should think.

Should one have brackets on sync. I don't know. There isn't such a command in C++ is there? Maybe there is, although I can't remember.
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 00:18
Although the meanings of statement, etc. have become confused, there is a clear different between a function call, and not a function call.

At a low level, a function call results in a "call" assembly instruction being used, whereas nothing else does. At a higher level, a function call results in some other piece of code being run and then returning, and nothing else does that. IMO, all function calls should use brackets, so that they are all standard. Having brackets makes it obvious that some other bit of code is going to run.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 01:16
Quote: "I have been a programmer since the early 70's. I started with Fortran and Pascal."


Looks like Flatlander and I went to the same school (except I did Algol instead of Pascal).

Quote: "IMO, all function calls should use brackets, so that they are all standard."


I agree.

I'm just not 100% clear what constitutes a function - but if the distinction comes down to whether or not a low level assembly "call" instruction is used then so be it. The distinction is hardly likely to be obvious to the average user. I find it hard to believe that the other constructs don't call code but then I know practically nothing about assembly and machine code.

On balance I vote for brackets - even if it means writing "sync()".
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 04:58 Edited at: 21st Jan 2011 04:59
Quote: "I'm just not 100% clear what constitutes a function"


Basically every time you need indention is when you enter into something that isn't a function call, i.e.



In other languages such as C/C++/C#/Java/PHP/etc the distinction is more obvious because you can put braces after all of these such statements, or in python you'd use tabs.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 13:31
Quote: "Basically every time you need indention is when you enter into something that isn't a function call, i.e."


What about "end"? [I certainly would indent my code if we had to enclose everything in a begin/end pair, but we don't. ]

Actually, I think Diggsey has made the point about functions quite effectively already.
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 13:55
Quote: "What about "end"?"


End is a function:



Quote: "I certainly would indent my code if we had to enclose everything in a begin/end pair, but we don't."


We do, if/repeat/while/for/select/case/type/function all have closing pairs that are required.


Quote: "Actually, I think Diggsey has made the point about functions quite effectively already."


Well you said you weren't 100% sure, so I tried to give a different definition.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 14:57 Edited at: 21st Jan 2011 14:57
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)?

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 15:16 Edited at: 21st Jan 2011 15:19
Quote: "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

Quote: "he said, to stir up trouble"


Too late for that.
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 15:59 Edited at: 21st Jan 2011 15:59
He means that the pairs are "do" with "loop", "while" with "endwhile", etc. They function identically to begin/end or { } in other languages.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 16:35
Quote: "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?
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 17:21 Edited at: 21st Jan 2011 17:24
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

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 19:42
Quote: "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.
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 20:19 Edited at: 21st Jan 2011 20:22
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.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 20:40
Quote: "I think 'end' is a stupid feature to begin with"


To end with, perhaps?
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 21:52 Edited at: 21st Jan 2011 21:52
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


Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 21:54
Why?
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 21:58
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.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 22:06
Quote: "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.

Quote: "'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. ]
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Jan 2011 22:23
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()

I drink tea, and in my spare time I write software.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Jan 2011 23:27
Quote: "So I guess we best get used to seeing things like Sync() End() and WaitKey()"


Rampage
16
Years of Service
User Offline
Joined: 4th Feb 2008
Location: New Zealand
Posted: 22nd Jan 2011 09:31
Brilliant. I love my parameters being separated by brackets. This should be nice.

Regards,

Max
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 30th Jan 2011 12:48
@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?


Everything worthwhile requires effort.
dark coder
22
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 30th Jan 2011 13:42
Quote: "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.

Alquerian
18
Years of Service
User Offline
Joined: 29th Mar 2006
Location: Reno Nevada
Posted: 17th Feb 2011 01:26
I cannot stand multi-word commands with white space!

No white space for commands!
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 15th Mar 2011 02:14
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

I drink tea, and in my spare time I write software.
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 16th Mar 2011 03:33
Eh? You press Esc to end your program Maybe I've been spoiled by DBP

[center]
Join the TGC Group!
http://tehcodez.groups.live.com

Login to post a reply

Server time is: 2024-11-24 02:09:51
Your offset time is: 2024-11-24 02:09:51