A new programming language

[David]

What about creating a new programming language for calcs?
The two existing languages TI-BASIC and assembly has their pro's and con's, which the vast majority of us are familiar with. My idea is to combine elements from those languages (and others as well) into a brand new language.
Anyway, this new language needs to meet the following criterias:
-> Needs to be interpreted (like BASIC)
-> Programs must be executed significantly faster than TI-BASIC progs
-> Has to be relatively easy to learn.

Perhaps you could fill me in here.

What would your favourite calculator programming language look like?

[magicdanw]

I think it might not be such a bad idea to do a basic-like language, possibly with many of the same tokens to facilitate transition. I think one important thing though is to allow use of integers, because that would probably speed things up a lot! Also, local variables and functions should be included.

[Harrierfalcon]

I'd have to say that most of Basic's speed (or lack thereof) is due to the parser. A faster parser with better-written ROM calls would be much faster. And of course, a few more functions would be very handy .

So maybe, a hand-written ASM parser?

[TheStorm]

A hand written nostub no romcall parser that way to can run an any os version and is easyier to port plus runnable on third party oses

[nitacku]

This sounds awesome.

Make sure to include the xLIB functions. You could give them their own names instead of using real(. Having control over the On key would be cool as well. Would there be a way to create a function that could take the different layers of a grayscale picture/sprite and display it automatically without having to manually create the grayscale?

Example:
DrawGray( pic_layer_1, pic_layer_2 )
continue interpreting code while grayscale pic is being displayed...

Another thing to include would be multiple keypress recognition. Ability to archive/unarchive programs within programs would be nice. Also the ability to archive/unarchive pics without having to use a picture token would be nice.

So instead of:

Archive Pic1
Archive Pic2
Archive Pic3
Archive Pic...

You could have:

For(x,0,34)
ArcPic(x)
End

I'm assuming this is meant to be a gaming language. In this case it would not be necessary to include all of the commands that are available now. One more thing, a command to link two calcs together so that you could share data would be awesome. The current one sucks because both calcs have to be in a neutral/paused state in order for the transfer to work.

This is all that I can come up with right now.

[Demon]

Functions, classes, single- and multidimensional arrays (and you could use numbers or strings), local variables, ability to create/modify/delete other programs, appvars, or the parent program itself (writeback if to itself!), run and use other programs even if they are archived or are in a group (and the ability to unarchive/archive any datatype except for apps and groups), ExecASM command so you can run hex ASM code anywhere.

More ideas later.

[magicdanw]

If someone were to start this as a serious project, I think it would be best to work out a good parser that can understand functions and the binary operators, as well as a system of local variables. With that base, the rest of the language would be rather simple, since it would consist of defining functions to do stuff.

I have a friend who wrote a basic interpreted language on the computer. I'll see him in school (starts in a week), so maybe I'll ask if he has any ideas of how to begin. Maybe he'll also finally learn assembly code, and he could help out in the calculator community!

[DarkerLine]

The main things the TI-83+ basic lacks are, like magicdanw said, function and local variable capability. Graphics-wise, a reasonable minimum would be to allow storing and recalling pictures that take up part of the screen (essentially, sprites) to and from arbitrary points on the screen - given that, most other routines that libraries provide are not too difficult to code.

Taking a leaf (or a tree) out of the TI-89's book wouldn't hurt either - a lot of the things that would make TI-Basic better are there (of course, the TI-89 is crippled in Basic's inability to use the whole screen, which is painful)

Please, though - no classes. OOP in a calculator interpreted language is ridiculous.

[magicdanw]

What sort of stuff do the 89s do? I've never had the privilege of using any graphing calculator outside of the 83+ series.

I'm beginning to like this idea for a new language. It'd be tough to do, but maybe if I get bored with CalcUtil, and if I have spare time this year in school (hey, anything's possible, even with 5 APs and college prep), I'll try taking it up as a new project! :biggrin:

[DJ Omnimaga]

http://omnimaga.org/index.php?showforum=58
http://www.casiocalc.org/?showforum=18
this isnt too much like basic, but it's almost as easy, i hope THIS TIME it will not die tho, it used to back in the days of EPS programming team. It may even be compatible between casio and TI calcs as well, and between each ti calc models if it comes to fruition

[spandiv]

http://www.unitedti.org/index.php?showtopic=2857&hl=

[elfprince13]

personally I'd much prefer to see one of the existing projects finished (mlc, fastrpl, Spencer's scheme interpreter, that thing from DS (SLIDE?)), on the other hand it would be pretty cool to see an implementation of Python (not all the libraries of course, but the language itself).

[magicdanw]

elfprince13: Cool song in your signature! I guess I never noticed it before. I'm not into a lot of popular music, but instead I recognize words from a Swahili song! Go figure...

[baorder54]

time and time again, people have tried making hybrid languages/converters. All have failed or are unpopular. If you want better games than pure basic you use a lib, if you don't you use pure. If you want to learn asm then you learn asm and you make even faster games. I don't see where this "hybrid" fits in... slow, medium, fast. Thats what we have... do you really need anything inbetween? Seems like just another "avoid asm" scheme.

[magicdanw]

I personally think that the programming community could benefit from this, if it were ever done. I know there are plenty of people with great ideas for programs and games, but don't have the time/patience/skill to learn assembly code. If there were a language faster and more capable than basic, while not being as odd as assembly code can seem at times, then I think there would be even more cool stuff written for the calculator. One thing I'd like to see is a language that's stable like basic, but is more expandable, like with local variables, and being able to write functions. Some of these ideas I might carry out eventually in CalcUtil to a degree, but a new language would be a better solution.

[Harrierfalcon]

If this is a serious project, start with something that will run Basic progs, but faster. (Faster Parser, better-written ROM calls)

[Pseudoprogrammer]

You could make it into an app, that makes it so when you run a basic program it intercepts it and runs it through the faster parser automatically... What would said program be named if it was made

[magicdanw]

Well, I'm not sure what it would be called as it's own app, but if I was the one who made it, I'd stick it in CalcUtil2 as an option, so it all could be run out of archive and it could run shell programs, as well as the other stuff I plan to add to CalcUtil. Maybe I'd call the option "SuperParser" :biggrin:

[DarkerLine]

[David]