Re: [PATCH] * src/eval.c: Stop checking for nvars, and use only CONSP

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > I'm all for a revolution, but it might be a bit early to chop off this
>> > particular king's head...
>> Until we have good debugging support for byte-compiled code, the
>> interpreter isn't going anywhere, indeed.
> We could rewrite it in ELisp, though :-)

That would mean just replacing the `Flet` in C with another in ELisp, so
it would largely just move the question (which is about diagnosing
invalid code).

>> >>     (defun eval (exp) (funcall (byte-compile `(lambda () ,exp))))
>> > Except for the ones that can't.  ELC is still limited to 64K constants
>> > in the vector, for example, isn't it?
>> I believe so, yes.  If/when we bump into this limit we can push it
>> further (or finally replace our bytecode language with a new one ;-).
> I hear the hot new thing is to use leb128 integers for everything.

I see I'm fashionable, then:

    (defconst bindat-test--LEB128
      (bindat-type
       letrec ((loop
                (struct :pack-var n
                        (head u8
                              :pack-val (+ (logand n 127) (if (> n 127) 128 0)))
                        (tail if (< head 128) (unit 0) loop
                              :pack-val (ash n -7))
                        :unpack-val (+ (logand head 127) (ash tail 7)))))
       loop))

;-)

>> > But as for the original question, do we have to have Flet?
>> I have not seen this question asked in this thread.
> The question was "can we remove this code from Flet?", right? I think
> "yes, all of it. No, all of Flet." is a valid answer to that question :-)

Point taken.

> (I dislike the "let" family, mostly for the fact that it is a family.
> It leads naturally to cl-loop.)

Removing its special-form status wouldn't remove it from the
language, tho :-(

[ Personally, I do find `let` important.
  Partly because of my let-polymorphism upbringing ;-)  ]


        Stefan