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
3:03:08
kiki_lamb
Heh, sadly he'd already chosen to try parallel efforts in Rust and plain C before he started askbing me questions. :/
3:05:50
kiki_lamb
C++ would be what I'd probably recommend if he wants to rely upon my advice, simply because I've myself done just the sort of thing he's trying to do in that language before and so would probably have better advice to offer that way.