InterBlit

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|237\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Blogs Home -> Blogs

JL235	Created : 02 January 2008 Edited : 02 January 2008 InterBlit Blitz Basic v.2?
As many people here know I am currently working on my own free implementation of Blitz Basic. The original goal was to produce an implementation which could run any currently existing valid Blitz Basic program. First what do people think about this? If you haven't or hadn't bought Blitz then would you be interested? For those who have bought Blitz Basic, what do you think? Second, as I've been making this I've been finding areas where I feel there is room for improvement. So I'd like to ask what improvements people would like to see in Blitz Basic. Most of my suggestions are quite small but would break Blitz compatibility. The multiplication of strings Self explanatory: "a" * 3 => "aaa". All variables must be defined This would be as Const, Global, Local or as a parameter. All other variables would be seen as an error. This is useful because if you have the following code: local size sixe = 50 --v You'll notice I have misspelled size, a mistake which can be lost in large bodies of code. If I added this rule then in this example 'sixe' would be thrown as a compile time error. Added alpha support This would be for the Color, ClsColor and DrawImage commands. This is a very easy and simple addition to make. Essentially an extra parameter in the drawImage and an extra component in the colour. local red, green, blue, alpha ClsColor(red, green, blue, alpha) cls() local x, y, alpha local img = LoadImage("my_img.bmp") DrawImage(img, x, y, alpha) --v Adding Short Circuiting This is where with the And and Or operator the right side is evaluated based on the result of the first. This is a very common feature in most languages, but Blitz doesn't have it. For example if we take the following Blitz code: function foo() print "foo" return false end function function bar() print "bar" return false end function local fubar; fubar = foo() and bar() waitkey end --v Currently this will print out 'foo' and 'bar'. If there were short circuiting then the left side is first evaluated and returns false (as usual). But because the left side is false it is impossible for the whole And to ever be true. The right side is then skipped. So with short circuiting this would just output: 'foo'. This would also apply to the Or operator where if left side is true then the right side is not evaluated. "", 0 and False evaluates to False. Everything else evaluates to True. Currently anything which is not 0 is False. Everything else is True. But deciding what is False and what isn't can be a little confusing. For example consider the following code: If 4 Print "4 is True" EndIf If 2 Print "2 is True" EndIf If 4 And 2 Print "4 And 2 are True" Else Print "4 And 2 are NOT True" EndIf --v This prints: "4 is True" "2 is True" "4 And 2 are NOT True" This is because the And and Or are bitwise And and Or not boolean. Although yes Blitz doesn't have a boolean type, it can be represented in the idea that certain things are True (like numbers which are not equal to 0) and some things are False (like 0). So in my example although 4 and 2 are valid representations of True, 4 And 2 yields False. Strings add more headaches as Blitz will convert a String to an Integer for evaluating the condition of an If statement and for the And and Or operators. So "0" is False whilst "1" is True. However "0" and "1" are not numbers they are Strings so they should evaluate to the same result. Strings starting with non-digit characters also always evaluate to False. "a" is no more False or True then any other non-empty String, such as "1". The language should reflect this. "" can also be a special case because it is empty. I propose changing the And and Or so that only an empty String, 0 or False evaluates to False. Everything else is considered True. The addition of bitwise operators If I change the And and Or so they are more boolean like and added Short-Circuiting then you can no longer use And and Or for bitwise operations. I propose adding bitwise And and Or as either the traditional \| and & symbols, or some other suggestion (maybe BAnd and BOr). This would also code more readable. For example: local a, b, c c = a And b --v Is the intention of 'a And b' a bitwise And or a boolean And? You cannot tell. If I change it to: local a, b, c c = a & b ; or c = a BAnd b --v You now know the user intended a bitwise And. Parameters will be evaluated right to left The current order of evaluating parameters is to evaluate the penultimate parameter first, then the last, then the rest in order reading right to left from the second-last parameter to the first. For example consider the following code: Function a() Print "a" End Function Function b() Print "b" End Function Function c() Print "c" End Function Function d() Print "d" End Function Function e() Print "e" End Function Function f() Print "f" End Function Function test(a, b, c, d, e, f) End Function test(a(), b(), c(), d(), e(), f()) WaitKey End --v Currently in Blitz Basic this prints: "e" "f" "d" "c" "b" "a" It is unlikely the user would expected this order unless told (it's also far less work for me if I change it ). If they always evaluate right to left then the output would be: "f" "e" "d" "c" "b" "a" Otherwise... I have other improvements in mind, such as local arrays, but I would rather propose them when I have more of the VM completed. What would other people like to see added to Blitz Basic? Joe.

Comments
Wednesday, 02 January 2008, 07:21
Phoenix	How advanced do you want to make this? Is your goal to make it simple, or do you want to add more complex things -- such as pointers, and OOP? I think that there could be a slight change to your DrawImage alpha idea, at least. Perhaps that command could be affected by Color()? That way, images could also be tinted with different colors. I like your other ideas though
Wednesday, 02 January 2008, 07:30
Jayenkai	1. Multiplication of Strings. For the mostpart a neat feature, but in the end, you could just use the String$ command.. because that's what that does! 2. Variable Declaration NO. Absolutely not. Being able to do that is what makes Basic Basic.. If you're going to do Java Basic, do it right, and leave random variables in. 3. Alpha Go for it. The whole point of this was to speed up the graphics, so you might as well go nuts with the gfx commands. 4. Short Circuiting Imagine your button function draws a button. if Mudown=0 and Button(x,y,"Happy Face!")=1 then Do Button Thing. Now, with Short Circuiting, if mudown=1, the button won't be drawn.. Your choice, but I'd personally leave it out if at all possible. 5. True/False So long as it makes sense, that's all that matters. If you're going to break Blitz, at least keep things logical! In my mind, False = 0, True = anything else. 6. And \| & If at all possible, shove both in. Let the coder decide which to use. AND should do what it did in Blitz, & and && should do what they do in C. 7. Right to left. Seems a bit illogical. If it's that hard, why not just read in the params, flip them around, then work backwards? I don't see why things have to go backwards! If it's not do-able, then I'm sure people can work around it. It won't matter in 99% of cases, anyway, since you usually deal with ALL the function's arguments within a single function.
Wednesday, 02 January 2008, 07:32
Jayenkai	In addition, I like your ,alpha addition, but it does need tweaking.. DrawImage Image, X, Y, Frame, Alpha, Rotation, Zoom ... Much better
Wednesday, 02 January 2008, 07:49
JL235	Jayenkai 2. Variable Declaration NO. Absolutely not. Being able to do that is what makes Basic Basic.. If you're going to do Java Basic, do it right, and leave random variables in. What about a 'Strict True' option to turn Strict on, like in BMax? People like you can have it off, people like me can have it on. Jayenkai 4. Short Circuiting Imagine your button function draws a button. if Mudown=0 and Button(x,y,"Happy Face!")=1 then Do Button Thing. Now, with Short Circuiting, if mudown=1, the button won't be drawn.. Your choice, but I'd personally leave it out if at all possible. If Button(x,y,"Happy Face!")=1 And mudown=1 Jayenkai 5. True/False So long as it makes sense, that's all that matters. If you're going to break Blitz, at least keep things logical! In my mind, False = 0, True = anything else. That's the idea. The problem is that currently in Blitz somethings which aren't 0 are also False like "foo". Jayenkai 6. And \| & If at all possible, shove both in. Let the coder decide which to use. AND should do what it did in Blitz, & and && should do what they do in C. I was thinking of adding both as well as for And and Or too, like in Ruby. So you have !, &&, \|\|, &, \|, Not, And, Or, BAnd, BOr. The user can then chose which they want to use. Jayenkai 7. Right to left. Seems a bit illogical. If it's that hard, why not just read in the params, flip them around, then work backwards? I don't see why things have to go backwards! If it's not do-able, then I'm sure people can work around it. It won't matter in 99% of cases, anyway, since you usually deal with ALL the function's arguments within a single function. I think you have misread my post. In Blitz the parameters are not read right to left or left to right. Instead it's a funny 'do the penultimate, then the last and finally the others right to left.' Right to left is closer to this then left to right and both right to left and left to right are easy to implement.
Wednesday, 02 January 2008, 07:55
Jayenkai	1. Yep, and option sounds best.. 4. OK, but what about 2 buttons? 6. Seems you'll be adding in hundreds of possible And's, then 7. Oh, sorry! You said "The current order", so I thought you were on about yours, not Blitz's.. Blitz does that!? Weird! Yeah, whatever works for that
Wednesday, 02 January 2008, 10:02
Scherererer	The ability to define optional parameters maybe look something like this: function myFunc(x, y, z, [a], [b], [c]) end function --v This is something I always used to miss because it was in the api, but you couldn't define your own custom functions with optional parameters. It is especially missed since there is no function overloading in blitz.
Wednesday, 02 January 2008, 11:07
Phoenix	There are already optional parameters: function myFunc(x, y, z, a=0, b=0, c=0) end function --v
Wednesday, 02 January 2008, 12:04
Scherererer	I didn't know you could do that!!!!!!!!!!!!!!!!! holy crap!!!!!!!! DD: Make sure you keep that feature, and maybe actually document it!
Wednesday, 02 January 2008, 12:11
JL235	Optional parameters can be achieved through using default values. I don't want to add function overloading because having no strict type system (I can pass a String as a parameter of type Float) and default parameter values makes it confusing. Potentially though when I add arrays to my VM I could maybe add the special array parameter thing you get in many languages. Something like: function printAll(a, b, array[*]) print "a is: " + a print "b is: " + b print "array contains the elements:" for i = 0 to ArraySize(array) print array[i] next end function printAll(1, 2, 3, 4, 5) --v Prints out: a is: 1 b is: 2 array contains the elements: 3 4 5 --v Essentially the last parameter can be an array which is filled with any excess parameters (which includes 0 excess parameters and so an empty array).

The multiplication of strings

All variables must be defined

Added alpha support

Adding Short Circuiting

"", 0 and False evaluates to False. Everything else evaluates to True.

The addition of bitwise operators

Parameters will be evaluated right to left

Otherwise...

Comments