[p-dev] Language "levels" idea

Paul Bone paul at bone.id.au
Sun Oct 13 22:49:23 AEDT 2019


We've kicked around this idea on IRC a little bit but I wanted a place to
write it down, without going to the formality of "documenting" it.


This was raised when I said should Hello World look like this:

----
func main() using IO {
    print!("Hello world!\n")
}
----

Or this:

----
print!("Hello world!\n")
----

In other words, should the top-level of a .p file behave like the body of an
function.  I already want to add the ability to place declarations within
functions:

----
func foo() {
    import Bar
    // use Bar things
}

// Can't use Bar things
----

So by making the top-level also execute code means it'd actually remove any
special significance there and simplify the language (and therefore how
people learn the language.  Seems good right?

The problem that arises is when should the toplevel code be executed, and in
what order.  Is it when your program starts.  If you import a library twice
does it execute (initialising data?) twice?  How about cyclic includes?

That's not the can of worms I want to open while creating a language with
"few surprises" for developers.

I think it was Micheal who suggested another idea.  There can be different
"levels" of Plasma.  A file beginning with #!/bin/plasma can run
PlasmaScript (my name for it) which allows this executable top level, so
does the REPL.  So people getting started and experiments and scripts can
play with a less pedantic Plasma.  PlasmaScript code can include either
Plasma or PlasmaScript code.  Plasma can only include other Plasma code.

I've also been thinking of undefined behaviour in C and C++.  It's nice to
have none of that.  Java doesn't have any but it takes a performance hit in
terms of what optimisations can be made.  I'm curious about a middle ground,
a situation where the language is formally more like Java but also helps the
programmer write code where it doesn't affect optimisation.  Consider
shift-left.  x << 4 has no UB, but x << y might have (if y is negative or >
the bit width) (I might be mis-remembering).  So if the compiler knows that
y is safe then it can compile it to faster code, if it does not know this
then it must compile a checked version that will assert if y is negative.
It could do something more predictable than C as Java does but I don't see
the point, that's still surprising in some cases.

So the compiler could give a warning when it is forced to add a bounds
check.  But most people don't want that to deal with that most of the time.
So what if this was a third level of Plasma.  I haven't thought of a good
name, let's pretend that PlasmaCore is a good name that doesn't invoke any
elitist attitudes.

Now I can summarise some other things that are supported at each level.
This is still "kicking around the idea" phase.  I just want to write down
what's been in my head.

PlasmaScript:
 * Used in the REPL and scripts
 * "uses IO" is implicit
 * ! on function calls might be implicit, I don't know.
 * Executes code at top level as if it's within the main() function.
 * Will not support auto-parallelisation.
 * Optimisation may take "PlasmaScript" as a hint to optimise for compile
   times.

Plasma:
 * Used by default
 * Resource declaration and !s are required.
 * Might relax polymorphic resource usage.
 * Maybe allow multiple ! in a single statement.
 * Will not support auto-parallelisation.

PlasmaCore:
 * opt-in.
 * Might tighten polymorphic resource usage.
 * Multiple ! are forbidden on a single statement.
 * UB and other things create warnings or errors at compile time.
 * Auto-parallelisation is supported

Not sure:

How should floating point behave in these last two modes.  It may be
associative in "Plasma" but not in "PlasmaCore".  How about the equivalent of
C compiler's -ffast-math?  Is that the one where the C compiler will put
intermediate results on the stack causing truncation so that they actually
conform to IEEE754 rather than leaving them in the x87 FPU 80-bit register?

There's probably other things I haven't considered yet.  Just wanted to get
this down as an idea.  Feel free to comment.

PS: If I really wanted to pun I'd call these Liquid, Gas and Plasma.  Solid
code is code that doesn't run.


-- 
Paul Bone
http://paul.bone.id.au


More information about the dev mailing list