libera/#lisp - IRC Chatlog
Search
18:24:11
dmrz
(trying again) if i were making a new lisp in which `(def x 8)` was a 3-elt array, not a linked list, does anyone think this is a really stupid idea that I should reconsider?
18:29:22
dmrz
so on the one hand, i've heard this suggested before, and not making macros suck is a very core design consideration so i want to make sure i'm not ignoring anything related to this
18:30:44
dmrz
on the other hand, are you sure it's actually harder, as opposed to just less efficient for the machine given common patterns of macro design?
18:31:52
dmrz
like, i know that a lot of forms are naturally processed as like: step 1: dispatch on (car s) to decide what to do with (cdr s), repeat
18:32:37
dmrz
and it's obviously somewhat more cumbersome to do this with something that doesn't naturally split into a car & cdr
18:33:21
dmrz
but this could easily be hidden from the programmer if you didn't think spending a few more instructions per macro evaluation step was a big deal (and i don't)
18:34:19
aeth
Afaik, you can fake car/cdr. #(1 2 3) can be decomposed into 1 and #(2 3) without allocating a new #(2 3) if the language is designed for that. So the problem would be arbitrarily inserting potentially long things in the middle.
18:34:50
aeth
That and you'd mutate a lot while most macros are purely functional even though the cons pairs are usually mutable.
18:36:04
dmrz
the arrays don't have to be raw arrays, they can be those things like rope strings but for arrays (not sure what the official name is)
18:38:52
dmrz
anyway, imo macros are only supposed to be purely functional in terms of their outward effects (i'm turning one tree into a different tree), not in terms of what they do to the machine
18:47:00
dmrz
Mrtn[m]: it's not supposed to be a simple or just-an-experiment language. basically, i'm taking a clojure-like route and writing a compiler
18:51:30
Mrtn[m]
If you're going to use the power of CL however, you might be better off writing it in CL.
18:53:29
dmrz
the implementation target is pretty much settled, at least for now; the main thing i want feedback on is the language design
19:18:46
jcowan
aeth and others: you only have to use "lst" if you are going to use the "list" function in the same lexical scope. I don't use the "list" function much, so I am happy to use "list" as a local variable.
19:21:00
aeth
funcall seems to only be useful in Scheme for the very specific purpose of calling a list (or other sequence) of closures in a higher order function, which seems very niche
19:21:38
jcowan
thirdly, you could unify lists and vectors by setting things up so that (car v) returns the first element of vector v, whereas (cdr v) returns a subvector of v starting at element 1
20:35:06
moon-child
jcowan: I don't see why funcall is useful for adapting cl programs to scheme. The primary hurdle is colliding names that were previously in different namespaces; once you've taken care of that, you can freely remove all instances of funcall
20:35:29
moon-child
but, as aeth points out, it _can_ be useful in scheme when writing higher-order functions
20:36:08
jcowan
You can freely remove them, but if you'd rather not mess with the source more than absolutely necessary, having a definition of funcall is a small step in that direction.
20:39:28
moon-child
my point is that ensuring there are no collisions is a very invasive change, far more so than removing instances of funcall
20:44:18
moon-child
(looked at my old code where I thought I was using it, but I guess I decided against using it, so I don't have an example, unfortunately)
21:43:38
jcowan
moon-child: I mean, what is the advantage of funcall when dealing with higher-order functions?
21:47:58
aeth
(define (funcall fn . args) (apply fn args)) (define mapcar map) (mapcar funcall (do ((i 0 (+ 1 i)) (l '() (cons (lambda () i) l))) ((>= i 10) l)))
21:50:25
pjb
jcowan: the advantage is that you can have both functions and variables named with the same name, just like in English and a lot of other natural languages.
21:50:26
aeth
You might think to do (defconstant funcall 'funcall) in the CL version because 'funcall works just as well as #'funcall, but, no, there's a package lock on COMMON-LISP (and thus on COMMON-LISP:FUNCALL) in SBCL and any other implementation is free to do the same.
21:54:20
aeth
pjb: Yes, it's a debate as old as time. Which one do you want to be easy and which one do you want to be awkward? (defun list-of-list (list) (list list)) vs (define (f x) (x))
21:58:50
moon-child
jcowan: you can pass funcall as the 'function' and some other function as the 'data' into a higher-order function to make the hof call the 'data' function
22:03:43
aeth
(define (funcall fn . args) (apply fn args)) (map funcall (list (lambda () 1) (lambda () 2))) ; works