Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

μLithp - a Lisp in 27 lines of Ruby

fogus.github.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: μLithp - a Lisp in 27 lines of Ruby

#91

Post by joethephish »

Not sure what this proves exactly. For fun, here's a Javascript equivalent in 27, err, "lines":

    module.exports = function() {
        var atom = function(val) { return val instanceof Array ? false : true; };
        var env = {
            label:  function(sexpr, senv) { senv[sexpr[1]] = evaluate( sexpr[2] ); },
            quote:  function(sexpr, senv) { return sexpr[1]; },
            "==":   function(sexpr, senv) { return evaluate(sexpr[1], senv) == evaluate(sexpr[2], senv); },
            head:   function(sexpr, senv) { return evaluate(sexpr[1], senv)[0]; },
            tail:   function(sexpr, senv) { return evaluate(sexpr[1], senv).slice(1); },
            conc:   function(sexpr, senv) { return [evaluate(sexpr[1])].concat(evaluate(sexpr[2])); },
            "if":   function(sexpr, senv) { return evaluate(sexpr[1], senv) ? evaluate(sexpr[2], senv) : evaluate(sexpr[3], senv); },
            atom:   function(sexpr, senv) { return atom(sexpr[1]); },
            lambda: function(sexpr, senv) {
                return function(lexpr, lenv) {
                    for(var i=0; i
Example:

    var notlisp = require("./notlisp.js"); 
    var l = new notlisp();
    l.evaluate( ["label", "second", ["lambda", ["x"], ["head", ["tail", "x"]]]] );
    l.evaluate( ["second", ["quote", [1, 2, 3]] ] );

Re: μLithp - a Lisp in 27 lines of Ruby

#92

Post by [deleted] »

joethephish wrote: post #91

Not sure what this proves exactly. For fun, here's a Javascript equivalent in 27, err, "lines": module.exports = function() { var atom = function(val) { return val instanceof Array ? false : true; }; var env = { label: function(sexpr, senv) { senv[sexpr[1]] = evaluate( sexpr[2] ); }, quote: function(sexpr, senv) { return sexpr[1]; }, "==": function(sexpr, senv) { return evaluate(sexpr[1], senv) == evaluate(sexpr[2],…

[deleted]

Re: μLithp - a Lisp in 27 lines of Ruby

#93

Post by takikawa »

wonderzombie wrote: post #88
dschiptsov wrote: post #72

Earlier quoted context omitted.

Clojure is immutable by default what does this sentence mean? How Scheme is less immutable by default? Which data-structures are not first class "objects" in Scheme?

Again, I don't have much experience with Scheme; I've read about half of SICP. So that's a huge caveat here. It may have been misleading to say that Clojure was immutable by default. It is immutable; it does not have set! or the moral equivalent. You can use concurrency primitives to update in place (sort of? AFAICT you're mutating the var itself, not the data it contains) but each primitive comes with its own semant…

In Racket, any custom data type can be turned into a function by using the `prop:procedure` structure type property. It's usually not done with things like maps and sets because this kind of "punning" is not idiomatic. Being a function is not actually a necessary condition for being "first-class" though.

Re: μLithp - a Lisp in 27 lines of Ruby

#94

Post by stcredzero »

JasonFruit wrote: post #82
stcredzero wrote: post #26

Earlier quoted context omitted.

> If it was that important, we'd all be using J or APL. Fallacy. You haven't eliminated the possibility that line count is important, but also that too few lines is also bad. It's widely understood that line count, even though it's a hazy and exploitable metric, is indeed important. It's also widely understood that being too terse is as bad as being too verbose. Time to brush up on some old-school CS curriculum books…

I haven't proved anything, true — I was illustrating a point with an example, not writing a series of syllogisms. What I meant to do was to direct the reader to the broader idea that our language usage doesn't suggest that line count is a pressing concern past a point that allows for considerable verbosity. Now, wasn't it more enjoyable the way I put it first?

It's more accurate and less misleading the way you put it second. The way you put it first, it suggests that you've shown that line counts don't matter.

Re: μLithp - a Lisp in 27 lines of Ruby

#95

Post by dschiptsov »

wonderzombie wrote: post #88
dschiptsov wrote: post #72

Earlier quoted context omitted.

Clojure is immutable by default what does this sentence mean? How Scheme is less immutable by default? Which data-structures are not first class "objects" in Scheme?

Again, I don't have much experience with Scheme; I've read about half of SICP. So that's a huge caveat here. It may have been misleading to say that Clojure was immutable by default. It is immutable; it does not have set! or the moral equivalent. You can use concurrency primitives to update in place (sort of? AFAICT you're mutating the var itself, not the data it contains) but each primitive comes with its own semant…

This is rather tricky subject - to understand real behavior - what is behind this or that a syntactic sugar.

In Scheme, for example, we could implement any data-structure as a closure, which accepts messages. There is no difficulty in writing such wrappers - it is just a closure which return another closure which accepts "messages", and following some protocol, returns, for example, another closures to be called for a certain action (generators, iterators, etc.)

We could teach the read function to recognize any kind of wired syntax we wish, and constructing appropriate data-structures with type-tags attached to them. But it will become a mess.

The real data-structures, however, its representation is very different thing. In Clojure, I suppose, it is based on built-in Java types and generic interfaces, such as Iterable or whatever it is. So, they are ordinary Java objects, without any magic in it.

In Scheme or CL it depends on the implementation, the choices made by developers. So, for example, Gambit-C and MIT Scheme are quite different in how they implement hash-tables or vectors. My guess is that, say Alegro CL and CMUCL are also very different, yet they all conform to some standards (CLtL2, ANSI).

Having very different implementations with different set of compromises is a strength.

So, in my opinion, there is absolutely nothing special in this syntactic constructions, moreover, it is not that difficult to implement them using closures and macroses. In arc.arc you could see how strings and tables were implemented.

Another issue is, should we add all this wired syntax to what we call Lisp? In my opinion doing this ruins Lisp and the result is some very different in a look-and-feel language. Calling it Lisp is, well, confusing, at least to me. Arc is a Lisp, no doubt. CL and Scheme are Lisps, for sure. Clojure is Java with lisp-like syntax, if you wish.)

The old rules says that there must be very heavy reasons to add any new symbol or a keyword into a language, and that the same things shall look the same, and different - differently. For me, personally, Arc is a proper approach, while Clojure is, well, a mess.)

Re: μLithp - a Lisp in 27 lines of Ruby

#96

Post by chongli »

wonderzombie wrote: post #90
klibertp wrote: post #85

Earlier quoted context omitted.

Sad (for me) difference: tail call optimization, done automatically in Schemes, unavailable in Clojure. I know of recur and trampoline, but recur does not (I think?) work with mutual recursion and if I wanted to use trampoline, I'd be coding in JavaScript :) Personally I dislike Clojure's syntax - Scheme's feels more pure, cleaner. It's a bit like PERL vs. Python, a matter of taste largely.

I don't believe recur works with mutual recursion. I wish I understood mutual recursion better, frankly. Got any pointers about how one might use it in practice? In general my Lisp-fu could use a lot of improvement. I would call it more like Ruby vs. Python — c'mon, perl? that's just mean — but yes, we're quibbling. :)

>Got any pointers about how one might use it in practice?

The meta-circular evaluator is a prime example of mutual recursion. It consists of two functions, eval and apply, which call each other in a circular fashion until a result is reached.

Re: μLithp - a Lisp in 27 lines of Ruby

#97

Post by chongli »

dschiptsov wrote: post #95
wonderzombie wrote: post #88

Earlier quoted context omitted.

Again, I don't have much experience with Scheme; I've read about half of SICP. So that's a huge caveat here. It may have been misleading to say that Clojure was immutable by default. It is immutable; it does not have set! or the moral equivalent. You can use concurrency primitives to update in place (sort of? AFAICT you're mutating the var itself, not the data it contains) but each primitive comes with its own semant…

This is rather tricky subject - to understand real behavior - what is behind this or that a syntactic sugar. In Scheme, for example, we could implement any data-structure as a closure, which accepts messages. There is no difficulty in writing such wrappers - it is just a closure which return another closure which accepts "messages", and following some protocol, returns, for example, another closures to be called for…

>So, in my opinion, there is absolutely nothing special in this syntactic constructions, moreover, it is not that difficult to implement them using closures and macroses. In arc.arc you could see how strings and tables were implemented.

You're right, there is nothing special about what Clojure does; everything could be implemented in Scheme just fine. The real advantage comes from the fact that these things are there "out of the box" so that libraries are written to use them.

There is a lot of inertia when it comes to libraries in a language. In some sense, you only get one chance to get it "right" before everything becomes interdependent and you can no longer change anything. Clojure's advantage is simply that it presented a chance to start over and get things right from the beginning.

Re: μLithp - a Lisp in 27 lines of Ruby

#98

Post by chongli »

dschiptsov wrote: post #77
guard-of-terra wrote: post #74

Earlier quoted context omitted.

What's the problem with Clojure?: (defmacro when "Evaluates test. If logical true, evaluates body in an implicit do." {:added "1.0"} [test & body] (list 'if test (cons 'do body))) Moreover, what's the problem with μLithp? l.eval [:label, :second, [:quote, [:lambda, [:x], [:car, [:cdr, :x]]]]] l.eval [:second, [:quote, [1, 2, 3]]] Seems list-y enough for me. I have a feeling that you didn't actually read the article.

There isn't any problem with this Clojure macro. If you would like to see problems with Clojure, take a look at keep function in core.clj. There is a classic function: (define (filter fn l) (cond ((null? l) '()) ((fn (car l)) (cons (car l) (filter fn (cdr l)))) (else (filter fn (cdr l))))) The point is that stuffing more data-structures into a lisp ruins it. Somehow switching to the prefix notation and adding parenth…

>The point is that stuffing more data-structures into a lisp ruins it.

Could you please support this assertion?

Re: μLithp - a Lisp in 27 lines of Ruby

#99

Post by wonderzombie »

chongli wrote: post #97
dschiptsov wrote: post #95

Earlier quoted context omitted.

This is rather tricky subject - to understand real behavior - what is behind this or that a syntactic sugar. In Scheme, for example, we could implement any data-structure as a closure, which accepts messages. There is no difficulty in writing such wrappers - it is just a closure which return another closure which accepts "messages", and following some protocol, returns, for example, another closures to be called for…

>So, in my opinion, there is absolutely nothing special in this syntactic constructions, moreover, it is not that difficult to implement them using closures and macroses. In arc.arc you could see how strings and tables were implemented. You're right, there is nothing special about what Clojure does; everything could be implemented in Scheme just fine. The real advantage comes from the fact that these things are there…

Right, yes: what ships with the language shapes the way the language is used, and has wider impacts beyond what you could theoretically or even practically do with it.

A dumb example would be a Option/Maybe type in Java. You could write a good approximation. But none of the standard libraries would use it, let alone any user supplied libs. Lisps are different in some very important ways, but since this is in part a meatspace phenomenon, it's still a challenge. Somebody went so far as to call it The Lisp Curse[0].

Anyway, syntax is a matter of taste, though I think people focus too much on it one way or the other— people don't like s-expressions b/c parens, people don't like Clojure b/c brackets/braces/whatever.

So while I agree that Clojure syntax isn't a huge game-changer, it can and does improve the quality of life for some people, myself included. Built-in literals are a big deal. And there is a lot to be said for being able to use these as primitives on day 1 of learning Clojure, esp. as your first Lisp.

[0]: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html.

Re: μLithp - a Lisp in 27 lines of Ruby

#100

Post by wonderzombie »

takikawa wrote: post #93
wonderzombie wrote: post #88

Earlier quoted context omitted.

Again, I don't have much experience with Scheme; I've read about half of SICP. So that's a huge caveat here. It may have been misleading to say that Clojure was immutable by default. It is immutable; it does not have set! or the moral equivalent. You can use concurrency primitives to update in place (sort of? AFAICT you're mutating the var itself, not the data it contains) but each primitive comes with its own semant…

In Racket, any custom data type can be turned into a function by using the `prop:procedure` structure type property. It's usually not done with things like maps and sets because this kind of "punning" is not idiomatic. Being a function is not actually a necessary condition for being "first-class" though.

I agree that it's not necessary. But it's a very strong signal, and thus illustrative.

AFAICT there is not a well-understood definition of first-class outside of "first-class functions." If I had to nail it down, I'd probably include the notion of first-class as applied to functions, plus:

* literal representations (where applicable) * idiomatic, as demonstrated/enabled by the standard library * well-integrated/interop with other primitives

This is just off the top of my head. And sometimes this is relative to other constructs in the language, or fuzzier, like Haskell lists vs. maps vs. sets.

Post reply on HN