Source Code example

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

JL235	Created : 05 January 2008 Edited : 05 January 2008 Source Code example
Previously I said I was planning to be close to Blitz. The more I think about it the more I want to put my stamp on this language. So here is the first example piece of source code I plan for my language to look like. Const UNIT_SIZE = 20 Type Unit Field x Field y End Type // an array of type Unit Dim units:Unit // For is a function which in this case yields the values 0 to 10 // In this example I don't need a variable for the loop // (like i or n) so I just miss it out For(10) do unit:Unit = New Unit unit.x = 10 unit.y = 20 // pushes a unit onto the units array units << unit EndDo // start main loop // will use strings instead of numbers For keys While Not KeyDown("ESCAPE") Cls // red with a hint of blue and green Color 200, 50, 60 // the function 'Each' yields each Unit in turn // from the array 'units' into the variable 'unit' Each(units) do \|unit:Unit\| Rect unit.x, unit.y, UNIT_SIZE, UNIT_SIZE EndDo Flip Wend End --v The first thing you might notice are the comments, which will be using the C style of comments of // and /* / for block comments. They are quick to write, not very intrusive and most people already use them. Next you might be wondering why the For loop is so different, and what Each is doing. They are not loops but functions! This is related to the keyword I will be adding 'yield' which yields a value out of a function and into a joining 'Do' block. With the For(10) it yields a value 10 times, but there is no variable to catch it because I don't need the value. With the Each(units) it is yielding each element in units into the variable 'unit' which will hold it. Types are also declared with ':' like 'unit:Unit'. Arrays are also not* of a fixed size. Instead you will be able to add and remove elements freely, like in the above example with the << operator. This also means there is no longer a global list for each type like in Blitz. You are free to make your own lists, or not, as you see fit. I will be using Strings rather then integers for the key values. I find "ESCAPE" says a lot more about what key I am checking then '47'. Finally a little more on the 'yield' keyword. It passes the value given to outside of the function into the associated block. When the block ends flow of the program is returned to where yield was called. For example the definition of the 'For' method would look something like: function for(max) local i = 0 while (i < max) yield i // pass i to the block outside this function i = i+1 wend end function --v All for loop will be performed using yield and blocks. I plan to have no for loops in the traditional sense. Since yield is a keyword the user will also be able to define their own loops to use with blocks! So what do you think? Joe.

Comments
Saturday, 05 January 2008, 16:00
Phoenix	I like that you're taking a step away from the Blitz-syntax. Not sure about the yielding though -- I guess I have to try it in action before making up my mind. It is good though that you're thinking outside the bounds of the traditions. (Flexibility is always handy, though) That Ruby pipe/bar syntax is ugly though (I am refering to "\|unit:Unit\|"), perhaps you should replace them with more conventional symbols; such as a set of parantheses. C-style comments are great though, I prefer them over the standard Blitz semicolons. And while I'm at it I'll ask a question: will you add the handy += -= /= and *= symbols? That would be great.
Saturday, 05 January 2008, 16:32
Dabz	I've been thinking about the yielding and Diablo said it would have multiple yeilding, which will be handy me thinks and will open up new avenues about how to put a bit of code together! As long as the scanner doesnt check my identifiers, this is coming along a treat and look forward to seeing it in action myself! Dabz
Saturday, 05 January 2008, 17:01
Jayenkai	I'm with Phoenix on the Pipe hating. Also, the word DO pisses me off to a bizarre extent. "OF COURSE 'DO' FFS, I'm not typing for the hell of it!" So, removal of DO would be most impressive. If you really need something to put at the start and end, shove {}'s on. No-one'll mind. I'm still in the mindset that you should leave the For command alone. It's been doing what it's been doing for years, without being messed with. For n=1 to 10: Next - People learnt that years ago, they should still be able to use it. Every For loop in existance is nothing more than a Repeat or While loop. If we want fancy one's, we'll use those. For should be For.
Saturday, 05 January 2008, 17:05
JL235	The shorter operators I will be adding, however I haven't yet decided how. I could either add them as extra symbols and VM commands, or do what Ruby does and do some sort of conversion (x += 5 becomes x = x+5). The latter could potentially allow me to do += for any operator (@=?) I plan to allow multiple values for yield, so you could do something like: function EachUnitXY(array[]:Units) Each(array) Do \|unit:Unit\| yield unit.x, unit.y EndDo end function EachUnitXY(units) Do \|x, y\| print "unit, x: " + x + " y: " + y EndDo --v I'll bear what you say about parentheses instead of pipes on board, however pipes help to denote that they are block parameters. The alternate statement: EachUnitXY(units) Do (x, y) print "unit, x: " + x + " y: " + y EndDo --v I think pipes look better.
Sunday, 06 January 2008, 10:08
Phoenix	If you don't like the parantheses, I think you should consider Jay's idea; {}'s. Those pipes are awful!
Sunday, 06 January 2008, 11:19
JL235	In Ruby you can use { and } instead of do and end, so I might have that as an alternative. By convention you'd use the braces for single line blocks and do/end for multi line blocks. But the pipes themselves stay. each(units) {\|unit:Unit\| Rect unit.x, unit.y, UNIT_SIZE, UNIT_SIZE} --v
Tuesday, 08 January 2008, 13:40
Evil Roy Ferguso	I'm not fond of using pipes either -- I find them rather ugly. If you are against the use of ( and ), perhaps you could use [ and ]? They are still 'block-like' in appearance and they are entirely unambiguous in that position -- they couldn't possibly be subscripting the "Do" keyword, after all. \| x, y \| doesn't look "enclosed" within anything at all to me -- the start and end of a block of some sort must be visually distinct. I'd even prefer "BlockPs" and "EndBlockPs" to pipes. That's just me, though. I'd also prefer { and } over 'EndDo' -- but if you prefer a word to a brace, I feel that just "end" to end blocks (any block) would be preferable to 'EndDo.' Backwards compatibility is already broken and the existing "end" could be called something else -- perhaps "die" or "quit" or something. Again, that's just me. I'm very much in favor of the dynamically sized arrays and the mandatory declaration of variables -- I always declare all of my variables anyway. Yielding, too, is excellent. I feel sort of like the only one, but I like the new loop. Using strings for the keys seems a little odd to me -- is there a reason that you prefer them to constants? I would feel that something like KeyDown(KEY_ESCAPE) would be more natural -- but I'm sure there's a reason you're doing it this way. Still preferable to the 'magic numbers' Blitz currently uses. It brings to mind another question, though -- do you intend to implement a hashtable datatype? While they CAN be implemented in Blitz as-is, they're usually pretty ugly to use. In the end, it's your language and you ought to do what feels best to you. Congratulations on your work so far, and good luck with it in the future.
Tuesday, 08 January 2008, 18:31
JL235	Do is shorter then Block, which is why it's used instead. I'd mainly like to see two alternatives like in Ruby. This is for small blocks: for(10) {\|n\| print n} --v and big blocks: each(units) do \|unit:Unit\| // lots of collision code // lots of AI code // lots of drawing code EndDo --v However I do like changing End to something else, probably Exit, and then changing EndDo to just End. The reason it is EndDo is to follow on from EndIf, End Function, End Type and WEnd. [ and ] are exclusively for arrays, and I won't be changing that. Using ( and ) makes the Do look like a function. Unless there is another better suggestion, the pipes stay. Finally another source code example: Function EachEach(units) Each(units) do \|unit1:Unit\| Each(units) do \|unit2:Unit\| yield unit1, unit2 EndDo EndDo End Function EachEach(units) do \|a:Unit, b:Unit\| if unitCollision(a, b) // do something EndIf EndDo --v I agree hashtables should be there, but it is far from my top priority.
Wednesday, 09 January 2008, 14:00
Phoenix	How about this then? EachEach(units) do <a:Unit, b:Unit> if unitCollision(a, b) // do something EndIf EndDo --v
Wednesday, 09 January 2008, 14:07
JL235	Yeah, I like that. It's not already used and do look like brackets. They are also as easy to type as pipes. Would people really prefer < and >?
Wednesday, 09 January 2008, 14:34
mole	I prefer the <> over the \|\| The opening and closing is more defined and clear with <>
Wednesday, 09 January 2008, 15:30
Evil Roy Ferguso	I find < ... > to be much, much easier to read than \| ... \|, if you're willing to go that route. It also doesn't introduce the "hold on a second" that ( ... ) and [ ... ] do, so huttah.
Saturday, 12 January 2008, 06:30
Afr0	Jayenkai I'm still in the mindset that you should leave the For command alone. It's been doing what it's been doing for years, without being messed with. For n=1 to 10: Next - People learnt that years ago, they should still be able to use it. What about C for loops? They're like so; for(i = 0; i < 10; i++)
Saturday, 12 January 2008, 06:36
Jayenkai	Yeah, sure, but DD's initial aim was to make a Java Basic.. (in fact a Java Blitz)
Saturday, 12 January 2008, 06:54
JL235	Afro, they are far too long to write out and it's something I want to get away from. Jay, my aim was never to make a Java Basic. It's written in Java because I'm good at Java and so I'd rather concentrate on getting it made first rather then picking x language instead because "Java is slow" (as though making it in a different language will instantly make it fast and high performance). Since it was made in Java I did think it would be kinda nice to be able to incorporate Java into the code, but this won't be happening.

Source Code example

Comments