> Hi again, > > I've spent the weekend mucking around that idea of creating a Scheme > compiler targeting Neko, and I've ran into a couple of issues. > > 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). > 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. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
