<incomprehensibly>
devyn: also i just don't want lots of public logs with the name i intend to release music under in the future
<incomprehensibly>
devyn: haha
eligrey has joined #elliottcable
<Cheery>
katlogic: thought about implementing hash tables into snakelisp today and yesterday. but it's quite hard.
<Cheery>
katlogic: then I'm studying this thing.. I feel like a need for better organization of this code
<Cheery>
thought about removing everything bare, concentrating on closure/slot/gc -group.
<Cheery>
most everything else is just data and functions
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
gozala has quit [Quit: Connection closed for inactivity]
<Cheery>
extending the system for vararg calling convention
<Cheery>
and for arbitrary number of data structures.
<katlogic>
Cheery: And ellipsis, and multireturn ...
<katlogic>
and tailcall
<katlogic>
congrats, you have basic scheme (the hardest but most important features)
<Cheery>
ellipsis?
<katlogic>
...
<Cheery>
yeah. but how do they use that?
<katlogic>
in lua, it looks like
<katlogic>
function x() return 1,2,3 end and then you do: function blah(...) end, finally you can blah(-1,0,blah())
<katlogic>
aka, vararg and multiple return values fit into each other
<katlogic>
in scheme its just lists, so it comes off naturaly
<katlogic>
in lua, its simply stack
<katlogic>
finally, it has to be aware of tail recursion too (in lua impl, the arg frame on stack is overwritten by returns, if more returns are passed than original args, stack is shifted/grown etc)
<katlogic>
it comes off rather nontrivial, but is needed for proper functional programming.
<Cheery>
why?
<Cheery>
why have multiple return rules like that, instead of just returning a list?
<katlogic>
so you can funnel the return values as args to function call in a tailcall
<katlogic>
without this implemented properly, you cant have tail recursion
<katlogic>
(i mean, of course you can, this implementation is just efficient one)
<katlogic>
generating gc trash just to pass arguments around is often bad design choice
<katlogic>
(because you'd pollute heap just by looping in tail recursive loop)
<Cheery>
hmm.
<Cheery>
okay
<Cheery>
I think there's a way to implement it. You're just calling return continuation with multiple arguments