Science Design of a programming language

[Moach]

hmm... ok, i better get this open to discussion before i go too far on a mistake or some manner of disaster-bound course of action.... :hmm:

so, as some of you may have heard, i'm designing a "new"(ish) programming language... it's no huge deal... meh, it's not even a small deal, really... it's just a little "improvement" on my blunt everyday wok tool


i call it AXIOM, anyways, without going any further on why i chose to do this (theres plenty of good reading on that at my blog) - let me present to you what i mean to accomplish and how

AXIOM is a HaXe precompiler - this means, it does not build code - it only modifies what goes into the thing that does (haxe) :huh:


anyways... i figured it'd probably be wiser to go about it this way... first, i don't have to write a full compiler (who has the energy for that?) - second, i don't trample over the hard work done by Nicolas (the answer to my last parenthesis) so far with haxe


but more importantly, i'm not imposing anyone to "choose" between languages... so let it be known that AXIOM is an extension of the HaXe language, and hence it implies no incompatibilities with existing code - even when used together in a same project


so lets see, what can AXIOM do that HaXe cannot, you would ask?
well - whatever i want it too :lol: but no, really - there is a features list i'm using as a guideline while i cowboy-code this semi-resolved device of mine into earthly existance

goes as follows -

function overloading - different arguments means different functions - even if under the same name

inline type (struct) instancing - you can declare non-primitive-typed variables without using "new", allocating to the stack, as C++ does - also, when used in the scope of a class, struct instances are "flattened" into primitive-typed class-member fields, integrating seamlessly to existing/intrinsic code

pointers and references - AXIOM should allow you to explicitly decide how to handle a value, allowing a choice on pointer, value-reference or value-copy

local static fields - in C++, you can make a local (in-function) var "static", which makes it persistent between calls while only accessible from within that same scope - AXIOM can bring this to flash

multiple inheritance - through a special notation, you can extend from more than one single base type

compact syntax-based inference - AXIOM will rely on C-style variable syntax to trigger in-scope instancing logic

full HaXe compatibility - AXIOM does not overlap nor it redefines any existing aspects of HaXe coding - it just adds more tools to work with

operator overloading - it is conceivable to use the pre-compiler to parse operators into traditional code (how that'd work is t.b.d.)

global modifier - AXIOM can abbreviate singleton patterns using a "global" keyword - combined with "using" this allows global variables
IDE integration - by building AXIOM as a variant of the HaXeContext FD plugin, the new language features can be seamlessly recognized for code coloring and completion (for preprocessor symbols as well)

Vector<T> by default - AXIOM may adapt [] syntax to replace the dated "Array" default by much faster Vector<T>

optional header notation - to lessen the mess that long functions can make of a class, AXIOM offers declaring function signatures separate of implementations - with a special keyword to "link the head to the body", this syntax option can be made self-documenting (you'll always know where to find the detached function body)

native arrays - AXIOM provides for C-syntax usage of the [] operator to declare and access native arrays

never null - C-syntax values are never "null" - no run-time checks to deal with "null" when that's not an explicitly valid case

no Garbage-Man Blues - AXIOM-notation vars that are scope-bound or class-bound do not require, nor suffer garbage collection

zero architecture toll - by resolving types at compile-time, your program structure can be laid out worry-free of performance tradeoffs

as fast as it gets (in flash) - by relentlessly abusing of alchemy memory features exposed by HaXe, all these features can be implemented in ways that would yield faster execution than possible without heavy source-code optimizations (where readability goes out the window)

the absence of those things often make flash programming (which should be simple and toy-like, i gather) harder than programming in C++ - many puzzle-like situations arise from not having pointers...
that and the fact that OOP practices impose a run-time performance overhead make it a LOT more challenging to accomplish anything decent with flash than it is with C++ and other "hard" languages... :facepalm:

anyways, we're not here to discuss what we don't have - we're here to talk of what we can do to get it!


and so it is - what follows is a randomly-arranged listing of ideas on how to get the features above implemented into a machine that does not support it (you can wish me luck now)

STRUCTS
these can be tough... flash by design is based on a rather cumbersome and overbearing system of classes and packages, plus a bunch of other nonsense.... needless to say - slow!
many times, a class contains other classes, and those other classes, in say, about 90% of situations, would never "not exist" while the parenting class is in use...
of course, flash makes this quite cumbersome, for every non-primitive type defaults to "null" and must be instantiated (slow) before it can be used....

fortunately, adobe gave us ALCHEMY! - a rather obscure, set of tools that "bakes" C/C++ code into flash-compatible bytecode, and with this they opened up a door -- flash has a set of undocumented opcodes that allow alchemy to bypass the combersome memory model and get down to business right away...
HaXe does it's part and exposes those features into a clumsy-to-use Memory class...

now, with AXIOM, i can abstract that reader-unfriendly interface of the HaXe memory class and put it to proper use...

so if one defines a struct (in its proper notation), AXIOM knows that this is the cue to start doing its thing


Struct-Typed Variables
how can i make a struct into a primitive type? - well - we can FLATTEN it! :blink:
those familiar with Java and it's ilk (flash) know that non-primitives are always treated as pointers... well we don't want that, so we either forget about OOP altogether or...

we AXIOMIZE!

whenever one declares a struct-typed variable in typename-first notation (as opposed to flash-like "var blah:type") the precompiler grinds down the contents of that struct into primitive types... this effectively "fuses" the struct into the definition of the containing class - and gets us around a heap of problems already

yet, a few problems come to mind (this is the part where i begin to sound more and more uncertain of myself)

what if that struct is fed into a function? how is that function gonna be called? how do we convert that concept into something HaXe (and flash) can digest?


POinters!
we need pointers... HaXe provides random access to low-level alchemy memory in the form of a large byte-array thing (roughly) -
in AXIOM, i decided for a "handle" keyword that would act as a type modifer when defining vars to determine that said variable is an address to something - not the thing itself...

and now - for a little "what should i do??" - i have to figure a way to distinguish operations on pointers and on values in expressions.... C/C++ use the * and & operators... but i think sorting those out on a lexical-only basis (im using regular expressions about as long as my leg) can be more tricky than i'd wanna go for...

so i need an operator that's not already being used in regular code... i thought of the $ sign... but i find that has a certain "php overtone" which i generally dislike....

so i got to the @ sign... which HaXe does use those for macros already, but i can sort those out with some clever RegEx voodoo...
i like the fact that @ is pronnounced "at" in english - it makes for a very much verbal way to explain what is going on in cases such as:

Vec2D handle vecptr = otherVec@;

Vec2D notPointer = @vecptr;

get it? - try and think it out loud how those expressions would be spoken - "otherVec at..." - of course, means "address where otherVec is at" - alternatively, @vecptr stands for "value to be found AT vecptr"...

so with one operator (which can be used more than once in pointer-pointer cases), this could tell AXIOM (and the programmer) what is to be expected of the results...



ok... still not done... lots of more stuff to brain down on...

yet i find myself time-bound right now... i need to go and drive lest my girlfriend will be out missing her ride home... so off i go

and later i'll continue on in my ramblings on how i'm gonna pull-off this stunt and make flash workable (in a non-suicide-inspiring way) again....

 

[HarvesteR]

Nice one on the @ sign! it's very self-explanatory...

Now, to make your head spin a little... have you considered what would happen if one were to declare an array of structs?

Something like this:

struct Vector3{
    float x,
    float y, 
    float z
}

//and then, somwhere else

Vector3[] myBunchOfVectors;

What would happen in this case?

My suggestion to you would be to not flatten structs onto the class definition itself... flatten it to an array of primitive types, recursively, so if you have a struct containing a struct, each primitive type will occupy one position on this array, and the non-primitive types would be flattened down to an array inside the corresposding position for that value, and so on recursively.

The problem is, you're likely to be dealing with multiple data types in structs... So a typed array won't help much... you'd either need an array of type-free references, and resolve those types at compile time, or something like that...


Cheers

 

[Moach]

in case of native arrays, we can just treat the whole thing as a set of regular variables (which is what arrays are, anyways)

so yes, when using native arrays, this:
Thing myThing[3];

is the same as:
Thing myThing_1;
Thing myThing_2;
Thing myThing_3;


the only difference being, with the former you're kinda expected to access them by explicit means of pointer offseting, which is what the [] operator does, really...

you CAN, in fact, even if not specifically declared as an array, still access contiguous variables of the same type using offset logic... it's just not, uh... advisable to do so :hmm:

 

[Wishbone]

Being far from computer science, I can only ask: is your investment of time into a new tool worth the estimated savings?

EDIT: remember, languages (human and computer alike) are just spectacles through which you look at the world (or solve the problems in your domain). Spending time cleaning specs instead of sightseeing or problem solving may be not the best thing available, especially considering you can shop around to get whatever combination of type system, OO-functional-template-whatever programming flavour you require without the need to debug parsers, back-ends and optimizers...

 

[Moach]

Being far from computer science, I can only ask: is your investment of time into a new tool worth the estimated savings?

EDIT: remember, languages (human and computer alike) are just spectacles through which you look at the world (or solve the problems in your domain). Spending time cleaning specs instead of sightseeing or problem solving may be not the best thing available, especially considering you can shop around to get whatever combination of type system, OO-functional-template-whatever programming flavour you require without the need to debug parsers, back-ends and optimizers...

of course, i had asked myself that question just about a million times...

all things considered, so much work usually goes into workarounds and hack-jobs to manage without those things, it makes sense to divert some of that effort into fixing up a general solution
then there wouldn't be any of those problems to sort out later on...


yet its hard to see where those problems begin to pile up... by the completion of my last project, i estimate i summed up about a month or so of workarounds for limitations of the sort we're addressing here...

then, as i researched these issues, i also found there are others, like me who are going through similar lenghts to develop post-compile optimization tools and whatnot - there's one guy who even struck the same chords as i by addressing the lack of unmanaged memory in flash with a struct-like data type...
he didn't go about it with a language extension, tho - it was more a post-build tool... and it only works for AS3, not HaXe (which itself is another user-side effort to help make my point)



anyways, i stopped and reviewed several of the libraries i have laid out to deal with object pooling (one of the afore-mentioned hacks AXIOM would mitigate), annd all the blogs out there explaining countless manners of code trickery, all trading maintainability for speed in some way....

you see, thing is - flash has us pinned down - the way we're "supposed" to work with it is by far, the slowest, least optimal choice... then, there are the many pitfalls of garbage-collection (which i explained in my blog rants)
finally, theres a great, optimal solution just under our noses that we cannot reach without breaking away from the "traditional" ways of flash development...


i found i was getting so aggravated by this, i could not live with myself knowing there was something i could do to mend it...

you see, we all know it - something has gotta be done... now, someone has gotta do it


if flash hadn't become a carreer for me this would not bother much... i'd just go with "ah, its just flash" (which seems to be adobe's take on the matter) and leave things as they are...

but many developers like me are making serious work using a tool that's just too blunt for the job... HaXe is thew results of one Nicolas Canasse deciding to take action - he did a phenomenal job - but those things remain unnacounted for, and that's where AXIOM comes in



so yeah, it's damn worth it....:thumbup:

 

[Wishbone]

Does your employer enforce code readability? If nobody (but you) is going to read it, you can do whatever you like. The underlying problem seems to be linked to the limitations of ECMAScript, creeping well beyond the original design, and poor implementations by Macromedia/Adobe. Just my 2 cents...

 

[Moach]

Does your employer enforce code readability? If nobody (but you) is going to read it, you can do whatever you like. The underlying problem seems to be linked to the limitations of ECMAScript, creeping well beyond the original design, and poor implementations by Macromedia/Adobe. Just my 2 cents...

yep... thats pretty much the problem...

and no, my employer doesn't really enforce readability... i'm probably the only one who's gonna read my code - but then - i do have to read it! :lol: :facepalm:


and one billion hack jobs later, i don't even know what that big mess was supposed to do in the first place... and i was the one who wrote it :uhh:

that's very much less-than-ideal working conditions.... :shifty:

and i have to deal with it, somehow... everyday...


i'm not gonna wait for adobe to eventually sprout a brain and pull out some fix out of the hat.... i'm gonna fix the damn thing myself - and hopefully, my fix will be of use for others as well


it's no impossible feat, really... if one french genious kid can turn up with HaXe and make a multi-millon-dollar company look bad - i think i can preprocess it into coherence with already-existing features that would make everyones life a lot easier
this isn't really a big ambitious project - it's a mere adaptation of language constructs to make development a little more straightforward :hmm:

i hope... :lol:

 

[HarvesteR]

Yeah, I can attest this being possibly very very useful. I remember from my flash projects, that each new feature came accompanied with a twice-large amount of hacks and unexplainable bugs, all due to flash's poor handling of, well, everything...

So for each feature added, on average you spend the same amount of time again trying to solve some stupid problem like that, or hunting down some null reference error somewhere...

And yea, the problem is mainly that Adobe treats Flash as if it were a toy for hobbyist game developers... the platform developers themselves don't seem to take it seriously...

But then there's the big evil... Anyone in their right mind would think "if there are so many other options out there, why not ditch Flash altogether?", well, if all developers COULD ditch flash and not look back, I imagine that there'd be a mass exodus taking place... but the thing is that the Flash Player is installed on 98% of computers world-wide. That's more than windows itself, or any other piece of software for that matter.

What Adobe fails to realize is that they're sitting on the biggest thing to potentially happen to web applications. A platform-safe, all-around engine that can do anything and could unify the internet's content... that's Flash's potential... but instead, Adobe chooses to treat it like a toy for silly games and streaming youtube.

Meanwhile, others, like Unity and now Google with their NaCl engine are creeping up the dying carcass that is Flash, and slowly taking out chunks.... but too slow to climb up the top...

Ohh well, the web platforms scene is in a very weird state right now... but let's [/rant] here...

Cheers