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.

AppGameKit Classic Chat / Extra operators

Author
Message
Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 21st Jan 2011 10:57
It makes a lot of sense to include extra operators such as ++ and += allowing things like:

a++

a += b (shorthand of a = a + b)

Thoughts on any other operators?
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 21st Jan 2011 11:46
!=, && and ||



Also I can't think of a language that uses it but in maths we use ! infront of a variable to signify the inverse of it, would there be a way to include this in AppGameKit?

a=1
!a=0

b=0
!b=1/0

c=623
!c= umm... is it just 0 again? xD

And just for fun you could have something silly:
d="Hello"
!d="olleH"
For when someone tries using a numerical operator on a string.


Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:13
% instead (or as well as) mod

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:13
If we already have a working and logical convention though why add complication?

What's wrong with:
<> instead of !=
inc instead of ++
and instead of &&
or instead of ||?

If there are some new operations it might be worth it.

In C# for example a++ can be used differently to ++a for pre or post incrimenting.

Hodgey
14
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 21st Jan 2011 12:14
I find the '%' (mod) useful.

@ C0wbox:
If !b = 1/0 won't that cause a runtime error as you can not divide by 0?

A clever person solves a problem, a wise person avoids it - Albert Einstein
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:15
In response to baxslash - why not have both?
<> and !=
inc and ++ (+=)

C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 21st Jan 2011 12:18
Oh yeah, how did I forget %.

@ baxslash
Well I spose <> is a reasonable alternative to != (I just like C++ syntax more than DBP syntax xD)

Also I heard inc and dec call whole functions so wouldn't it be better to create an operator that handles it. +=, ++, -= and --

@ Hodgey
I don't know; there's got to be some logical way to express !0 in a computer. xD

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:21
Quote: "In response to baxslash - why not have both?
<> and !=
inc and ++ (+=)"

Why change something that everybody that uses DBP already knows?

Changing the (BASIC) language changes the direction. If there's a good reason to do that then sure but most people here use DBP, so why make it different when there isn't a valid gain? At least not one I'm aware of...

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 21st Jan 2011 12:24
Quote: "Why change something that everybody that uses DBP already knows?"


Because AppGameKit isn't explicitly for DBP users. There will be new programmers using AppGameKit and users of other languages where != is the standard. So your argument could be flipped for none-DBP users.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:29
Quote: "Because AppGameKit isn't explicitly for DBP users."

True. I just have thought the majority would be though... otherwise why are they asking us?

I got the impression they were trying to base this on DBP and improve on the old formula. For me, changing the formula to match other languages is not an 'improvement' but a shift.

Hodgey
14
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 21st Jan 2011 12:30
@ baxslash: it also alows simplicity with other operators e.g
a *= b instead of a = a * b.
As far as I'm aware there is no easy way to type a = a * b in DBPro

A clever person solves a problem, a wise person avoids it - Albert Einstein
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 21st Jan 2011 12:32
Quote: "it also alows simplicity with other operators e.g
a *= b instead of a = a * b.
As far as I'm aware there is no easy way to type a = a * b in DBPro "

That's a good argument. I use C# at work anyway and it would make it easier for me

I'm just trying to see it from both sides, that is a good reason for the shift. An actual improvement.

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 12:40
I find operators like != etc extremely unreadable - <> is far more intuitive to me. If it were available an = with a / superimposed would be my choice.

I have no strong feelings about ++ although I do find "inc x" instantly understandable compared to "x++" (which always makes me think something is being added twice).

I generally prefer simple words to obscure symbol sequences especially in a BASIC style language. The more or less universal +, -, *, /, ^ and = are fine though.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 21st Jan 2011 12:49
<> only makes sense with numerical data types, so it should be replaced with != or ~= or =/= or something.

I also think ++ and -- are pointless, in C/Java they are used 99.999% of the time in for loops, because the 'for' construct is nothing like the one in BASIC. In BASIC, your loop iterator increments by whatever the step value is(default 1), so that's its most common usage out the window.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 21st Jan 2011 13:19
Having a case-insensitive string comparison operator would be nice, like UnrealScript's ~= operator.

Also, if you do decide to implement standard 3D types (vectors etc) I'd expect all existing applicable operators to work, as well as having operators such as dot and cross. It's easier to type and read.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 13:59
I'm not sure that the C or C++ operators need to be imported into the language (/=, *=, +=, -=, ++, --). If you aren't careful, you'll end up with confusing operations being carried out in DBPro, with no idea what should or will actually happen:

Better to not have ++ and --, and to use inc and dec commands instead - it's explicit then:


The logical AND/OR/XOR operators need to be introduced though - having bit-wise isn't quite enough.

I'd cautiously accept Benjamins suggestion on new operators for new types, but as long as they are available as functions, I'd not be too worried if they weren't included.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 14:57
+1 for both logical and bitwise operators!

[b]
thenerd
15
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 21st Jan 2011 15:33
I agree...

Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 21st Jan 2011 21:38
Quote: "Also I can't think of a language that uses it but in maths we use ! infront of a variable to signify the inverse of it, would there be a way to include this in AppGameKit?"

!Boolean means doesnt

eg

bool hello = false;
if (!hello)
{

}

bool hello = true;
if (hello)
{

}

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Jan 2011 22:53
At this early stage in the discussion, I am in favour of the BASIC flavours rather than the C++ flavours. AppGameKit Tier 2 provides for our C++ cousins. AGL Tier 1 should choose it's operators and symbolism based on what is best for ease of use, reading other peoples code, e.t.c. I do agree that any missing operators should be added to the language

I drink tea, and in my spare time I write software.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Jan 2011 23:13
Does this cover them all?
Comparison operators: = < <= > >= <>
Arithmetic operators: + - * / ^ MOD
Arithmetic commands: INC DEC
Logical operators: AND OR XOR NOT
Bitwise operators: && || ~~ .. << >>

If so, then that matches what's actually documented in the DBPro help files (even though it doesn't match the DBPro reality).

Then, if new types are introduced (vector/matrix types), new 'word' type operators can be added too if you think it's warranted, such as Ben's DOT and CROSS.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 21st Jan 2011 23:37
+1 for IanM's suggestions.

[b]
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 01:07
++1 from me too.
C0wbox
17
Years of Service
User Offline
Joined: 6th Jun 2006
Location: 0,50,-150
Posted: 22nd Jan 2011 03:29
We should just scrap all the operators and use reverse polish notation. - It's much more logical. !

Brk_oth
18
Years of Service
User Offline
Joined: 8th Aug 2005
Location: Australia
Posted: 22nd Jan 2011 05:38
+1 for Ians list of operators.. that seems to cover all thats necessary.
I do prefer != to <> but I can work with either and it doesnt bother me.

No signature found...
DMXtra
21
Years of Service
User Offline
Joined: 28th Aug 2002
Location: United States
Posted: 22nd Jan 2011 08:19
I vote for Ian's list as well.

Just because C and C++ are some of the most used languages in the world does not mean its all that readable to the common folk.

Ian's list is more realistic and more in-line with something that is easier and readable.

Dark Basic Pro - The Bedroom Coder's Language of choice for the 21st Century.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 14:15
I forgot to specify one thing in that list though, and that is that the possibility that logical operators should short-cut whenever possible.

For example:


As soon as 'a' is checked, you know that no matter what, the DoSomething function will not be called, so why bother checking 'b' at all.



As soon as 'a' is check, you know that no matter what, the DoSomething function will be called, so why bother checking 'b' at all.

If you substitute those variables for other function calls, then they should work in the same way.

There are pro's and con's to this though.
Pro: Faster evaluation
Con: Functions with side-effects will not get called, when maybe you want them to.

Discuss

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 22nd Jan 2011 14:26
Quote: "
"


I've got used to DBP's limitations and have instead been using:

In the belief that it would correct that limitation ... I don't think I've every checked it though

It would be nice not to have to split things up like that. So I agree with IanM's suggestion.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Jan 2011 14:33
So do I.

However, if the programmer desires side effects regardless of the outcome of the condition then they should code in a sensible order, i.e. perform the side effect before the if statement.
bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 22nd Jan 2011 14:50 Edited at: 22nd Jan 2011 15:29
Scratch all that, I'm in favor. I totally went off in the wrong direction because I wasn't paying attention!

This may be an issue with statements like:

If makeObject(1) and makeObject(2)
print "fail!"
endif

Where you may want makeObject(2) to go through if makeObject(1) fails.

I think shortcutting should not be used and instead programmers can do what Scraggle posted if they want shortcutting.


[center]
Join the TGC Group!
http://tehcodez.groups.live.com
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Jan 2011 14:52 Edited at: 22nd Jan 2011 14:57
Quote: "If makeObject(1) and makeObject(2)
print "fail!"
endif

Where you may want makeObject(2) to go through if makeObject(1) fails."


But if the net result is a 'failure' why would you group the two operations together unless they were dependant on each other?

I'd also like to add that if short-circuit evaluation isn't available, and the function being called relies on a previous condition, you'll end up with problems:



It serves the more powerful languages, I don't see why you'd not want to see it added in AGK.
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 22nd Jan 2011 14:54 Edited at: 22nd Jan 2011 14:57
Since you are asking for extra operators, I am a fan of the ternary operator and would like to see it in AGK.

I much prefer this:

Over this:

But I can see why it may cause confusion especially with the colon.

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 22nd Jan 2011 15:00
Yeah short-circuit evaluation is vital, I don't think I've ever written code where the calls within an if statement are all required to be run, such things should almost logically use multiple lines.

bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 22nd Jan 2011 15:02 Edited at: 22nd Jan 2011 15:04
Quote: "But if the net result is a 'failure' why would you group the two operations together unless they were dependant on each other?"


Because maybe you want to print the same warning if either fails, but you don't want the warning printed twice.

If one function depends on the other, you shouldn't put them in the same if/then statement, they should be separate statements.

I guess if DBP ever short-cut or circuit or whatever, I've never seen it happen or it didn't effect the outcome of my code.

But to me, it makes more sense that if one function relies on the other, checks should be in place explicitly, not intrinsically in the layout of a single if/then statement.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd Jan 2011 15:09
Quote: "Because maybe you want to print the same warning if either fails, but you don't want the warning printed twice."


In that case you would write something like this, which would not short-circuit:

bitJericho
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 22nd Jan 2011 15:26 Edited at: 22nd Jan 2011 15:30
oh, yeah, duh.

You guys are right again

Here's me, not known the difference between "and" and "or"

I'll change my vote to yes, this is needed.

[center]
Join the TGC Group!
http://tehcodez.groups.live.com
Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 22nd Jan 2011 20:50 Edited at: 22nd Jan 2011 20:50
Quote: "I much prefer this:+ Code Snippet
if a ? doThis() : doThat()"


Thats an inline if statement.

C example:


(<CONDITION> ? <TRUE RETURN> : <FALSE RETURN>;

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 21:30
I'm not going to go so far as to say that I disagree - if it's in the language then I'll use it. If it isn't, then obviously I won't.

However, take into account how difficult it is to actually design that operator within the compiler (and I don't mean parsing it).



Taking that code, what 'type' is the return value of '(1 > 2) ? a : b'? Is it a float, a byte, or something else? What happens if one or both of a or b are incompatible (string + udt)?

Fatal Berserker
13
Years of Service
User Offline
Joined: 2nd Jul 2010
Location:
Posted: 22nd Jan 2011 22:14
Quote: "Taking that code, what 'type' is the return value of '(1 > 2) ? a : b'? Is it a float, a byte, or something else? What happens if one or both of a or b are incompatible (string + udt)?"


Well the return type will have to be an integer.

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 22nd Jan 2011 22:21
Quote: "Taking that code, what 'type' is the return value of '(1 > 2) ? a : b'? Is it a float, a byte, or something else? What happens if one or both of a or b are incompatible (string + udt)"


c is an integer so the return type is an integer. As for string + UDT that would obviously be an error in much the same way as this is:


IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 22nd Jan 2011 22:32 Edited at: 22nd Jan 2011 22:33
Since when has the storage type ever affected the return type? Yes, the return type is converted to the storage type when necessary to store it, but it never affects the expression's underlying type.

Let me see if I can express this in C++ without actually using the terniary operator:


What type would you put where the question-marks are?
Here's a page I found that discusses the problem: http://geeksforgeeks.org/?p=9205

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 23rd Jan 2011 14:48 Edited at: 23rd Jan 2011 14:49
Yep, you're right, of course.

*hangs head, accepts defeat*

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 23rd Jan 2011 16:00
Quote: "*hangs head, accepts defeat*"


I know the feeling.
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 26th Jan 2011 22:04
Would it not be reasonable to just check if both values were compatible to the context? For example, with assignments, don't check the type of the whole operator. Instead, check the types of each of the operands, check if they are both compatible with the left side of the assignment. I don't know how it'll look when it's compiled, but if it's stack based like Java, it shouldn't be that difficult.

"everyone forgets a semi-colon sometimes." - Phaelax
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 26th Jan 2011 23:34
As long as a method for casting is introduced, it could simply require both operands to have the same type.

[b]
BiggAdd
Retired Moderator
19
Years of Service
User Offline
Joined: 6th Aug 2004
Location: != null
Posted: 30th Jan 2011 15:17 Edited at: 2nd Feb 2011 18:58
Quote: "template <typename Ta, typename Tb>
???? TerniaryOp(bool Expr, Ta A, Tb B)
{
if (Expr)
return A;
else
return B;
}"


Can't you just use Polymorphism to determine the return type, using "Object" or "boost::any"? (Had to look that C++ one up)
I'm not familiar with C++, but using "Object" in Java would be valid (But obviously that's only because everything in Java is a child of Object)

Digital Awakening
AGK Developer
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 1st Feb 2011 19:50 Edited at: 1st Feb 2011 19:51
I'm all for: var != var 2 (read as "not equal to"). I have always preferred that over <>.

I also like doing stuff like: if !function() then

I also like these and -*/ variations on them:
var++
var += var 2
var += 5


But I want to keep "and" and "or" as they are.

[center]
Alquerian
18
Years of Service
User Offline
Joined: 29th Mar 2006
Location: Reno Nevada
Posted: 17th Feb 2011 01:42
% for mod
+=,-=,!=,&&, !, ||
Alquerian
18
Years of Service
User Offline
Joined: 29th Mar 2006
Location: Reno Nevada
Posted: 17th Feb 2011 01:44
Quote: "In response to baxslash - why not have both?
<> and !=
inc and ++ (+=)"

Scrag, sorry but I totally disagree with you. Bad bad bad coding practice. Try using it in a mixed solution like that and performing a search and replace. Absolutely PRONE to logic errors.
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 17th Feb 2011 09:57
Quote: "Scrag, sorry but I totally disagree with you. Bad bad bad coding practice. Try using it in a mixed solution like that and performing a search and replace. Absolutely PRONE to logic errors."

You're right of course, it should be one or the other. I guess TGC are going to have to decide whether they are writing something "Basic" or something closer to C++

Everyone will have their preferences based on their experience of other langages.

I would hope for something closer to DBP but a little more consistant in its approach, in this case it would make more sense to use != and += as they are similar to >= and <=.

Login to post a reply

Server time is: 2024-04-25 16:22:15
Your offset time is: 2024-04-25 16:22:15