People should really put a few examples on their webpage when they introduce a language, like a hello world, making a http request, writing a ping/pong server, etc.
If by "bold" you mean daft, then you are right :-)
Mark/Sweep GC is easy, well contained, and simple to test. RefCounting affects everything, obviously does not work for circular refs, and is an incredible pain to test/debug. While RefCounting gives you generally continuous smooth performance, it can stop the world if a particularly large/complex data structure is being collected. So all in all, I would skip RefCounting next time. (scScript does have a compile option to turn it off.)
You could run C that way... but scScript is a scripting language using C-like syntax with features designed for scripting. For example, it provides dual variadic parameter/arg lists. Turns out having "in" (pass-by-val) and "out" (pass-by-ref) parameters are more pleasant (at least to me) than trying to return N values out of a function (especially since script languages run away from pointers). Perhaps it is a testament to my ignorance, but I am not aware of another language that does this.
The difficulty in designing a language is not so much implementing a compiler, but the iterative process of implementing and fine-tuning a given aesthetic... a given flavor as it were and it has to work well. Of course the other side is testing the damn thing... so my hats off to QA!
Nevertheless, I am sure good tool users could save a lot of time instead of hand implementing everything, as I would. So thumbs up to LLVM.
No (scripting) language with 2 parameter lists, the second all Var (to use the Pascal syntax). I could have included a Var keyword instead to differentiate, but a) that would complicate the variadic nature of scScript parameter lists and b) didn't quite look C-like to my eyes. (Then again I also have two Map functions in there for arrays and dicts.... so I should not claim purity.) (Yes, I stole them from LISP :-)
So you want to generate C code instead of ByteCodes.... and then compile the C? I suppose, if you broke out the runtime memory management (and a few other things) into a library. But I am not sure why you would....
If you want pure speed, then you would rather have it generate machine instructions instead of higher-level ByteCode ops. But you would not be using a scripting language if you want pure speed.
Perhaps if you only want a double-arglist variant of C (you must call it scC!) then you could write a front end processor! And by you, I mean not me :-)
People should really put a few examples on their webpage when they introduce a language, like a hello world, making a http request, writing a ping/pong server, etc.
Yes! That is why the 3rd line says: "...or to see sample code (Intro 1)." You just had to click on "Intro 1".
Combining mark-sweep with refcounting is bold. Most small VMs just pick one.
If by "bold" you mean daft, then you are right :-)
Mark/Sweep GC is easy, well contained, and simple to test. RefCounting affects everything, obviously does not work for circular refs, and is an incredible pain to test/debug. While RefCounting gives you generally continuous smooth performance, it can stop the world if a particularly large/complex data structure is being collected. So all in all, I would skip RefCounting next time. (scScript does have a compile option to turn it off.)
I wanted to write a love note to C... and if you hate it, it is all my fault.
It looks interesting.
Isn't the same kind of thing available from LLVM?
You could run C that way... but scScript is a scripting language using C-like syntax with features designed for scripting. For example, it provides dual variadic parameter/arg lists. Turns out having "in" (pass-by-val) and "out" (pass-by-ref) parameters are more pleasant (at least to me) than trying to return N values out of a function (especially since script languages run away from pointers). Perhaps it is a testament to my ignorance, but I am not aware of another language that does this.
The difficulty in designing a language is not so much implementing a compiler, but the iterative process of implementing and fine-tuning a given aesthetic... a given flavor as it were and it has to work well. Of course the other side is testing the damn thing... so my hats off to QA!
Nevertheless, I am sure good tool users could save a lot of time instead of hand implementing everything, as I would. So thumbs up to LLVM.
No other language that does what? Have out parameters? Many have that, even Pascal.
No (scripting) language with 2 parameter lists, the second all Var (to use the Pascal syntax). I could have included a Var keyword instead to differentiate, but a) that would complicate the variadic nature of scScript parameter lists and b) didn't quite look C-like to my eyes. (Then again I also have two Map functions in there for arrays and dicts.... so I should not claim purity.) (Yes, I stole them from LISP :-)
i haven't looked at the code yet but i love the website. just how open source project websites should be! ♥
May Odin smile upon you :-) And thanks for not laughing at my art!!
The dual in/out parameter idea is interesting. Looking forward to trying it.
Can this trans-compile to C? (And vice versa?)
So you want to generate C code instead of ByteCodes.... and then compile the C? I suppose, if you broke out the runtime memory management (and a few other things) into a library. But I am not sure why you would....
If you want pure speed, then you would rather have it generate machine instructions instead of higher-level ByteCode ops. But you would not be using a scripting language if you want pure speed.
Perhaps if you only want a double-arglist variant of C (you must call it scC!) then you could write a front end processor! And by you, I mean not me :-)