Some news!

First of all, I gave a presentation on my language to my peers this week! My presentation included all presently implemented features of Source. Get the slides here!


Second of all, here's an example of how the type system works:



function types() {
local a as real //a is of type real
local b as string //b is of type string


//a = "" //real!=string, ERROR!
b = "" //string==string, fine

a = 1 //fine
//b = 1 //ERROR!


local c //c is ??, which is the base type (?) weakly typed


c = 1 //fine, c is now of type real?, again weakly typed
c = "" //fine, c is now type string?


local d = 44 //d is of type real?
a = d //real==real?, fine
//b = d //string!=real?, ERROR!
d = "" //real?==string?, fine


local e as ? //e is ?, the base type, but strongly typed


e = "" //you can set anything to e
//... But the reverse is not true.
//b = e //string!=?, ERROR!
d = e //??==?, fine
}


I'll definitively have to try Source at one point too, although since I prefer to not learn multiple languages at once I'll most likely stick to PPL at first, but if I keep running into roadblocks or can't stand it, I might attempt a switch to Source.

Anyway keep the good work on this. If this do come to fruition this is definitively front page material I'll be suggesting to staff.

Wait, so basically if I want to make a game for both the HP Prime and the computer at once then I now can if the computer language is available for Source?

That's amazing.

Someone, create this for Axe please!

That's amazing. I wonder if PC programs will run as they do on the Prime, especially for compiled languages? It would definitively make things even easier (although you would need of course good support for the TICKS and WAIT commands so we can make our games run at constant speed.

And yeah drawing will definitively be a must, especially with how much freedom HP PPL offers already.

Well, right now, SourceBox is a rather... Naive implementation. For one, in SourceBox, lists start at 0 and are passed by reference...

For one, I plan on having other compiling platforms; platforms where things are passed by reference and where arrays are indexed by different things.
I have plans to alleviate this divide; for example, I plan on making Source a language where the first list index is irrelevant. Wait and see to find out how!

In other news, you can insert HPPL code directly into Source programs:

@export
@!optimize
function hax() {
   local a="HAX"
   @lang=hppl "msgbox(a)"
}

Also, you can use custom HPPL functions as Source functions:

@native=MAX
function wow(a,b) {
   
}

@export
function getmax() {
   return wow(1,2)
}

@native
function MAX(a,b) {
   
}

@export
function getmax() {
   return MAX(1,2)
}


You can also use @lang to comment your compiled output:



@export
function stuff() {
@lang=comment "This function does stuff."
print("Stuff done!")
}


I'm guessing the FFI is not going to be platform independent. Am I sensing compile-time code selection?

Yes, the @lang strings are platform-dependant, as well as @native. However, I plan on making a few @langs that are independent, such as ones for Source internal bytecode.

Basically, there is a bytecode operation called NATIVE which contains the @lang string. The platform assembles this operation however it wishes; in this case, the HPPL platform takes @lang=hppl blocks and inserts the contents directly into the HPPL output.


Moving on...


Today, I have for you more progress! We now have function overloading. Now you can have two functions with the same name and different arguments, like so:



@export
function overloadTest() {
print(func())
print(func("an argument"));
}


function func() {
return "Got no arguments!"
}


function func(a) {
return "Got "~a
}


Overloading via data type will be supported soon. Right now, however, I have made directive-based overloading, too.


So, in SourceBox, you have an output panel where calling print is like the standard println. Well, what if you want a newline-less print? Well, in SourceBox, there are two versions of print. They both take 1 argument, but one of them is tagged with the @append directive. Because of this fact, you can target the print-like one instead of the println-like one as so:



@main
function printTest() {
print("This ends with a newline.")
@append print("This one ")
@append print("does not.")
}


If you tag your function call with a directive, it will try to match the directives up between functions. This way, you can have a very fine way to control function call overloading.

Multiple dispatch?

inline HP PPL support is definitively a good idea. Also if the calc ever supports ASM maybe Source could allow inline ASM opcodes?