libera/#lisp - IRC Chatlog
Search
20:39:48
kiki_lamb
So, someone I'm talking to is making themselves a toy Lisp, and they seem like they're entertaining the idea of having many/most of the 'lists' actually being implemented as some kind of vector/array under the hood. How bad of an idea is this? Are there examples of this being done? It seems like it's going to be at least a bit awkward, with special cases needed for handling shared tails and circular
20:45:10
pjb
kiki_lamb: implementation details don't matter. They just may have an impact on performance or implementation complexity.
20:46:56
kiki_lamb
sure... this language is just a toy, they're basically a student, so I'm trying to offer advice that keeps the implementation simple, it's the first time they've implemented any parser or language.
20:48:14
kiki_lamb
Apparently the language they're implementing in makes true linked lists a bit awkwards, which seems like a shame... actually using linked lists in the implementation seems like it would be a simpler implementation, to me.
20:55:28
jcowan
kiki_lamb: http://www.faqs.org/faqs/lisp-faq/part2/section-9.html describes cdr-coding
21:08:33
kiki_lamb
pjb: heh, could be. I'd been teaching them how to do this in C, but they're also working on a parrallel implementation in Rust (with which I am not familiar). They're pasting me things from their Rust chat where people are saying that, apparently, the object ownership/GC details can be strange for linked lists with loops or shared tails in Rust. *shrugs*
21:09:49
kiki_lamb
Hopefully they will eventually give up on the Rust implementation and return to focussing on the C one... or perhaps even see the light, and take my advice of using C++ instead.
21:14:23
jcowan
So we must add a third category of languages: there is Lisp, and there is Blub, which is any language that is not a Lisp, and there is Super-Blub, which is any language in which you cannot even *implement* a Lisp.
21:19:01
kiki_lamb
Also the dependent type SuperBlurb<Person>, with SuperBlurb<me> describing those languages in which I personally could not write a Lisp.
21:30:42
iisi
Only thing I remember from looking at Cobol excerpts is the possibility of lots of consecutive periods, which must have exactly the right count.
22:45:03
jcowan
Just think of the dot as a right paren/brace. I have actually seen it written at the same indentation level as the verb.
22:49:05
mrcom
Normal, safe-mode Rust code has a very strict ownership graph; no object can be owned by two parents. And, you can't depend upon something (e.g., include it or point at it) without owning it.
22:51:16
mrcom
However, code marked "unsafe" can do it; the programmer just has to guarentee safety via algorithm. In other words, it degrades to C/C++-style coding.
22:54:51
jcowan
Allocating pairs out of a big array works for this (degrading to assembly language, basically)
22:56:12
jcowan
There's a Java native-code sandbox implemented as a MIPS emulator running out of just such an array. You compile your native code for MIPS and then convert it to a big initializer for an array representing memory.
23:41:49
moon-child
I think this is the second time we've had someone in here trying to implement a lisp interpreter in rust
23:42:32
moon-child
lisp is a pointer-chasing language. rust is referentially transparent. their operational models are incomensurable
23:47:59
iisi
If Rust had been around when there were Lisp Machines, I wonder if they would have had an all-aluminium chassis, so they could brag "Lisp Machines never rust.™".
2:00:34
kiki_lamb
moon-child: heh, well ~i~ wouldn't do it in rust, and will probably continue to advise that this guy return to C or, better yet, to C++ where I will be able to offer him better advice.
2:04:17
kiki_lamb
So far, from what I've read about rust, implementing a lisp the obvious way seems like it means he's going to have to use all these weird escape hatches that you just wouldn't have to use in an 'unsafe' C-type language.
2:27:18
iisi
Shhhh, they don't know that alu oxide forms instantly and is a form of rus. It just never looks "rusty".
2:42:14
moon-child
kiki_lamb: anyway, if I were forced to write a lisp in rust, I would do it as jcowan suggests, reducing everything to a big array of integers
2:46:53
kiki_lamb
moon-child: well, sure, but it's in that weird 'mid-level language' category where you can see the underlying hardware at least a little while still being pretty portable, which is nice as an implementation language for languages you'd actually prefer to use... I would much prefer C++ though, where you can imagine the template system as being the ~real~ language and conceive of the C-like part at some
2:47:38
moon-child
why can't I use the languages I'd actually prefer to use to implement the languages I'd actually prefer to use?
2:51:57
kiki_lamb
I think it is nice, at least as an educational execise, to learn the some of the low-level stuff, about dealing with the hardware directly, writing directly to registers and all that fun stuff, and learn how to implement a higher level using the tools the hardware offers you... but writing assembler is just awful, and every other option is going to sacrifice some portability. Almost every chip at least
2:53:23
moon-child
so, sure, somebody else has come up with a c compiler for some relevant piece of hardware already
2:53:44
moon-child
that doesn't mean it's a _good_ think they implemented c instead of something else
2:54:58
kiki_lamb
Sure, some path dependance. It's a convenient fact of history that there's something above assembler (but not too far above) for which we can trust a compiler has already been written, but conceivably better options could exist than C.
2:57:51
kiki_lamb
Scrolling back a little, I'm not confident that Rust could be that better option. I've only glanced at a little Rust while trying to help this friend out, but so far the impression I get is that half of the text in the tutorials consists of explaining escape hatches from the safety mechanisms people seem to praise it for.
2:59:02
kiki_lamb
moon-child: Yeah, transpiling to C seems like a pretty good option for more serious languages (but maybe a bit much for a student who's just building a toy first language to educate themselves like my friend).
3:00:23
moon-child
no--the question here is what language your friend should use to build his interpreter