BlitzC - A Blitz Syntax Alternative - Thoughts???

Blitz3D Forums/Blitz3D Programming/BlitzC - A Blitz Syntax Alternative - Thoughts???

Kram(Posted 2004) [#1]
Hi,

This is my first post - but I've been using Blitz for a couple of months now. I love Blitz's simplicity and functionality, but being a C# developer, I cant stand the BASIC syntax. Im sure most of you are comfortable with it, but in case you are not I have developed a syntax parser and have developed a whole application using blitz, but in a different (more compact c-like) syntax. Its actually more like a cross between the two. You dont have to have your whole application in the same syntax as well. By naming your file blah.cx - the converter will automatically convert it, and if you keep it as blah.bb, then no conversion takes place.

If you want to test it out, let me know all i post it later. Debugging is very difficult at the moment. There is much to improve. Here is an example of the syntax:


// include a bb file
#include <a_file.bb>
// include a cx (BlitzC) file
#include <another_file.cx>

/* 
 Use block comments like these
 to comment larger sections at a time.
*/

// declaring a type
type texture() {
	field cTexID$, cFilename$;
	field nWidth#, nHeight#;
	field nIndex;
}

// a while loop
while (condition = true) {
    if (this_condition = true) {
        debugLog("Condition is true.");
    } else {
        debugLog("Condition is false.");
    }
}

// standard function
function doStuff(cText$) {
    print("Printing " & cText);
    for(1 to 10 step 2) {
        print("A line");
        // break out of any loop
        break;
    }

    // create an instance of a type
    tTex.texture = New texture;
    tTex->cTexID$ = "texture 1";
    tTex->cFilename$ = "a texture filename";
}



// you get the picture


You see it not real C, C#, Java or anything, but its sort of similar and faster to code. Anyways, let me know your thoughts....

http://www.blitzbasic.com/toolbox/toolbox.php?tool=92


Rob(Posted 2004) [#2]
I see a lot of pointless syntax for no reason. Mostly redundant.

For example...
// a while loop
while (condition = true) {
    if (this_condition = true) {
        debugLog("Condition is true.");
    } else {
        debugLog("Condition is false.");
    }
}

Is cleaner in basic.
; a while loop
While condition = True
    If this_condition = True
        DebugLog "Condition is true."
    Else
        DebugLog "Condition is false."
    EndIf
Wend

And as such, can't possibly see a compelling reason why I should worry about the syntax any more than I have to. It really should be taken care of by the compiler and be more human-readible where possible.

Many aspects of C are now completely outdated.


Robert(Posted 2004) [#3]
Hi Kram,

I would certainly be interested in this. Rob (above) hates C (I quote: "Brackets are outdated"), so you're not going to win him over.

However a recent discussion on BlitzMAX showed that a number of people would be interested, and if you could get debug mode working well I would use it.


Kram(Posted 2004) [#4]
I understand you appreciate the Basic syntax, but this is for those who dont - eg, me. There are some aspects of C which are out dated, but the syntax certainly isn't. Take .net for example, you have VB.NET and C#. As with this, VB.NET and C# have almost the exact same functionality, but more programmers prefer to use C# as they are use to the syntax.

I personally see 'if (...) {' and '}' much easier to cope with then 'If ... Then' and 'End If'. Although its less verbose, its much neater (in my opinion). Anyways, im sure many others will share your opinion, but Im certain there are a couple who share mine.

Anyways, what is the harm in having an option, just like .net does??


degac(Posted 2004) [#5]
Personally I can't stand '{' and '}'. I hope to never see them in BlitzMax...


Rob(Posted 2004) [#6]
surely this kind of stuff is possible with a clever IDE.


Rhyolite(Posted 2004) [#7]
Good luck to you, I am sure it will be usefull to some peeps. I have to laugh because I started out in Basic (at school), then learnt Pascal, then C and UNIX shell stuff, then VB, then Blitz! Kinda goes around in circles, a bit like history and life!

Not sure which I prefer really. I definetly have a soft spot for Basic because that was the first language I learnt and takes me back to my ZX81, Spectrum and (of course) Amiga days. It amuses me to know see Basic doing all the things the 'big, powerful' (sarcasm here) languages can do (well, most of them - kinda!). I see no disadvantage/advantage in any modern language (Basic, C or whatever), more down to prefference and 'what you know' these days.

I find that C type stlye makes me 'focus' more and tends to lead to more concise code. I find Basic allows me to be more creative, probably because its more 'natural' (at least to me). Hmmm, I guess Basic is perfect for Blitz when I need to be creative but if I was writing code for a nuclear power plant maybe C would be better (although doing it in Basic would somehow be very entertaining!!!).

Oh, and yes, a good IDE helps any language a lot. I purchased one especialy for Blitz (best not mention name or may get linched by all the other IDE's - lol - but it begins with P!!).

Rhy's Waffle Over!!


AntonyWells(Posted 2004) [#8]
I think it's a great idea, but only if integrated into the regular blitz/ide pipeline. (I.e I can still hit compile and run. No messing about with commandlines etc) - One little tip is, rename the blitz compiler and then name your tool to blitzCC, that way it'll work with any ide, and this app of yours can then call the renamed compiler with the parsed source.



I'd much prefer {} over end function/end if etc


Warren(Posted 2004) [#9]
I like C++, but I don't see what the brackets are bringing to the table in this case. I hope to see them in BlitzMax, but I think Blitz as it stands is fine without them.


sswift(Posted 2004) [#10]
I hate brackets!


John Blackledge(Posted 2004) [#11]
Cheers Rob and sswiftt - Too Right!
I think my record was 157 compile errors due to one missing semicolon in Borland C.
Don't take me back to those nightmares!

A further thought is that it's always struck me that a good basic is FAR more difficult to write than a bracketed type language:
e.g. if (this=true) - must be easy to parse with everything bracketted.
But if this=true and that=false * 1/10 * pi - must be a nightmare, and full credits to Mark that his parser IS so competent, and allows us to think and code in a more human manner just concentrating on the logic of what we are doing, and not to have to cope with the idiosyncrasies of a lazily programmed compiler.


Big&(Posted 2004) [#12]
I like brackets (too many years writing C) but prefer to use them like this:

// a while loop
while (condition = true) 
{
    if (this_condition = true) 
    {
        debugLog("Condition is true.");
    }
    else
    {
        debugLog("Condition is false.");
    }
}



ZombieWoof(Posted 2004) [#13]
@kram: bring it on... I'm so tired of \ for types :)

and see if you can get == and != in there too :)

@John Blackedge: I guess you havent used any of the modern compilers... havent seen a error dump like that in a coupla years :)

@Rhyolite: followed much the same path as you, except sprinkle c, c++, java, and php around VB... still, I much prefer the {} syntax as most of the languages I work with use it :) Still... I'm pretty much language neutral... if the runtime has the functions, it doesnt really matter what language I write the code in.

@kram: my only complaint with your sample is -> for accessors... figure out some way to track type/field names so you know when you need to translate to "." or "\" so we can use "." all the time :) (the other features I would be interested in would require a full LALR parser, and it looks like you are just doing substitution, so we wont go there for now :)


Warren(Posted 2004) [#14]
debuglog "Condition is "+(this_condition?"true":"false")+"."

Awww, yeah!! ;)


Beaker(Posted 2004) [#15]
I think this is a good idea. A way around the debug problem is to keep all the lines in sync. Something else that might be interesting to experiment with is only using close brackets, the open brackets being implied by the context as they are in BASIC.

It would be good if it were extremely configurable with otions to turn everything on and off. A good example is that there isn't much reason to do Types as you have above, its actually longer to type.


Synchronist(Posted 2004) [#16]
I'm with Big&! That's how I use 'em...


DrakeX(Posted 2004) [#17]
epicboy - i'm not sure if you could do that, as all this thing is is a text replacer. you can't add operators ;)

though if it were made smart enough, it would be able to compile it into an if/else/endif construct.


daaan(Posted 2004) [#18]
hey guys, come on! i mean, using brackets looks sooooo much cooler! so when you show your friends the code they'll think you are a actual programer! (nothing against basic, and if you can't tell by now im being sarcastic) i do belive it should be an option. i feel that blitz should be the engine but the scripting language shoulder be the choice of the scripter.


Bot Builder(Posted 2004) [#19]
Lol.That's no argument :P A: Your friends (at least mine) won't understand much of it anyway B: The old "why not use C++ then" argument

Kram - you could have your proggie between the IDE and the compiler (like Michael's Preproc). I'm not against brackets, but definitly won't be using it.


JoshK(Posted 2004) [#20]
So the convoluted syntax of C and the slowness of Blitz? Great idea.


ZombieWoof(Posted 2004) [#21]
geeez -- why not just go all out -- to heck with BlitzCC completely (or keep it as a generic basic compiler)... create a DLL with the blitz core for BlitzCC/VB/C++ and .Net wrapper for VB.Net and C# -- let peeps pick any language that supports DDLs or COM (which includes borland C++ builder, Delphi, and even Java with a little extra JNI work).

When it gets right down to it... its the engine, not the language that counts.


N(Posted 2004) [#22]
create a DLL with the blitz core for BlitzCC/VB/C++ and .Net wrapper for VB.Net and C#


Why stop there? Make it cross-platform, let everyone have the joy that is BlitzBasic.

Just to note, I don't like the way you're doing the whole 'new type' thing, I prefer typing stuff like:

CKillerRabbit krA
krA.fluffiness = 200000000


It wouldn't be too hard to do that, really. You just have to actually parse the line and not just replace bits and pieces of text in it but compare it to existing types.


Barnabius(Posted 2004) [#23]
Mmmm... FORTRAN did it for many decades (and is still doing it) without { or }
Many other languages, which are just as capable as C or C++ don't need them, too.
Also... if the programmer is not a neat type (most of us are not) C code tends to be rather unreadable.

Leave our BASIC as it is, please. ;-)

@Rhyolite: I was developing software for nuclear power plant testing and control and I can tell you that there's very little C in most critical areas. We've done a lot of critical stuff in proprietary version of FORTH, which btw. is an excellent control language with a very (and I mean very) weird syntax to the uninitiated.

Barney


N(Posted 2004) [#24]
Leave our BASIC as it is, please. ;-)


He's not permanently changing it and he's not forcing it on you, so this request is absolutely pointless.

By the way, if you want very weird syntax, look at PATH: http://pathlang.sourceforge.net/


Warren(Posted 2004) [#25]
So the convoluted syntax of C and the slowness of Blitz? Great idea.

Best. Troll. Ever.


John Blackledge(Posted 2004) [#26]
@Barnabius "Leave our BASIC as it is, please. ;-)" Thank you!

@Rhyolite. I was in nuclear for nearly 10 years and never used C or C++. And never used Windows! - Jesus, they wouldn't chance it, or we might learn the true meaning of the phrase 'the blue screen of death'!

God forbid that Mark is reading this thread.
Mark, please, leave it the way it is.


Bot Builder(Posted 2004) [#27]
I believe Mark said at some point that he will leave it the way it is.

I'm not even sure why people write stuff like brainf$%^ (I wonder if the mods would care) or path... Makes no since. If you want stuff like that use ASM. Maybe they just want the thrill of writing an interpreter in 50 lines or somthing :P I'd like to see a DirectX game written in Path... OMG (cue for a very large map of random senseless symbols to pop up, along with a window with a cube rotating in it :D)


LAB[au](Posted 2004) [#28]
PATH is really wierd ... and fascinating! It's somekind of mutant ... in between Basic/C and Building Blocks environment (flowchart) like Max MSP / Eyesweb / Virtools / Puredata


Bot Builder(Posted 2004) [#29]
Maybe mark will adopt the path syntax for blitzmax:

             /Type\
$If a=5\     "    C
       T     o    a
       h     o    r
       e     m    *
       n     "    *
       \Print/    *
     /#deepS dleiF/
     M
     e
     t
     h
     o
     d   epyT dnE\
     \Crash\     d
           P     o
           l     h
           a     t
           y     e
           S     M
           o
           u     d
           n     n
           d     E
           \crash/


Almost easier than brackets....


EOF(Posted 2004) [#30]
I detest the C syntax.
It's very difficult to spot any coding mistakes..
Example. What error(s) have I made here?

// a while loop
while (condition = true) {
    if (this_condition = true) 
        debugLog("Condition is true.");
    } else {
        debugLog("Condition is false.")
    }
}

All those {} ; characters make it difficult to SEE what's going on. This is much easier to decipher:

' a while loop
while (condition = true)
 if (this_condition = true)
   debugLog "Condition is true."
 else
   debugLog "Condition is false."
 endif
wend



Bot Builder(Posted 2004) [#31]
lol let see.... Left of a semi colon, = needs to be ==, missing bracket after if. In other words, after putting it into a C compiler, 4 "syntax errors" in places they didn't actually happen...


Warren(Posted 2004) [#32]
If you format your code in a decent manner, the error becomes obvious:
// a while loop
while (condition = true)
{
    if (this_condition = true) 
        debugLog("Condition is true.");
    } 
    else 
    {
        debugLog("Condition is false.")
    }
}

And it becomes obvious BECAUSE of the "evil" braces.


Warren(Posted 2004) [#33]
Or, written as an actual C program would be:
while( condition )
{
    if( this_condition ) 
        debugLog("Condition is true.");
    else 
        debugLog("Condition is false.");
}

Complete with all errors fixed and leveraging the language properly.


N(Posted 2004) [#34]
The latter of your corrections, obviously, looks far better and doesn't use the unneccessary, EpicBoy. Good job.


Rhyolite(Posted 2004) [#35]
Hehe. Apologies to everyone in the nuclear programming industry, my previous statement was based on absolutly no knowledge in that field of expertise whatsoever (I mainly work with binary load lifters)! I am VERY glad to hear they don't use windows ;o) I picked nuclear energy as being kinda serious and a bit glamourous(???). Dont expect it is very glamourous though? I remember being really jealous of a work mate who used to program military stuff, but he said he mainly wrote boring sub-routines that could have been for anything. Hmmm, its late and I am waffling as usual...

Oh (and to get back on topic, errr kinda of), decided to pin my colours to the mast and proclaim no brackets and Basic as my preferred language (but have nothing against C - which I still use - or FORTH or its derivatives or any other language).

@Kram: Keep up the work on your parser, seems like quite a few folk are interested.

Rhy Out


podperson(Posted 2004) [#36]
One of the advantages of Modula-2-like programming languages (including BlitzBasic) is that closures are typed...

if

end if

vs.

if {

}

A common problem when reading code written in C-style languages is figuring out which closure goes with which. A lot of formal programming methodologies require something like this:

if {

} /* if */

Once you actually start trying to work on large projects with multiple programmers in C-type languages, most of the added "efficiency" of C (i.e. it's terseness) becomes a liability and project standards are implemented which force everyone to do a ton of extra typing.

This eliminates the "efficiency" of C, while forcing C coders to learn relatively useless information (how to code according to some arbitrary standard) versus get on with their lives.

Back in the good old days, C was pretty weakly typed, everything except floats could be treated as integers or packed arrays of integers and all kinds of evil ("efficient") tricks took advantage of this. These tricks were SO POPULAR that ANSI C made them harder to do, C++ made them even harder to do, and Java made them impossible to do.

My favorite example of C's "efficiency" (EpicBoy refers to it obliquely in rewriting the earlier code example) is the fact that every project includes at least one bug caused by someone accidently coding something like:

if ( a = b ) {
// do something
}

If you don't know why this is a bug, then be glad you're not using an efficient C-like language.

"C++ -- instant legacy code."

P.S.

A lot of VB programmers prefer C# to VB.NET, but they don't prefer C# to VB. The problem with VB.NET wasn't its BASIC syntax, it was its total incompatibility with previous versions of VB combined with a corruption of its syntax to more greatly (but in a half-arsed way) resemble the plethora of Javascriptish scripting languages the world has become infested with (including VBscript).


Warren(Posted 2004) [#37]
If you don't know why this is a bug, then be glad you're not using an efficient C-like language.

However, the horror of that bug is also the beauty of C. The fact that that line of code is valid, rocks. And the fact that it could be doing a ton of real work, is awesome.

An override of the "=" operator can open up a lot of coolness.

It's advanced, sure, but it's nice to have that sort of power sometimes...


podperson(Posted 2004) [#38]
I think you're confusing terseness with efficiency.

There's no guarantee that this code compiles to especially efficient binary. Meanwhile, every coder I know considers this to be a significant cause of bugs. A language that makes it easy to write bad code that's hard to see sucks.

a := b
if (a <> 0) then

end if

is unlikely to be less efficient (when compiled) than

if (a = b){
}

The first example is HIGHLY unlikely to be an accident, whereas the second is quite possibly an accident, and it will waste someone's time figuring out whether it is or not one day.

Similarly:

a+=1

may be a very convenient construct, but there's no reason to expect it to compile to more efficient code than

a:=a+1

and

if (condition)

won't compile more efficiently than

if (condition == true)

C was designed to minimize keystrokes in large part because the guys who designed it were working over a very slow teletype connection and not because having unreadable code was deemed a virtue of itself.


LT(Posted 2004) [#39]
Podperson:I don't think it's a matter of compiling more efficient code, but lowering the number of keystrokes.

The += operator, for instance, makes more sense if your variable name happens to be longer, because you don't have to type it a second time.

thisObjectIndex = thisObjectIndex+1
vs.
thisObjectIndex+=1

Epic's one line example is cool because of how little space it takes up. Personally, I prefer to keep any given function that I type all on the screen at the same time, so I don't have to scroll.

The negative arguments here are completely useless, folks. If you don't want to use it, then don't.

Kram:I think that if you have to go outside of the IDE to use this, then it's not worth it. There's my two cents.


N(Posted 2004) [#40]
One thing I'd really like, if you continue this, Kram, is to be able to call functions in this manner:

CallToFunction(5,5,5
               7,7,7
               12,.5,80
               True,True,GL_BGRA) ;no particular function i'm quoting the arguments of


Keep it up, I really like the idea of this (I started writing one, but remembered I have business to attend to ;).


Kram(Posted 2004) [#41]
Hi again,

I appreciate the feedback!! Although I havent yet read all responses so forgive me.

To those who are concerned about me "ruining the blitz basic language" you honestly have nothing to fear about. Nobody is forced to adopt this syntax style. All it does is convert one syntax to another.

For those interested, it is linked to the IDE - you name it BlitzCC.exe (and rename the original to BlitCCompiler.exe), it recursively searches all your includes and converts any BlitzC files (creates equivalent .bb files) then calls the actual compiler to compile it all.

Either way I dont use the default IDE anyways, I use UltraEdit for proper syntax highlighting.

It appears many of you detest the c-style syntax. For me (and many others) C was my first language, then Java and now C# and VB.NET. I have written extremely large applications in VB and VB.NET for local government, utilities etc so im am use to the VB syntax - but to me it still dont like it.

I dont want Mark to spend time on syntax alternatives, I would rather him spend time on BlitzMax functionality.

Things like the following are possible:

// coming soon
i++;
i--;
i+=3;
i-=3;

// works now
// != doesnt work yet so you have to use <> still
if (i/(10*40) <> 30) { /* do something */ }

switch(i)
{
    case 1:
        functiona();
    default:
        // like case else
}



It doesn't just mass replace code, there is, believe it or not some intelligence behind it. I could even incorporate the BlitzBasic precompiler.

Anyways, dont be scared of it, just dont use it if you dont want to. I still have a quite bit of work to do on it before people can play with it.

I didnt originally intend to distribute it, but when I decided to use blitz for my latest project, I thought I would spend a bit of time writing my own syntax for it since it was a large application. Anyways, once I converted my original code to the new syntax, I shortend it by a few hundred lines and made it much easier to read - for both myself and the others on the development team.

If most people are not happy with the 'type->member' usage, then I can change it later (or make it configurable) or whatever.

Appreaciate your thoughts.


Kram(Posted 2004) [#42]
Also, people seem to think Im requesting this from Mark for BlitzMax or something. My original thread states I already developed this parser... im not asking Mark to do or change anything. Its purely optional.

@Rob: "surely this kind of stuff is possible with a clever IDE." - well its not at the moment... For blitz anyways


@halo: "So the convoluted syntax of C and the slowness of Blitz? Great idea." - C is only convoluted to people who are not use to it. With almost equal experience in both, I would much prefer to look at C.

@John Blackledge: "A further thought is that it's always struck me that a good basic is FAR more difficult to write than a bracketed type language" - BASIC uses newline characters for parsing as opposed to braces. In fact - some people would disagree completely. From a parsers point of view, looking for a matching brace and determining its corressponding statement can be harder than searching for a corressponding 'IF' for an 'END IF'.

And if people are concerned that reading braces can be confusing, then use simple best practices ie:

1) dont make your functions and code blockss 9999 lines long,

2) indent your code

People have been doing it for years without any fuss.

Look, I expected this sort of response since Blitz has always been basic. But that doesn't mean it always has to stay basic...

Im sure Mark is not a basic Nazi since he codes blitz in VC++. And to John Blackledge who said "God forbid Mark is not reading this thread..." have I in any way offended Mark for writing a tool that nobody has to use??? If I wrote a pascal parser for blitz does that mean I would have my registered blitz version disabled for life and be banned from the forum??

In retrospect it should entice more developers to consider using blitz due to its optional language syntax.

Cheers


ZombieWoof(Posted 2004) [#43]
@Kram: "If most people are not happy with the 'type->member' usage, then I can change it later (or make it configurable) or whatever." -- Truth to tell, I'm pretty much addicted to java/c# syntax now... dont see myself going back to C++ or VB for any new projects :) So there is my vote !!

@Noel: actually, seperating the engine from the language would make it easier to go cross platform as you have now seperated those parts that could be platform specific from those parts that are not.

Of course, by that time, it doesnt really matter what language you use on top of the engine, at most a wrapper is needed to interface the engine with a given language on any platform.

It also opens up Blitz to a larger audience... i.e. those that believe an engine that locks you into a custom language isnt worth the trouble to look at. An attitude that almost caused me to pass over Blitz... the only reason I'm giving Blitz a shot is the level of community support.


EOF(Posted 2004) [#44]
Mmm ... Just a idea ...

Anyone thought of doing this the other way around?
That is, convert Blitz code to C#?
Since I struggle to understand all that +=1 {}; [] stuff of C it would be interesting to see how a simple bit of Blitz code looks like in it's equivalent C format.

EG:

From
; a while loop
while condition = true
    if this_condition = true
        debugLog "Condition is true."
    else
        debugLog("Condition is false."
    endif
wend

To
// a while loop
while (condition = true) {
    if (this_condition = true) {
        debugLog("Condition is true.");
    } else {
        debugLog("Condition is false.");
    }
}



Kram(Posted 2004) [#45]
@JimB: I wouldnt bother writing a BlitzBasic > BlitzC converter since you would only have to convert it back to compile it.

Besides, like I was saying B4, its not real C, C++, Java C# etc. There is not and will not be any operator or method overloading, class management, object events, or even proper scoping (unless Mark makes it a feature of Blitz). You see, its an alternative syntax - no major extra functionality. Only small things.

However thats not to say that all these things aren't possible for blitz, but I just cant be bothered writing them for now.


podperson(Posted 2004) [#46]
LT -- saving keystrokes (beyond ridiculous levels) should not be a major issue in designing a programming language. Legibility of code and efficiency of compilation should be.

If your typing speed is a significant factor in the time it takes you to code, then saving a few keystrokes on += won't help you.

Most experienced programmers would gladly trade NOT being able to save a few keystrokes with if (a = b) for not having to debug code with an accidentally typed if (a = b) in it, just as most experienced programmers would prefer having to type explicit variable declarations over having to debug subtley mispelled variable names that don't throw compile errors (now there's a feature of C, or any number of languages, that BlitzBasic needs).

Kram -- I don't think there's any harm in what you're suggesting. I happen to think it's a waste of time (folks who prefer C-style coding languages can write their games in C++ ... that's a C-style coding language).

BlitzMax will use dot-syntax for dereferencing -- as many of other BASICs already do -- removing the ugliest feature of Blitz's synax and a big part of the aesthetic difference between BlitzMax and C.

Aside from that the differences will largely comprise (a) not having all of C's whacky operators, and (b) not using generic block structure... Mark doesn't strike me as a Basic Nazi, but as someone who knows that calling a language BlitzModula2 or BlitzAlgol wouldn't sell many copies... Folks who prefer Modula-2 over C know why they favor it and aren't easily swayed by folks who adore cryptic syntax such as a=b?c:d because it saves a few keystrokes or helps you win the annual obfuscated code competition.

http://www.ioccc.org/


Kram(Posted 2004) [#47]
@podperson: "folks who prefer C-style coding languages can write their games in C++ ... that's a C-style coding language" - Many have said that but thats missing the point completely. I chose blitz because of its simplicity, not because of its use of basic. No matter what engine you use, writing an application in C++ or C will always take much longer then in Blitz, but this way, you can use blitz's functionality with your own choice of syntax.

Basic has been around for a long time, and so has C. At university, basic was never part of the core curriculum. Its been C, C++ and Java for years now - well at my uni anyway. I know many people who would much prefer to use a C style syntax over basic, especially if it were as simple, mainly because it is more natural to the developer.

And whats with the whole "if (a=b) {" debate?? There is no operator overloading, so "if (a=b) {" will be equivalent to "if a = b then". If "if (a=b) {" passes the blitz compiler, then it also passes the parser. Its pure preference.

I also get the impression that many think the whole c style syntax is out of date???? If so, why wasn't Java or C# (being two of the 'newest' commercial languages - along with few others) written with "if .... then ... end if". VB.NET was made to suit existing VB and beginner developers, but by no means is it preferred choice - its purely up to the developer.


Im sure if I went to A6 or something and said "I have developed a basic interpreter for your C script", most of the developers would diss it and ask why, so i think it'll take a bit of time to sink in.

Im not concerned at all if nobody uses it, but I do and I love it.


Warren(Posted 2004) [#48]
For the record, my examples weren't meant to argue efficient code. They were to argue code brevity while still being readable.

All this fuss about not being able to read C code is kind of dumb since you're being thrown into the deep end here. If you spent a few hours with a beginners book on C, all the code in this thread would become crystal clear and you would see that it's a wonderfully concise and powerful language.

C is NOT a complex and hard to read language. It's just that you guys haven't learned it...


LT(Posted 2004) [#49]
@podperson:My argument was not about typing speed. Less code, in my view, is naturally more legible because there is less to wade through. Epic's example was better.


ZombieWoof(Posted 2004) [#50]
@podperson: " just as most experienced programmers would prefer having to type explicit variable declarations over having to debug subtley mispelled variable names that don't throw compile errors (now there's a feature of C, or any number of languages, that BlitzBasic needs). " == Thats what I was refering to when I mentioned WAY BACK needing a full LALR parser -- adding strong typing and not having to specify type as var.type for typed variables :) But then you need to keep a symbol table and track scope during translation.

once you go that far, you could take the YACC spec for any language and fairly easily write a translator to BB :)

@Kram: I dont expect you to go that far.. I've been programming 30 years and have written a couple of translators.. one YACC based... and it can be quite a headache.... however, if you are that crazy:
java: http://www.devincook.com/goldparser/download/grammar/Java-Dmitry-Gazko.zip
VB.Net: http://www.devincook.com/goldparser/download/grammar/visual-basic.net.zip

both use the GOLD parser engine: http://www.devincook.com/goldparser/index.htm
which is available in many languages, or as DLL or .Net assembly :)


Beaker(Posted 2004) [#51]
Kram - I use UE if you want a tester.


Kram(Posted 2004) [#52]
@MasterBreaker: I'll post it once I make debugging a little easier. Also its a .net executable, so anyone who wants to use it will need the .net runtime.

@EpicBoy: "If you spent a few hours with a beginners book on C, all the code in this thread would become crystal clear and you would see that it's a wonderfully concise and powerful language." - I cant agree more.

@ZombieWoof: Thanks for the reference, but I think I'll keep it as it is for now - simple. It works fine for me anyway.

Cheers


Synchronist(Posted 2004) [#53]
'scuse me. But what's the point of all this? Other than an interesting exercise, what is the overall gain? I'm not running down Kram's work, I'm just trying to understand what would be gained here. Blitz syntax is dirt simple as it is. Is this a "comfort level" thing?

BTW, I realize that I don't have to use it if I don't want to. Not trolling. Just asking...


N(Posted 2004) [#54]
CodeMeister: If I'm not mistaken, it's because he's more comfortable with C/C++/C# styled syntax, so the benefit is he can use Blitz without switching to a new syntax style, but rather continue using the one he likes. So yes, I suppose it is a '"comfort level" thing', as you put it.


Synchronist(Posted 2004) [#55]
^^That's cool. 8^) Innovation is a good thing...


big10p(Posted 2004) [#56]

C is NOT a complex and hard to read language.



That's true for the most part but things can get very hard to read sometimes. E.g.

char (*(*x[3])()())[5]


What is x?

Even if you are a long-standing C programmer, I bet deciphering that takes you a while (relatively speaking) - the syntax is certainly not immediately obvious.

You wouldn't actually come across something like that in C code very often - at least, I haven't - but the syntax is legitimate.

Don't get me wrong, I think C is a great language. I found it completely liberating when I learned to program in it effectively. I realize the syntax may not be to everyone's taste, though.

BTW, that example was from 'The C Programming Language' by Kernighan & Ritchie - i.e. the C Bible and best programming book I've ever read! And, if you're interested, the answer is:

x is array[3] of pointer to function returning pointer to array[5] of char

Gulp! :/


Bot Builder(Posted 2004) [#57]
Hehe. I am familiar with C/C++, but I don't use it much because I can never get it to do anything in 3D :=/ Probably because I insist on using free software but still. I also have a introductory version of MSVC++ 6 (cheap but you can't distribute anything) and I know from that that the debugger sucks - "syntax error" is not a very helpful error. Surely it knows that there is a missing semicolon or parenthesis or }. Not to say that C/C++ isn't a great language. If Blitz was a lib I could use with Dev C++ I wouldn't even use basic:

#include "Blitz.h"

int main(int argc, char* argv[])
{
	int cube;
	int cam;
	cube=CreateCube();

	cam=CreateCamera();
	PositionEnity(cam,0,0,-5); 
	
	while (KeyHit(1)==0)
	{
		TurnEntity(cube,1,1,1);
		RenderWorld();
		Flip();
	}

	return 0;
}


This'd be cool because then I'd actually put to use a language that is important to know for the computer proggraming business. Although, I hate those semicolons after each thing. I mean, there is an end of line charachter after each thing too. However, I'm not going to use somthing to convert my C code to basic because its pretty much pointless. I like the basic language anyway. The only reason at this point I would use C/C++ is for classes, usefullness in the "real world" of proggraming, and the speed boost.


Warren(Posted 2004) [#58]
big10p

Yeah, that line of code sucks for reading, but that's an extreme case that you could probably go your entire professional life and never see.


Kram(Posted 2004) [#59]
@bot builder: your code would actually look more like this with this syntax


cube=CreateCube();
cam=CreateCamera();

PositionEnity(cam,0,0,-5); 

while (KeyHit(1)=0)
{
	TurnEntity(cube,1,1,1);
	RenderWorld();
	Flip();
}




Bot Builder(Posted 2004) [#60]
Well yeah, see, that's just imitating C for your purposes which is great if you are familiar with that syntax, however, I would like to use a real C/C++ compiler along with a lib that imitated blitz for speed. My routines would be really fast then. Ah well. Bmax, Bmax.... Mainly I'm worried about ever getting a computer proggramming job if I'm constantly using basic.


N(Posted 2004) [#61]
I've written a sortof 'translator' for my own syntax for Blitz now. Basically, it takes code like:

float yourFunction( A#, B# )
     Return A*B;
}

C# = yourFunction( Rnd(1,200),Rnd(1,200) );

D# = C#;
for N% = 0 to 200
     D++;
}

// pseudo-C styled syntax

D# -= Rnd(64);
D# /= Rnd(64);
D# *= Rnd(32);
D# --;

Print D#;


;; NOPARSE
; NOPARSE areas are areas that do not get parsed by the translator

If D# > 0 Then
     Print "> 0"
Else
     Print "< 0"
EndIf

;; OPENPARSE

E% = Rand(4)
switch e
     case 0;
          print "case 0";
     case 1;
          print "case 1";
     case 2;
          print "case 2";
     case 3;
          print "case 3";
     case 4;
          print "case 4";
}


And it translates that code into (in all of my tests at least) working BlitzBasic code. It only parses files with the extension 'bc'. You can include files that won't be parsed by just including normal 'bb' files, but if you include a 'bc' file then it will be parsed accordingly unless you wrap the include instruction in the ;; NOPARSE/;; OPENPARSE tags.

So, operators like +=, -=, /=, *=, ==, !=, ++, --, etc. are useable, you have curly brackets, etc. Inside of strings, in order to make it less of a pain in the fingers to add quotes, you can also use \" to escape the character (I recall escape being the proper term).

I'm considering defining a language sheet which lets you customize what these operators are exactly, but right now they're all hard-coded.

Also, opening brackets aren't used because, basically, they don't need to be used in these cases.

It's really fun writing this thing, might even help some people- who knows.


poopla(Posted 2004) [#62]
oh. my. god.

That is ugly.


Dreamora(Posted 2004) [#63]
If you are able to create a parser that supports OOP it would be an interesting alternativ ... others: no *ggg*


martonic(Posted 2004) [#64]
Hi! I may be wrong, but I don't find a "continue" in BlitzBasic - is it possible? For instance:

For k = 1 To 100
; Do something
If (condition) Next ;Parser throws an error here!
; Do something else
Next

That is something I take for granted in C, but don't find in BlitzBasic. You could write:

For k = 1 To 100
; Do something
If (condition=False) Then
; Do something else
Endif
Next

However, with complex logic it gets messier and messier with no "Continue" option - or is there one? Thanks.


Bot Builder(Posted 2004) [#65]
Ah. that would be a good feature request, but you can do it the somewhat messy way:
For k=1 to 100
 ;Do Somthing
 If condition Then Goto Continue1
 ;Do Somthing Else
 .Continue1
Next



N(Posted 2004) [#66]
If you're feeling really bored, you should check mine out. If anything, it's a laugh to mess around with.

Linky


RiverRatt(Posted 2004) [#67]
I think that turning blitz code into C++ would be a very cool thing. But I don't know C or much about compilers,
but if you could do it you should, and you and Mark would
rule the world.

"I wouldnt bother writing a BlitzBasic > BlitzC converter since you would only have to convert it back to compile it."
Would this still be true if you recompiled the code in C++
or C compiler?


dooz(Posted 2004) [#68]
I've created a OOP-like preprocessor for Blitz - I was sick of the disconnect b/n functions and types. It goes something like this:

Type Color
Field r
Field g
Field b

Method Color(r, g, b)
\r = r
\g = g
\b = b
End Method
End Type

Abstract Type Shape
Field x
Field y

Abstract Method draw(c.Color)
End Type

Type Square Extends Shape
Field size

Method Square(size)
\size = size
End Method

Method draw(c.Color)
c\apply()
rect \x, \y, \size, \size, 1
End Method
End Type

Type Main
Method main()
c.Color = new Color(255, 0, 0)
s.Shape = new Square(50) ; Could also be s.Square = new Square(50)
s\draw(c)
End Method
End Type

There are a few other things, but that's mostly it. Time to flame!!!


RiverRatt(Posted 2004) [#69]
Do you have comlete code for it so I can see it run? See
what it does?


Warren(Posted 2004) [#70]
Yeah, I would love to see the resulting Blitz code!


Rogue Vector(Posted 2004) [#71]
I like it. I like it alot.

But, to make it even cooler, add Public, Private and Protected status to the fields.

Regards,

Rogue Vector


N(Posted 2004) [#72]
dooz: If I can use your preprocessor I'll worship you daily -_-


*(Posted 2004) [#73]

// include a bb file
#include <a_file.bb>
// include a cx (BlitzC) file
#include <another_file.cx>

/*
Use block comments like these
to comment larger sections at a time.
*/

// declaring a type
type texture() {
field cTexID$, cFilename$;
field nWidth#, nHeight#;
field nIndex;
}

// a while loop
while (condition = true) {
if (this_condition = true) {
debugLog("Condition is true.");
} else {
debugLog("Condition is false.");
}
}

// standard function
function(cText$) {
print("Printing " & cText);
for(1 to 10 step 2) {
print("A line");
}

// create an instance of a type
tTex.texture = New texture;
tTex->cTexID$ = "texture 1";
tTex->cFilename$ = "a texture filename";
}

// you get the picture



I still prefer the full C/C++ command set personally =)

// include a bb file
#include <a_file.bb>
// include a cx (BlitzC) file
#include <another_file.cx>

/* 
 Use block comments like these
 to comment larger sections at a time.
*/

// declaring a type
struct {
	char cTexID[255], cFilename[255];
	float nWidth, nHeight;
	int nIndex;
}

// a while loop
while (condition == true) {
    if (this_condition == true) {
        debugLog("Condition is true.");
    } else {
        debugLog("Condition is false.");
    }
}
...


Coming from a pre-games PC market (I still remember Wordstar and Lotus 1-2-3 (the dos version not the CD version), im an old C hack (started on Turbo C before migrating to proper C then C++). TBH if you want to code in C or make Blitz C like you should be using C :).


ZombieWoof(Posted 2004) [#74]
@dooz: hand your code over to Kram so he can build it into his setup :)

@EdzUp: gimme an engine as simple to use, and with as much community support as Blitz, but with C/C++/C# as the language and you'll make my day :) I've looked at most out there and Blitz is simple enough for fast ramp up, but plenty powerful for doing decent games once you have the basics down. It would have been just as simple to use had Blitz3D been an engine library for c/c++.

It just gets back to my point that the engine could be seperated from the language easily enough, and the engine wrapped up to be usable with any language. Language is a matter of personal preference, engine functionality is language independent.

I'm not even saying get rid of BlitzBasic... just seperate the engine so that if you want another language, its easy enough to hook the library and GO. Its then the problem of the people that use other languages to translate the samples into their language of choice.


Kram(Posted 2004) [#75]
@dooz: Can you post your code? I would love to see the resultant code? Even post th resultant code to what you have put up there? I thought of going OO, but i thought Id wait till bmax instead - despite the fact it isnt true OO...


Kram(Posted 2004) [#76]
@ZombieWoof: I agree. The ultimate option would be for a seperate engine. Im sure it wouldn't be hard to use the blitz runtime dll in your own app. But until then, this'll have to do.


UByte(Posted 2004) [#77]
I considered doing a C-like pre-processor, not purely to get a C syntax but to wrap Blitz's bank commands into c-like arrays and pointers. This would have allowed arrays in types, castable types, pointer arithmetic and so forth.

But with Blitz-Max rapidly approaching I suspect an effort to do this would be redundant.


JoshK(Posted 2004) [#78]
While condition
  If this_condition s$="Condition is true." else s="Condition is false."
  Debuglog s
  Wend



AntonyWells(Posted 2004) [#79]
Umm..... What?


Warren(Posted 2004) [#80]
Don't go there, it isn't worth it. Halo's time is very valuable and he doesn't have time to explain himself to the likes of you. Now, if you'll excuse him, he has another political flame war thread to start up...


Craig H. Nisbet(Posted 2004) [#81]
I know both C and Basic now. C = confusing, Basic = simple and readable. I like basic. Although I like some of the features of the C language, like pointers.


Warren(Posted 2004) [#82]
If you find C confusing, it could be argued that you don't really know it.


Bot Builder(Posted 2004) [#83]
Maybe the point is it's alot harder to learn C thus making it generally more confusing, while basic is pretty easy to pick up.


AntonyWells(Posted 2004) [#84]

Now, if you'll excuse him, he has another political flame war thread to start up



The govermount made him, now they can't stop him. Policop...the robotic menance to south central, whilst coding his code in the hood. Maybe.


I know both C and Basic now. C = confusing, Basic = simple and readable. I like basic. Although I like some of the features of the C language, like pointers.


C is easy. WinAPI on the other hand is a proven torture method of the NSA.


N(Posted 2004) [#85]
WinAPI on the other hand is a proven torture method of the NSA.


You can say that again. But if you have any common sense, you won't.


AntonyWells(Posted 2004) [#86]
Oh go on then, tell me how winApi is a wonderfully well designed api, and everyone just loves it, except those who don't understand it of course.

Common sense is never putting yourself into a situration where you need to code winAPI.


N(Posted 2004) [#87]
Oh go on then, tell me how winApi is a wonderfully well designed api


Why bother? I hate it. To clear anything up, did you interpret my reply as suggesting that you were wrong in saying that it's worse than being strapped to an anthill (how you could get strapped to an anthill I do not know, but it sounded right), covered in honey, while naked?


martonic(Posted 2004) [#88]
Here is something easy to do in C, that I really miss in Blitz3d. But maybe it's there and I just don't know it.

Is there any way (other than inserting ; before each line) to "comment out" a section of code? Thanks.


Kram(Posted 2004) [#89]
@martonic: Im not sure if its available in Blitz3D but with the BlitzC parser you can just use /* */


Warren(Posted 2004) [#90]
Blitz3D has no native way of doing this. The only way to hack it is to do something like:

if 0
    ...your code here...
endif


But even then it sort of sucks because the code within the if block still has to compile successfully. Sometimes you just want code to "go away" for a short while... block commenting would be nice.


big10p(Posted 2004) [#91]
Yes, that's another thing I really miss from C, too. :)


Kram(Posted 2004) [#92]
just implemented continue, and break:


for (i=1 to 10) 
{
    if (this = true) 
    {
        continue; 
    } else {
        break;
    }
}




skidracer(Posted 2004) [#93]
Some people will do anything to avoid writing a game.


I would imagine if you install mingw, you could also use a proper C preprocessor pretty easily on your blitz source with something like (untested):

gcc -E -o progout.bb progin.bb


N(Posted 2004) [#94]
I think mine is turning out nicely, now I can use methods and stuff.

Fun little thing to write.

Some people will do anything to avoid writing a game.


What if they don't want to write a game? Just wanna write weird little applications and stuff. Like preprocessors.


AntonyWells(Posted 2004) [#95]

Some people will do anything to avoid writing a game.


I would imagine if you install mingw, you could also use a proper C preprocessor pretty easily on your blitz source with something like (untested):

gcc -E -o progout.bb progin.bb


What about the actual ide though, is it possible to change highlighting/language rules? Not a biggie considering other people will write ides to do it anyway but still nice to have out of the box.


skidracer(Posted 2004) [#96]
If you write expanding macros the only place you would want to be looking at that source code would be in the debugger window.

To patch a preprocessor in I would have thought you rename bcc.exe as say b3dcc.exe and create a bcc.bat file that invokes first the preprocessor and then the b3dcc compiler. As far as the IDE is concerned it's then (again untested) integrated.


dooz(Posted 2004) [#97]
Sorry for the delay, but here's some example code for the OO stuff I posted a few days ago. It's called BBO and its a prototype to try.

http://www.doozey.com/bbo/bbo.zip


big10p(Posted 2004) [#98]

Some people will do anything to avoid writing a game.



lol. I think we've all been busted! :P


N(Posted 2004) [#99]
I'm really happy with what I can do so far:

Type Application
	Field W,H
	Field Title$
	Field Windowed
	Field BPP
	Field Uses3D
	Field Camera

	Method Application(Width=800,Height=600,BPP=32,Windowed=0,Uses3D=0,Title$="My Application")
		\W = Width
		\H = Height
		\Title = Title
		\BPP = BPP
		\Uses3D = Uses3D
		\Windowed = Windowed
		If \Uses3D Then
		   Graphics3D \W,\H,\BPP,1+\Windowed
		   \Camera = CreateCamera()
		Else
		    Graphics \W,\H,\BPP,1+\Windowed
		EndIf

		AppTitle Title$,"Close application?"
	End Method

	Method MainLoop()
	       Repeat
	       	     UpdateWorld
	       	     RenderWorld
	       	     Text 4,4,Millisecs()
	       	     Flip
	       Until KeyHit(1)
	End Method

	Method GetCamera()
		Return \Camera
	End Method

	Method Free()
		FreeEntity \Camera
		ClearWorld
		EndGraphics
		Delete this
	End Method
End Type

Type Entity
     Field X#
     Field Y#
     Field Z#
     Field Pitch#
     Field Yaw#
     Field Roll#
     Field ObjHandle
End Type

Type Mesh Extends Entity
     Method Mesh(Path$)
     	    \ObjHandle = LoadMesh(Path$)
	End MEthod
End Type

Type Sprite Extends Entity
     Field Width
     Field Height
     Field Alpha
     Method Sprite(Path$,Alpha=1)
     	    \ObjHandle = LoadSprite(Path$,1+2*Alpha)
     End Method
End Type

Type AnimSprite Extends Sprite
     Field Frames
     Field CurrentFrame
     Method Sprite(Path$,Frames,Alpha=1)
     	    \Frames = Frames
     	    \ObjHandle = LoadSprite(Path$,1+2*Alpha)
     	End Method
End Type

Global A.Application = New Application(320,240,32,1,1,"Test")
YourCam = A\GetCamera()
A\MainLoop()
A\Free()


Really simple syntax as far as I'm concerned.


aCiD2(Posted 2004) [#100]
Where can i download Kram's?


N(Posted 2004) [#101]
I don't think he's released his yet.


Kram(Posted 2004) [#102]
I couldn't be bothered doing any more to it as it works fine for me now. If you can be bothered - check it out.

http://www.blitzbasic.com/toolbox/toolbox.php?tool=92


Tibit(Posted 2004) [#103]
Kram, Can one do:

If a <> 10 and b = 2 C=5 : a=0 : c=c+1 else b=b+1 :a = rnd(0,100):c=4 {

---Code---

}else{

}//if