[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lua
From: |
Andy Wingo |
Subject: |
Re: Lua |
Date: |
Mon, 14 Jun 2010 22:50:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Hello!
On Sun 13 Jun 2010 23:03, No Itisnt <address@hidden> 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/