[xavel]

Maybe it's just me, but I'm not a particular fan of Lua-inspired pseudo-stackbased APIs.

I'm not sure why so many language devs insist on this terrible design. I fail to see anything good about it; It doesn't make the code smaller, it doesn't make the code faster, but it does make abstraction a royal pain in the buttocks.

Also, they couldn't have possibly chosen a worse license for a library that is going to most likely embedded statically in a program. Of all licenses, why AGPL? If it has to be GPL (whyever is none of my concern), why not LGPL?

[jaen]

Explicit stack-based interfaces are used for good reason: This allows simple accurate garbage collection (see eg. the Ruby API which requires somewhat error-prone conservative GC, Python which requires refcounts all over the place, or OCaml which requires annotating all local variables in a special block). A custom frame stack is also needed to have coroutines in pure ANSI C (two of the reasons Lua is popular).

[sesquipedalian]

I don't believe non-stack based APIs prevent the implementation of the features you just mentioned. You don't necessarily have to expose the underlying stack manipulation routines as your defacto API although it is easier to do so. My gripe with this technique is that it makes it much harder for the compiler to catch errors. Personally, I think it would be better to expose the API as helper functions that compose (and hide) the underlying stack routines.

[anjbe]

The intent is clearly to promote sales of commercial licenses. Similar to why Oracle relicensed Berkeley DB from BSD to AGPL: “As of July 2011, Oracle's list price for non-copyleft Berkeley DB licenses varies between 900 and 13,800 USD per processor.” https://en.wikipedia.org/wiki/Berkeley_DB#Licensing

[xavel]

Well, that's just Oracle being Oracle. They did the same nonsense with Opensolaris, if I recall correctly.

[chubot]

What would you do instead of the stack-based API? That's the best design there is AFAIK.

Lua started out with something like Python's API (Lua 3.0 I think), but they changed it to use the explicit context and stack.

[xavel]

The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way.

If your question is about cheap memory storage, linked list algorithms already exist, so there's really no good reason to use a faux stack to store data.

[marktangotango]

>> What's would you do instead of the stack-based API?

Did not see you answer the question here. You have a strong opinion, what would you like to see instead?

[xavel]

It's not so much about what I would like to see, but rather why some developers insist on copying Lua's stack-based API, merely because so many people have accepted Lua as the very definition of a lightweight, embeddable programming language.

It seems like a false promise to me is all I'm saying. People get lured in with a very questionable tactic, and then start to believe "stack-based API == tiny and great", whereas I think that this is a pretty bold statement.

In any case, I did answer your question - you can achieve the same level of minimalism by using linked lists, and yes, OOP in C. Shouldn't be exactly news to anyone who has learned C (not that difficult anyway). I don't see any compelling reasons to choose a stackbased API over anything else.

I've found myself figuratively battling with Lua when I tried to create nontrivial objects, such as metatables with constructors, indices, missing indices handling, etc, you name it. It's fun and easy for small things, but gets cumbersome really quick. And inline-evaluating Lua code just because the API has been updated in some odd ways, so that previously perfectly fine working code now compiles, but no longer works, just feels hacky to the max.

With a non-stackbased API, this is literally just a matter of walking function calls (the native program stack). But with a stackbased API, you have to walk the machine stack AND the API stack.

That's not fun. Not even remotely. This is how you teach a programmer to hate programming.

[angersock]

The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way.

Um, what is the C ABI for invoking functions?

:|

[xavel]

Yes, of course. But that's ABI, not API.

[angersock]

An ABI is the API a computer understands.

It makes a great deal of sense, especially when dealing with an interpreter for a stack-like machine, to expose language bindings in terms of that stack.

It's not super friendly, mind, but it makes perfect sense.

[sesquipedalian]

Agreed. The biggest drawback IMHO is you defer errors that could have been caught at compile time to runtime if you had a saner interface.