5 ms·

Kernel is what I really want scheme to be. It's like scheme, but better. And if you're wondering why I say better, more first-class objects is always a good thi

Kernel is what I really want scheme to be. It's like scheme, but better. And if you're wondering why I say better, more first-class objects is always a good thing.

shasta 11y ago
That's a pretty simplistic explanation. There are lots of ways to mess up Lisp in an attempt to enable the style of meta-programming that Kernel supports. What distinguishes Kernel from these other approaches (many of which have been seriously considered in the past) is mostly what you're not able to do in Kernel. That is, the vau construct still allows encapsulation in a useful way. Kernel may have "more things first class" than Lisp, but that's not all that sets it apart.
- deleted 11y ago
  [deleted]
- qwertyuiop924 11y ago
  That's certainly one way of looking at it, and it IS one of the reasons I like kernel. fexprs > macros because of this.
sklogic 11y ago
> more first-class objects is always a good thing Only if they're not enforcing some (actually, the worst possible) evaluation strategy.
- qwertyuiop924 11y ago
  True, I suppose.
groovy2shoes 11y ago
When you get first-class fexprs, you pay for it in performance. They're nearly impossible to compile, and even interpreting them efficiently is a challenge.
- qwertyuiop924 11y ago
  Read Sutt's paper, then decide if he didn't fix the performance problem. I haven't gotten around to it yet, so I'm not sure, but apparently $vau-calculus has some interesting properties.
  - groovy2shoes 11y ago
    I read Shutt's thesis back when he first published it. I'll admit I'm due for another reading. The vau calculus is indeed very interesting, but there are fundamental reasons why fexprs can't be implemented efficiently (at least, not on commodity hardware). Of course, depending on your use-case, they might be fast enough, which is what really matters in the end. (Shutt's homepage offers the "official" interpreter that goes along with the thesis, and even he admits that it's painfully slow).
    - qwertyuiop924 11y ago
      Indeed. Thanks for letting me know. So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time? Or is it something else? Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments? I'm assuming I'm missing something, because somebody must have tried that by now. Or you could just `quote` the call yourself, like TCLers do.
      - groovy2shoes 11y ago
        > So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time? That's part of it. But the bigger issue is, I think, that you can't even generally compile[0] the arguments before runtime, because you don't necessarily know what expressions they'll be by the time they get evaluated. > Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments? That's exactly what they are, along with the environment at the call site. Then, when (and if) you need the arguments to be evaluated, you do it explicitly with a call to `eval`. But keep in mind that the fexpr body is free to modify those arguments as data before evaluating them. > Or you could just `quote` the call yourself, like TCLers do. Tcl is similarly a very difficult language to compile and/or optimize. [0]: I mean ahead-of-time compilation here. I don't see any reason why a JIT compiler couldn't be effective.

Kernel is what I really want scheme to be. It's like scheme, but better. And if you're wondering why I say better, more first-class objects is always a good thing.

shasta 11y ago

That's a pretty simplistic explanation. There are lots of ways to mess up Lisp in an attempt to enable the style of meta-programming that Kernel supports. What distinguishes Kernel from these other approaches (many of which have been seriously considered in the past) is mostly what you're not able to do in Kernel. That is, the vau construct still allows encapsulation in a useful way. Kernel may have "more things first class" than Lisp, but that's not all that sets it apart.

deleted 11y ago
[deleted]
qwertyuiop924 11y ago
That's certainly one way of looking at it, and it IS one of the reasons I like kernel. fexprs > macros because of this.

sklogic 11y ago

> more first-class objects is always a good thing Only if they're not enforcing some (actually, the worst possible) evaluation strategy.

qwertyuiop924 11y ago
True, I suppose.

groovy2shoes 11y ago

When you get first-class fexprs, you pay for it in performance. They're nearly impossible to compile, and even interpreting them efficiently is a challenge.

qwertyuiop924 11y ago
Read Sutt's paper, then decide if he didn't fix the performance problem. I haven't gotten around to it yet, so I'm not sure, but apparently $vau-calculus has some interesting properties.
- groovy2shoes 11y ago
  I read Shutt's thesis back when he first published it. I'll admit I'm due for another reading. The vau calculus is indeed very interesting, but there are fundamental reasons why fexprs can't be implemented efficiently (at least, not on commodity hardware). Of course, depending on your use-case, they might be fast enough, which is what really matters in the end. (Shutt's homepage offers the "official" interpreter that goes along with the thesis, and even he admits that it's painfully slow).
  - qwertyuiop924 11y ago
    Indeed. Thanks for letting me know. So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time? Or is it something else? Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments? I'm assuming I'm missing something, because somebody must have tried that by now. Or you could just `quote` the call yourself, like TCLers do.
    - groovy2shoes 11y ago
      > So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time? That's part of it. But the bigger issue is, I think, that you can't even generally compile[0] the arguments before runtime, because you don't necessarily know what expressions they'll be by the time they get evaluated. > Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments? That's exactly what they are, along with the environment at the call site. Then, when (and if) you need the arguments to be evaluated, you do it explicitly with a call to `eval`. But keep in mind that the fexpr body is free to modify those arguments as data before evaluating them. > Or you could just `quote` the call yourself, like TCLers do. Tcl is similarly a very difficult language to compile and/or optimize. [0]: I mean ahead-of-time compilation here. I don't see any reason why a JIT compiler couldn't be effective.