Calculator Community > HP Calculators

Source: It's a programming language. Now with HPPL support!

(1/14) > >>

iconmaster:
Once upon a time, I was writing programs for the HP Prime in HPPL. The more I worked in HPPL, the more I became dissatisfied with the language. I mean, it was usable, but I wanted better.

So I decided to make something better. I started work on Source. It's a programming language.

Source is a procedural, statically-typed bytecode-compiled language that can either compile to whatever platform you need or interpret directly on your computer. Currently, it compiles to HPPL.

Source gives you control. It's statically typed, so you can read your code more easily. It can assume types, so it's not needlessly verbose. You can control how it compiles through directives.

Source is flexible. It provides data structures and user types. You can define methods for data types anywhere. You can organise your code into packages. Source even can handle cyclic dependencies!

Source has tools. Compile it into HPPL from the command line, or use SourceBench to write and compile code on the fly. Use SourceBox to run your code on your PC. Run SourceLine to interactively execute Source code.

Source isn't done yet. The core libraries still need implemented, not to mention a bunch of features such as custom structs and classes. In the future, it will be able to compile to a bunch of places, not just HPPL. I wouldn't describe it as 'usable' yet. But stay tuned!

Anyways, the important bit: The link. Check out the source code at:

https://github.com/iconmaster5326/Source

Want to download Source? Want to learn more? Check out the wiki at:

https://github.com/iconmaster5326/Source/wiki

The wiki has downloads, documentation, and tutorials.

DJ Omnimaga:
Seems interesting. Since HP PPL is fast I think an alternate language that compiles to it could be very feasible, although an interpreted language would probably run as slow as 83+ BASIC or so. Just make sure, however, that the compiled code doesn't end up totally bloated or unoptimized, though.

One thing I would suggest is offering certain pre-made routines for sprites or maps, for example, with a decompressor, so that people could use different image formats that are smaller than the built-in ones. The resulting code would simply decompress the images into a GROB upon runtime.

iconmaster:

--- Quote from: DJ Omnimaga on June 25, 2014, 07:18:14 pm ---Seems interesting. Since HP PPL is fast I think an alternate language that compiles to it could be very feasible, although an interpreted language would probably run as slow as 83+ BASIC or so. Just make sure, however, that the compiled code doesn't end up totally bloated or unoptimized, though.

--- End quote ---
Yeah, an interpreted language isn't a good idea for speed here. Even if I made, like, a bytecode language, it wouldn't be fast.

And yes, optimization will be important. I'll have to do lots of testing to see what code patterns run the most efficiently.


--- Quote from: DJ Omnimaga on June 25, 2014, 07:18:14 pm ---One thing I would suggest is offering certain pre-made routines for sprites or maps, for example, with a decompressor, so that people could use different image formats that are smaller than the built-in ones. The resulting code would simply decompress the images into a GROB upon runtime.

--- End quote ---

I do plan on having all-new custom functions in the mix as well, yes. Graphics-wise, I'll see if there's a format that's smaller than ICON (Uncompressed PNG file? There has to be a better way). The compiler will be smart enough to only put HPP+ custom functions into the code if you call them.

For example, there's no simple function to get only a part of a list, or to insert a list item in the middle of one. HPP+ will add these functions, which will decompile into an HPPL function that gets called when needed.


In the future, I'll probably be collaborating with other interested people to figure out A. how to organise functions into packages and B. what custom function we need and how they should be called.

bb010g:
I like the idea, but I think this will become less useful over time. The most important thing the Prime needs is some way of passing around functions (either anonymously or by pointers) and values (pointers most likely) without strings. I used expr in a paint program I had and it dropped performance a bunch. Every time an expr is hit, a bit of compilation has to be done. In a tight loop (like in a game), this gets bad fast. I like the constants, but it's more space in the editor on-calc. I wouldn't mind so much if it was just in the compiled file. These problems can only be fixed by changing PPL itself. I think adding pointers, even without pointer arithmetic, development would be a whole lot nicer. (I would also feel better about using large data structures. :)) I'm using struct-esque lists in my in-progress Tetris clone, and all you really need are program-local vars that act like enums and a function to take key-value pairs and give a list with the proper indices. That function could even just be shared in a lib.

Anyhow, I'm looking forward to see how this goes. :)

cyrille:
Hello,

>smaller than ICON (Uncompressed PNG file? There has to be a better way).
ICON is a compressed PNG... problem is that since it is in hex, it takes 2 bytes per nibble :-(


>For example, there's no simple function to get only a part of a list
yes there is! L1({5,8}) will get you elements 5 to 8 of L1 in a list..

>or to insert a list item in the middle of one.
concat(L1({1,n}), { 1, 2, 3}, L1({n,1000}))

You can also pass around functions, but they need to be properly QUOTEd to make sure that they are not evaluated at the wrong time...

Cyrille

Navigation

[0] Message Index

[#] Next page