[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 14 Jun 2010 21:51:17 -0500
>> 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.
Great! Please excuse the mess. The parser is awful, awful, awful and
will probably be the first thing to go. Maybe it will get replaced
with a PEG later on :) But it works for now.
>> - 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.
It has to be distinct from false. I'll just stick with #nil and
hopefully nothing will go wrong
>> - 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))).