Page 1 of 4 123 ... LastLast
Results 1 to 10 of 33

Thread: Gumberoo - Making a new learning language intepreter using FPC

  1. #1

    Gumberoo - Making a new learning language intepreter using FPC

    Posting this across several forums... This is a bit lengthy a post, but it's because I'm going to outline my entire reasoning for starting this project.

    For some time I've been of the opinion that education on the whole is failing to... well, educate. Between teachers being paid more than twice that of the average citizen bankrupting our schools, to poor standardized test performance, social promotion, and kids graduating high school with what when I was a kid would have been considered a 4th grade reading level, it is painfully apparent to me that the entire "institutionalized" educational system is failing to deliver. There's a reason we're seeing budget cuts, program cuts, and even mass layoffs or outright firings. Just ask Providence, Rhode Island about that one.

    The gaps in what's being taught too -- like apparently physics is a single class at the junior high locally, that isn't even offered to standards level students?!? That's frightening to me.

    My ex-fiance was/is a math teacher, now studying up for her masters after a year of subbing, and everything she's told me reinforces this -- what the kids coming into her high school class had for knowledge being a fraction of what we were expected to know 30 years ago at the 4th grade level... much less concepts like "social promotion" and the rapid decline of results in standardized tests leading to the inexorable conclusion that modern school is little more than glorified daycare!

    NOT that from my time in the system roughly two or three decades ago delivered anything I use today past the 6th grade. My schools didn't even have computer classes; though certainly some of them had computers that were locked away due to a lack of qualified staff or at best used as typewriter replacements for the ONE typing course. (great when there were no printers).

    I think back to when I was learning -- and what did I REALLY learn to program on? I discount the Cosmac Elf because it was a limited toy more about learning the hardware side of things; but really it was the TRS-80 Model 1 and Color Computer, Atari 800, and the Commodore Vic-20 where I started actually being able to write software; Software that left my math teacher's jaws hanging open in wonder all before I even got to Junior High.

    I look at the state of computing today, and... where are the equivalents to ROM BASIC that a ten year old kid could sit down with something simple like say... "Getting Started with Extended Color Basic" and by the end of the book be able to write something simple like pong all on their own? Something they can sit down, turn the machine on and just start using?

    On the hardware side we have new devices like the Raspberry Pi -- cheap, simple... but on the software side they have it booting into Debian or Fedora and expect the people 'learning' to be alternating between gEdit and Bash? "for education" leaves me thinking they are aiming for college age -- in which case they're almost pricing themselves UNDER the market.

    Near as I can tell (and I'm three weeks into this) there is NO suitable language / development environment I would be comfortable handing to a ten year old like I would a C=64 to go with the Pi's "for education" concept. Sure there's talk of doing things like making it boot to a BBC emulator or porting BBC basic to it; but that's ridiculously crippled if authentic, a bit complex due to choices that were made due to hardware restrictions that no longer exist, and if you were to modernize it, why not at that point just make a new programming language?!?

    If nothing else, seriously, what is a child from today going to care about BBC Basic in terms of what they can do with it?

    More so since to make kids interested in learning; what made me and those of us interested in programming back then in the first place?

    Games? I know I wrote my share and typed my share of them out of magazines, and contributed my own to the various rags of the era.

    Music? All of you who spent hours on your C=64 making SID files or later on the Amiga MOD scene...

    Graphics? I remember being all impressed when I made my Coco draw Garfield on the screen using the DRAW statement...

    Combine graphics and music, and this is what the demoscene was all about! Democoders being some of the most hardcore programmers ever.

    Also when it comes to the pi, with the low price it would be a great entry level for the people who can't afford a modern PC or even a netbook/tablet... and if we're talking the poor why leave our dumpster diving friends with TV's out of the equation? The pi has a composite out, yet all the current software is pretty much MEANT for HDMI resolutions -- why not a 'old school' style 40x25 UI, since that's about the upper limit you can push composite anyways? (with 320x240 graphics underneath).

    ... and lets not leave out people who already have hardware; cross platform is easy these days what with SDL and OpenGL.

    So... I'm doing it. I'm making a new interpreted language with an immediate mode, in-built editing tools, with 40x25 text and 320x240 as it's primary targets (with support for higher resolutions).

    It will be called... Gumberoo; with it's mascot Menlo, the friendly Gumberoo. (as opposed to his evil cousin Anur, the baby eating Gumberoo)

    For those who don't know, the Gumberoo is a North American legend of a hairless bear with a thich black bullet resistant hide and long almost alligator like mouth full of teeth.

    Gumberoo was chosen because few people use the name, it's not trademarked to anything, the domain was available, and it sounds cute and friendly, even if the actual mythological creature was generally considered a monster. Taking a monster and making it friendly is nothing new -- Just look at Nessie or Ferdinand the Bull.

    I'm writing this entire project using Free Pascal, and I may switch to objectPascal syntax just to make it easier when it comes time to deal with xCode for iOS/OSX. I chose Pascal not just because it's the language I'm most comfortable with, but for code clarity and because FPC can now target a wide variety of languages, and now ships with working SDL and OpenGL on SDL units... that it can now target ARM, x86, AMD64/EM64T, PowerPC and even SPARC... is really the icing on the cake. Lands sake, it might be possible to build this for the Wii or DS... or at least make the interpreter work there.

    Besides, I'd sooner put a bullet in my head than deal with GCC. I'd sooner hand compile 8k of Z80 machine language than deal with 50 lines of C code.

    So far I'm working up several lists... Broken into subsections; "Development" means targets I can likely achieve unassisted and when complete will mean it's reached Beta status. "Final" are what will be required for it to be considered 1.0

    --------------------
    Target Audience
    --------------------
    4th graders and up. I want this to be interesting enough for making games to hook kids, advanced enough to still entertain adults, and

    --------------------
    Hardware/OS
    --------------------

    OS Platforms
    Development: Linux, Windows
    Final: OSX, iOS, Android

    CPU's
    Development: x86, AMD64/EM64T
    Final: ARM

    Minimum of 700mhz ARM8. (what's in the pi)

    Memory
    Should be able to run full featured in less than 32 megs free space. (basically half what's left over after a 'massive' Fedora install on the Pi)

    --------------------
    Language
    --------------------

    variable types -- there will only be three types of variables, "number", "string" and "array". Number will either be 64 bit double precision or 80 bit extended. With modern hardware there's no reason to confuse people new to programming with the difference between byte, word, dword, integer, longint, etc... If you add a number to a string it will auto-convert to string, If try to add a string to a number it will throw a error during tokenization.

    tokenizing editor -- per line editing much akin to the old line basic, but it will also let you scroll through the listing rather than using immediate mode commands like LIST. When you hit 'enter' to finish editing a line, the tokenizer will compile the line to bytecode.

    break/continue -- one thing interpreted basic used to provide was actually a very robust debugging tool in being able to break and continue code. You could ^C, or you could use a command like 'break' to halt execution, change the values of a variable or look at variables, type "continue" and it would... continue with your changed values. You don't get that from compiled languages...

    Immediate mode -- there are lots of new names for doing this, but the result is the same... you type in a line of code and it runs immediately, as opposed to 'deferred' where it runs later. Since I'm going to have the tokenizer compile by line, performing immediate mode operations should be simple.

    No Scope -- Scope is a very complex concept that I've repeatedly over the years seen confuse people new to programming. Let's get logic flow into their heads BEFORE we confuse them with scope.

    No userland objects -- objects are hard enough in a real language, much less in one without scope. It's a complex concept better left for better languages. Besides, user created objects in an interpreted language is most always a bad idea, and doesn't do objects proper justice. (see PHP)

    System Objects -- however, introducing the notion of system objects having properties and methods is simple, and can be considered a baby-step into the world of objects.

    Basically, provide objects, just don't confuse them by letting them try to make their own.

    No line numbers -- I might be patterning on ROM BASIC, but lets at least TRY to make this a real language.

    Labels -- since we don't have line numbers, we'll need something to point at. Rather than getting things all fancy with functions I'd like to keep it simple as line numbered basic was, so we'll have labels. Probably start them with a colon like in some assemblers.

    No user function calls -- we'll have subroutines, but to keep the tokenizer (and expression evaluator) clean and simple, we'll not introduce that concept.

    No return values -- since we lack scope and user made functions, there'll be no mechanism for RETURN to actually pass values.

    Pointers -- uhm, no...

    No Peek/Poke -- multi-platform from the start, there's no reason (and in some cases no way) to let people blindly access memory.

    Useful state based input handlers -- inkey$ sucked, readchar sucked, input really blows chunks if you're writing something realtime like a game... so I'm thinking a 'ifKeyDown' language construct to read if a key is pressed, and a 'inputmap' function letting you quickly map out what to do or call when a key is down during a logic loop. This is one of the things we used to have to peek into memory for in the first place.

    Sprite and animation engine -- The ability to assign a variable as a sprite, load textures from a png file, probably incorporate a simple sprite editor into it. This is something we'd have killed for back in the day, as even getImage/putImage and it's various equivalents across platforms were slow, painful and not that useful... I'm thinking on having these rendered using OpenGL and/or OpenGL ES so rotation, scaling and depth-sorting can be easily done. Also should incorporate collision detection.

    "world mapping" -- the ability to place tiles into a large 'world map' that can be scrolled around in the background.

    Backbuffered video -- a requirement for game animations that don't suck. Since I'm thinking OpenGL this is easy to do on the back end.

    Rudimentary automatic physics -- mono-directional gravity (Mario), radial gravity (SpaceWar), drag, possibly having automatic reactions for collisions like bounce rates.

    Audio playback -- likely WAV, Ogg or MP3.

    Simple multivoice composer -- piano-roll type tool for making your own music and being able to call it from inside your program.

    Programmable Synthesizer for making custom sound effects... I'm thinking multi-operator and introducing the concepts of ADSR, but in a simple way kids can grasp; kind of like what was built into a Casio VL-Tone, except having it sound good. A soft-synth would allow games to sound the same regardless of platform without relying on existing (or not existing) midi capabilites. If I could figure out the VL-tone at age 8, I figure a 10 to 12 year old can probably handle it today.

    I'm still playing with the syntax, but so far I'm aiming for a simple program to look something like this:

    Code:
      bufferVideo
      makeSprite player 32x32
      player.loadTiles "playerSprites.png"
      loadSound "thrust.wav",thrustSound
      
    :menu
      player.hide
      clear
      stopSounds
      at 0,16
      writeCentered "Simple Game Demo"
      write
      writeCentered "Press <SPACE> to Start"
      writeCentered "or <Q> to quit"
      inputMode buffered
      flushKeyBuffer
      renderFrame
      
    :menuKeyLoop
      inputMap
        = ' '
          jump gamestart
        = 'q','Q'
          jump exitgame
      endInputMap
      jump :menuKeyLoop
      
    :gameStart
      clear
      player.moveTo 0,0
      player.setMomentum 0,0
      player.setAngularGravity 180,10
      player.setDrag 1
      player.show
      
    :mainLoop
      renderFrame
      inputMap
        = "q"
          jump menu
        = "a",arrowLeft,numberPad4,digitalLeft
          player.addMomentumX -1
        = "d",arrorRight,numberPad6,digitalRight
          player.addMomentumX 1
        = "w",arrowUp,numberPad8,digitalUp
          player.addMomentumY -1
          player.setAnimationRow 2
          call thrust
        = "s",arrowDown,numberPad2,digitalDown
          player.addMomentumY 1
          player.setAnimationRow 2
          call thrust
      endInputMap
      jump mainLoop
      
    :thrust
      if thrustSound.stopped
        thrustSound.play
      else
        thrustSound.sustain
      endIf
      return
    
    :exitGame
      stopSounds
      clear
      writeCentered "Thanks for Playing"
    Very rough example of what I have in mind for language syntax and grammar.

    ... to be continued
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  2. #2
    ... continued

    In terms of status, right now I'm still struggling with getting my expression evaluation engine in place; I figured i'd tackle one of the toughest parts first. The tokenizer for expressions is working stellar, but I'm having trouble with function calls...

    3+(-2) returns 1, correct
    3+abs(-2) returns 5, correct
    (-2)+3 returns 1, correct
    abs(-2)+3 returns -5... WRONG.

    It's literally ignoring the closing parenthesis... I'm probably overlooking the obvious. Even with this minor bug it handles complex formula:

    5*(a-3)+2^8+6*b

    flawlessly. Function calls also run quickly because the tokenizer is compiling to state-based lookups, meaning when the interpreter gets to the token for a function, the next byte is an array index into the function list -- so I can call it thus:

    functionList[currentData^]^(expression);

    Where currentData^ is the current byte stored in the code, and expression is the function to evaluate what's inside the function call.

    The expression engine is a simple three stage expression/factor/value system... you call expression, it calls factor, which first calls value to, well... get a value to work with. Value checks to see if we're pulling an immediate, a function, or a variable, returns kind... factor then checks for a 'second stage' operator like multiply/divide/exponent, if present pulls a value and does it, if not it returns to expression which checks for first stage operations (addition/subtraction) and does those, again calling factor for their values.

    It's how I did it all those ages ago when I wrote a Clipper interpreter in DiBol (I should track down the code for that)... tried and true method. I think it's even how Prof. Wirth did it in his p-code interpreter. (as opposed to C with it's 17 stage nightmare)

    Means a wee bit of nesting, but nothing FPC can't handle.

    So the code is coming slowly. I'm working up a website for the project and hope to soon get that up live... but I've not really set up a time limit on getting this into the beta stage. I may release some binary demos before this goes beta, but for now I'm keeping the code private as, well... during development I don't work well with others. Once I have it to the point of text mode and input handling complete, I'll be opening up the code to the public.

    I have had suggestions to make a Kickstarter page for it. I'd like to get something to show for actual working tokenizer (read "caching bytecode compiler" in 'modernspeak') and interpreter first.

    Was also thinking on making the IDE web-aware, so kids could easily share their games online with others.

    So... good idea, crazy idea, who cares? Any ideas/suggestions welcome... well -- apart from "oh just write a book about python" or "why don't you make a UML implementation", in which case bugger off! Dealt with that already in two different places, and to me that's a sign that said individuals don't get the concept.

    Sorry for the long post... Wait, no I'm not; The TLDR crowd can kiss right off too!
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  3. #3
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    An interesting proposal. I think that anything that helps kids learn to program is great.

    There was a programming compiler/interpreter called Turing, named after Alan Turing, by some students at University of Toronto in Canada. It was used by many of the high schools in Toronto, including mine, to teach young people how to program. It took the medium to low level coding of the day and brought it up to a high level of code writing. It also took away much of the low level stuff you needed to do to add sound and graphics.

    I think that's important! Having an all in one solution so that new programmers don't have to learn "rocket science" before they learn how to simply "put a nail into a wooden board" at the beginning of everything they have to learn. It sort of kills the path to learning this great art form called programming.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  4. #4
    Update...

    Expression engine complete. Was a stupid mistake where I was treating the function as a expression start, while stilll tokeinizing the opening (

    So the problem WAS in the tokenizer after all. Finally, I can move on to actual line processing/execution, and variables.

    Though I also just belted out a couple test constants. PI and Deg2Rad.

    Deg2Rad=PI/180. You multiply degrees by that to turn it into radians... though since I'm NOT going to make SIN/COS/Arctan use radians, I guess that one's kinda pointless.

    Still, it's really cool to see it finally evaluate:

    Code:
    Enter expression or blank line to quit >64*sin(45*pi/180)+160
    result: 205.25483400
    From here should be smooth sailing, I actually consider that the hardest part of writing an interpreter. It even has error handling:
    Code:
    Enter expression or blank line to quit >160+64*sin(45*pi/180
    processing: 160+64*sin(45*pi/180
    Error in Expression: Closing Bracket Missing
      160+64*sin(45*pi/180
                         ^
    Which that's done at the tokenizer, so the actual interpreter part would never even get that code to try and run it. In the final version I plan for the EDITOR to not allow you to add such a line without fixing the error first.
    Last edited by deathshadow; 15-04-2012 at 08:00 PM.
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  5. #5
    That's a rather interesting project. But speaking frankly: lables and jumps are considered as bad programming, right? Shall in nowadays people start programming the "old" style (GOTO)?
    I also think that functions are elementary of a learning computer language. Even Pascal was invented to teach programming; see wikipedia article to Pascal:
    Initially, Pascal was largely, but not exclusively, intended to teach students structured programming.
    What about Lua?
    Just my two cents.
    Best regards,
    Cybermonkey

  6. #6
    Sounds like a very interesting project! Looking forward to more

  7. #7
    Quote Originally Posted by Cybermonkey View Post
    That's a rather interesting project. But speaking frankly: lables and jumps are considered as bad programming, right?
    Well, keep in mind I consider Assembly/Machine language to be simpler than C... and in ASM you only have jump or call. The difference between CALL and a function is... uhm... yeah. At most the difference being passing a result in a register or on the stack. Just be glad I rejected the idea I had of making conditionals work like machine language.

    While I've loved pascal from the day I first learned it on a DEC Rainbow, a lot of it's concepts and methods of working, like a number of more modern languages I feel require more time investment to do anything useful -- to that end there's python, but that has it's own host of issues and isn't entirely suited to what I want the projects focus to be.

    A lot of this comes from my recent putterings on the Apple II and VIC 20... Pascal had a number of conceptual hurdles I never had to deal with in line numbered BASIC... hurdles I didn't really make it past until I was a teenager. I'm trying to find a middle-ground between the two, without treading into the noodle-doodle land that Python does with classes.

    Again, I'm hoping to make it simple enough that with a decent manual a ten year old/4th grader could use it without adult intervention; which is why I reject python or even pascal. They make assumptions of knowledge and require certain amounts of programming theory, that honestly I glazed over at that age and gave up on before grasping them... Hell, I know adults today who glaze over on endless pages of theory going "where's the beef?".

    It's a big bun. A big fluffy bun. It's a very big bun...
    WHERE'S THE BEEF?

    In a lot of ways, I want to make what LOGO wanted to be but never was.
    Last edited by deathshadow; 16-04-2012 at 01:40 AM. Reason: added some clarification.
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  8. #8
    Quote Originally Posted by deathshadow View Post
    ...the noodle-doodle land that Python does with classes.
    hahaha!! nice description

  9. #9
    There is something that I can't seem to coperhand. Why would you limit numbers to 64 bit. Isn't this a waste of memory? I meand how often do you use nimbers greatear than 32 bit Integer in your games? Also won't using 64 bit integers considerably slow down all mathematical calculations when programs would be running on 32 bit operating systems.
    Also wich type of string would you use (Ansi, UTF-8, Unicode)? Having only ansi support will make your rograming language les interesting for any programer coming from Easten Europe, Asia, or any other country whic uses some aditional characters wich are not present in Ansi charset.

  10. #10
    Quote Originally Posted by SilverWarior View Post
    I meand how often do you use nimbers greatear than 32 bit Integer in your games?
    Since I'm planning on it being openGL aware, 32 bit floating point is likely the best minimum once rotations, gravity, momentum and drag are in the equation, much less the notion of resolution independent rendering. I considered single precision since that's what glFloat is guaranteed to be, but the max value limitation when dealing with non-integer values worried me and, well.. It plays to your second question about it:

    Quote Originally Posted by SilverWarior View Post
    Also won't using 64 bit integers considerably slow down all mathematical calculations when programs would be running on 32 bit operating systems.
    The speed concern did worry me, but given that interpreted languages were fast enough by the 386 era to make simple sprite based games, I'm really not all that worried about the speed of floats when the minimum target is a 700mhz ARM 8 or a multi-ghz machine with SSE operations available.

    ... and remember, even a 8087 math-co could handle 80 bit "extended" at a decent speed even at clocks below 8mhz... I should know, I have one in my Tandy 1000SX next to the NEC V20 running at 7.16mhz.

    Though that could just be I got used to targeting 4.77mhz on a 16 bit processor with a 8 bit data path that doesn't even have hardware sprites, I may be overestimating the capabilities of a 32 bit processor at almost 150 times that speed with blitting offloaded to the GPU.

    I don't want typecasting to get in the way of actually using the language, and if that means a bit of slowdown, so be it. It's something that pissed me off back on things like Apple Integer Basic where you didn't even have fractions... With 4th graders as the target, it's complex enough without confusing them on the difference between ordinal and real... much less the dozen or so integer widths, or half dozen real types. By the fourth grade they should be learning long division, so explaining why they get 5/2=2 is something to avoid until they put on the big boy pants and move to something like C, Pascal or Python.

    BASIC on the Coco only had 'numbers' -- and they were 32 bit numbers with 8 bits for the floating point on a 8 bit processor. (admittedly the semi-16 bit floating point monster 6809) -- and handled things just fine. If the 'slowdown' of 64 bit numbers when you have a math coprocessor DESIGNED to handle numbers that size is an issue, you're probably doing something wrong.

    Or am I really off-base with that type of thinking?

    I'm still thinking I might switch to 80 bit extended, though I'm going to test 32 bit single precision too; which is why I've defined my own "tReal" type so I can change it program-wide as needed.

    Quote Originally Posted by SilverWarior View Post
    Also wich type of string would you use (Ansi, UTF-8, Unicode)? Having only ansi support will make your rograming language les interesting for any programer coming from Easten Europe, Asia, or any other country whic uses some aditional characters wich are not present in Ansi charset.
    I'm arguing with myself over that because to be honest, I hate complex character sets; they are a needlessly complex mess that until recently (relatively speaking) weren't even involved on computers. I often feel that if we just restricted ourselves to 7 bit ASCII we wouldn't have a lot of the headaches that crop up on websites... and since my bread and butter the past decade has been websites; it's only further made me HATE languages or even normal text that requires anything more complex than that.

    Honestly, I'm tempted to restrict it to the character set used by a Apple IIe.

    BUT -- you are right, such ethnocentric views could limit the potential audience; something I'd like to avoid. At the same time, I'd be far, far more worried about the overhead of string processing UTF-8 into a raster based font system like my GLKernedFont method; which will be what it's going to run since being cross platform I can't rely on any specific engine being present, and freetype looks like ass and kerns text like a sweetly retarded crack addict.

    Also, converting even one complete UTF-8 font set to raster and making a kerning table for it doesn't rank all that high up on my to-do list either; Maybe if I got my auto-generator for the kerning table completed... THOUGH...

    I could at least start adding the code hooks to add extended codepage support; that way other people who want it elsewhere could add that support themselves once I go public with the first release and codebase. That might be the best approach since I'm not planning on this being a one man operation forever... just until I hit Beta.

    Partly to prove to myself I can still do this sort of thing. Past six years I've been retired due to failing health, and slowly weaning my clients off support... starting to feel like the mind is slipping, and this project isn't just about helping others, but also about proving something to myself.

    Well, that and I have some really weird ideas on how an interpreter should work - and want to test said ideas without getting led off-track.
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •