> > I believe the shortcoming of not being able to define variable > > arguments functions has been brought up in the list before. Without > > variable arguments, I have to retort to _always_ packing arguments > > into arrays. Scheme will always require some handling for variable > > arguments functions - namely, to build the rest list -, but that's > > internal to the function, not at every call site. > > Yes. > Please note that it only has a performance issue. I'm thinking about > adding them to Neko in the near future (it's not a big change since > there is already variable arguments C functions).
Yes, I understand this is mostly a performance issue, and arguably not even a big one. When I said it was a shortcoming I was more in the line of thinking about interoperability issues - a Scheme using this "calling convention" would have a hard time calling "normal" Neko functions. Not that I think you should support every exotic calling convention. In fact, there's always the option of wrapping functions that follow different conventions inside objects. But since, as you said, there were already variable arguments for C functions, it seemed a natural step to support them. I'm just glad you're planning to add them! :) > > I was also happily surprised to find out that, using NXML, I can use > > any characters I want for identifiers, at least as long as they don't > > start with a $. That means no name mangling is needed for Scheme! :) > > Now my question is: was this "by design"; am I even "allowed" to use > > it? > > It was not by design :) > > I'm not sure if I will or not keep this behavior in the future. In one > of our compilers I was also surprised that NXML permit to compile > expressions such as object.$field without translating it to > $objget(object,"$field"). The drawback is that when you convert it to > Neko source using nekoc -n you'll endup with an invalid neko program. > One possibily is then to enforce Neko rules in NXML and the other one is > to fix the Neko translator to always get a valid Neko source. I didn't > decided yet which one. Well, I have to say even I have mixed feelings about using this. On the one hand, it means that I could transparently use Scheme identifiers (perhaps adding in a prefix to avoid the $ issue, or maybe forbidding it's use); on the other hand, it dampers interoperability a bit, since other languages might not be able to use these identifiers, at least not "transparently". I could use objects to store globals, then they'd be accessible from Neko (with $objget, $objset, etc). But then again, modules already communicate using objects, so from the point of view of interoperability, it's just the same. But about objects, I must confess I was really suspicious of your handling hash collisions at first, though after doing the math I know it's pretty safe (2^31 is a big key space, after all). However, that depends on how good the hash function is. And the current one seems a bit simplistic (I was able to easily provoke a collision, which was fun, nonetheless :) I can offer a 4-line patch based on the FNV hash (<http://www.isthe.com/chongo/tech/comp/fnv/>) blindly adapted for 31-bits here. Sorry to nag you with such trivialities, but I am still feeling my ground with Neko... Nuno Cruces
-- Neko : One VM to run them all (http://nekovm.org)
