Introduce SemiScript.

[alloy]

After much discussion, it became clear that to support this library far into the future, we would need to abstract the requirements into its own language, which can be compiled down to different languages.

Currently the compiler generates valid code for JavaScript and CoffeeScript, but could easily be extended to support additional languages.

The compiler has been written in C for optimal ROFLScale performance.

Related #8.

[alloy]

Btw, the option parsing has been implemented very naively on purpose, I think it can provide us with quite some bike-shedding hours in the future.

[madrobby]

+1

[showell]

Great idea, and nice work.

It should be easy to extend this concept to other languages. Sorry, this is just a sketch (untested):

    if (
        (strcmp(argv[1], "-ada") == 0) ||
        (strcmp(argv[1], "-algol") == 0) ||
        (strcmp(argv[1], "-c") == 0) ||
        (strcmp(argv[1], "-cpp") == 0) ||
        (strcmp(argv[1], "-java") == 0) ||
        (strcmp(argv[1], "-js") == 0) ||
        (strcmp(argv[1], "-pascal") == 0) ||
        (strcmp(argv[1], "-perl") == 0) ||
        (strcmp(argv[1], "-php") == 0)
    ) {
         semicolon = 1;
    }

[lrz]

Well, multiple strcmp statements are going to impact the promised ROFLScale performance. It would be more efficient to use a perfect hash table here (one can be generated using gperf(1)). I would certainly throw a few belgian dollars in a kickstarter project that promised to contribute such a change.

[alloy]

@showell I like the suggestion, but @lrz raises a valid point. Any takers?

[prototype]

I do have some ethical concerns though with introducing semicolons back into our javascript. Do we really want to be responsible for a new generation of emo developers?

[lrz]

Is that valid javascript code? I believe that emo is a reserved keyword in the grammar.

[alloy]

It would definitely be cool to be able to have turning-complete code like that in semiscript.

[showell]

@lrz I would commit some of my own Belgian money to this project, but I'm afraid Belgium stopped printing its own currency in 1995, and that was AGES ago.

Also, "emo" is only supported as a keyword in certain browser implementations of what we colloquially call "javascript." It is not part of the ECMAScript standard. As far as I know, the committee hasn't even reviewed the draft proposal.

[raggi]

Don't you have to wrap all this in a (function(){;})(); ??? ECOMMON

[alloy]

@showell & @lrz Done.

[showell]

@alloy By my calculation, your use of gperf introduces at least 256 bytes of memory overhead into the solution for a minimal speed enhancement. You can look at asso_values to see what I mean. In addition, each word in wordlist necessitates a 4-byte pointer due to the extra level of indirection, not to mention an extra 30 bytes for the five empty strings necessary to make the overly clever hash function work.

Having said that, I do think it's a promising patch. Next time, don't even bother submitting compiler.gperf. The gperf transcompiler generates ugly, non-idiomatic C code. I'd rather just work with the C directly and avoid the extra build steps. I see that you automated it to some degree in the Makefile, but what happens if I forget to run the makefile? Talk about a debugging nightmare.

Also, what if I mistype "pascal" in the "%%" section? At that point, I'm gonna have to drop down into a C debugger to figure out what's broken. So I might as well have just learned C.

Sorry to be so harsh. I totally understand if you want to use gperf for your own projects, and think it's cool, but I don't want to have to learn it myself. I'm perfectly happy with C. I don't even want to hear about gperf.

[alloy]

@showell I’ve slept on this for 1925 nights and have come to the conclusion that you’re probably right. Additionally, since then I’ve started using TypeScript, so I would probably re-use its compiler infrastructure nowadays and get compilation time reasoning about semi-colons for free.

[madrobby]

Dammit @alloy, I was just about going to merge this. Well, I guess not then. Your utter lack of any patience for waiting a little bit for pull requests to be applied is disappointing.

[showell]

@alloy @madrobby This whole PR has been an utter fiasco.

UNSUBSCRIBE!

Oh wait, I think the CI build is still running. Don't unsubscribe me till we see what it turns up. And I'll ask our PM to schedule a postmortem.