Hello! On Sun 13 Jun 2010 23:03, No Itisnt <theseaisinh...@gmail.com> writes:
> Hey, now would be a great time for a critique of my Lua project if you > are willing, so I can incorporate any criticisms or ideas you may have > before the GSOC midterm date. I'm closing in on finishing the base > language and I hope to complete it this week if time permits. Great news. I haven't had time to really dive in, but hope to do so towards the end of the week. > - I am using #nil for Lua's nil right now. Lua considers nil false for > the purpose of conditionals and it's also the value of unset variables > or table slots. Maybe it should be replaced with a gensym? I didn't > follow the Emacs nil thing very closely so I'm not sure whether that > approach might be problematic. It could be OK. #f would also be fine. Does this value have any other kinds of semantics? You will want to use an immediate like #f or nil or something, going through a symbol will be too slow. > - Lua represents numbers as the C 'double' type by default -- what's > the best way to approximate that in Guile? Hmm. Here I think we should use Guile's numbers by default. That way you get the speed of inums in most normal cases. You should probably coerce division into inexact numbers (i.e. 3 / 4 translating to the equivalent of (exact->inexact (/ 3 4))). Looking farther, having immediate (unboxed) floating point numbers might be a win. See the discussion in http://www.nue.riec.tohoku.ac.jp/ppl2008/proceedings/1-06.pdf; I don't think a special GC nursery is the right thing for us though. I'd rather try to tag immediate floating point numbers as in http://t-t-travails.blogspot.com/2007/07/tagged-unboxed-floating-point-numbers.html. > - How should I implement multiple return values? Lua allows multiple > variables to be assigned in a single statement, e.g. "a,b = c()", but > it's also permissive in that an assignment need not be balanced -- > there can be extra variables on the left or expressions on the right. > So I think I need to be able to inspect the return value of function > calls somewhat at runtime. I was hoping for something elegant but > perhaps I will just return vectors and inspect the return values of > functions at runtime. I don't know really. This was the sticking point for me when I looked at implementing Lua. It would be nice to avoid heap allocation... Here is one option: (letrec ((cont (case-lambda ((a b c) ; the expected number of values do-the-thing) (args ; some other number of values (cont (first-arg arg) (second-arg arg) (third-arg arg)))))) (call-with-values (lambda () right-hand-side ...) cont)) This should be optimizable in the future (in particular, rendering the case-lambda body inline, as normal lambdas are). Happy hacking, Andy -- http://wingolog.org/