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

Racket – Lisp beyond Clojure

slides.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Racket – Lisp beyond Clojure

#141

Post by Jach »

imagist wrote: post #138
Jach wrote: post #80

Earlier quoted context omitted.

I'll just leave two of my old comments here... https://news.ycombinator.com/item?id=10207199 and https://news.ycombinator.com/item?id=3423646 Short summary: I do think on HN it's reasonable to assume "Lisp" without further qualification to refer to the lisp family. The usefulness of the lisp family idea (which afaict is having sexps and maybe something like defmacro) is questionable. Among Lisp and lisp-family practi…

> I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common. I just don't think "correctly" and "incorrectly" are words that have meaning when it comes to semantics. I care more about your goals. If your goal is to have "Lisp" mean "Common Lisp", then you can try to enforce that, but it's a strange goal…

Here are some ways words can be incorrect: http://lesswrong.com/lw/od/37_ways_that_words_can_be_wrong/

In the end it's not a very fulfilling battle even if won, to preserve the meaning of a word. I always liked the line "In the face of ambiguity, refuse the temptation to guess" as a guide to be more explicit and ask for clarification in general communication.

Re: Racket – Lisp beyond Clojure

#142

Post by qwertyuiop924 »

phyrex wrote: post #136
qwertyuiop924 wrote: post #70

Earlier quoted context omitted.

Well, real conses would be nice, for a start...

why?

There are all kinds of useful structures that you can make out of conses: trees (with two cells per node), infinite lists, and so on. They're also useful in conveying intent.

Re: Racket – Lisp beyond Clojure

#143

Post by phyrex »

qwertyuiop924 wrote: post #142
phyrex wrote: post #136

Earlier quoted context omitted.

why?

There are all kinds of useful structures that you can make out of conses: trees (with two cells per node), infinite lists, and so on. They're also useful in conveying intent.

I don't see why you can't make those out of the data structures provided - or even the Clojure conses?

Re: Racket – Lisp beyond Clojure

#144

Post by qwertyuiop924 »

phyrex wrote: post #143
qwertyuiop924 wrote: post #142

Earlier quoted context omitted.

There are all kinds of useful structures that you can make out of conses: trees (with two cells per node), infinite lists, and so on. They're also useful in conveying intent.

I don't see why you can't make those out of the data structures provided - or even the Clojure conses?

Well, it's nice to have a uniform cell structure, and you can't make them out Clojure conses, because Clojure conses don't really have a cdr, not as such, as Clojure's cdr cannot contain arbitrary data.

Re: Racket – Lisp beyond Clojure

#145

Post by ufo »

optforfon wrote: post #112
senex wrote: post #107

Earlier quoted context omitted.

When TCO is "lexically scoped" like loop/recur, the compiler can handle it. When HoF are involved, you may have a case where a procedure calls a procedure-parameter, which calls another, and another... Something about the runtime has to recognize this or else the compiler has to accept more constrains. See, for example, how Gambit-C implements tail calls by compiling modules to single C functions and how there is a t…

Okay, but at that point you're talking about things that are way beyond the capabilities of an iterative loop. I think my point still stands - that implementing a tail recursion in place of a loop is not something you will have to pay for. Both structures will map to the same instructions.

The difficulty with tail recursion optimization is related to calling conventions. Some calling conventions expect the caller to do some cleanup after the callee returns, which effectively means that no function calls actually occur in tail position. For example, in the C calling convention the caller caller is responsible for allocating and freeing the stack memory dedicated for the callee's function parameters. This system makes vararg functions like printf easy to implement but makes it hard to do TCO. Another example is Rust, where having destructors automatically run when a variable got out of scope prevented them from implementing TCO in a clean manner. I'm not familiar with the JVM internals but I think the limitations are going to be similar to the ones I mentioned here.

Re: Racket – Lisp beyond Clojure

#146

Post by ufo »

qwertyuiop924 wrote: post #132
mballantyne wrote: post #121

Earlier quoted context omitted.

Can you elaborate on how syntax-case "violates the macro abstraction", and maybe what you think is important about the quality it breaks? Not a description I've heard before. I do agree it is complicated!

The macro abstraction is that the AST is exposed as a series of lists, which is what macros process. Instead, syntax-case exposes 'syntax' objects, which are entirely distinct from any other datatype, and kind of complicated. This isn't a horrific sin (new macro abstractions pop up like rabbits, although they rarely change something so fundamental, at least in Lisp mavro systems), but if you're going to replace an ab…

I thought that the syntax objects resulted in better error messages, due to keeping track of source code position, lexical bindings for variables and so on. Isn't that worth the complexity?

Re: Racket – Lisp beyond Clojure

#147

Post by nickpsecurity »

pjmlp wrote: post #130
nickpsecurity wrote: post #55

Earlier quoted context omitted.

We cant entirely blame them: those cost significant money while mainstream stuff usually has free IDE's that are good without limitations. Allegro even mentioned royalties last time I looked at them. Royalties!? Only natural hobbyists overlook this. But, yes, LispWorks and Allegro are very powerful environments. Comparing AllegroCache to Hibernate might be fun for newcomers too. Haha.

I guess we were spoiled by being able to have seen such environments, back when it was common to pay for software tools. Even Macintosh Common Lisp would already have been a good experience. http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

That was pretty interesting. Especially that the Mac CL survived so long in about the same form. The one thing that confused me was Apple acquiring "Allegro" Common LISP. That's name of Franz's product. History of Franz says nothing about Apple. I'm assuming they're different products with the same name just to trip us archaeologists up?

Re: Racket – Lisp beyond Clojure

#148

Post by lispm »

technomancy wrote: post #135
armitron wrote: post #32

Earlier quoted context omitted.

There are plenty of module systems already there. If you want racket-style modules you can also have them by implementing them.

Great solution if you never want to use code anyone else has written. To be fair this seems like a pretty common mindset in CL-land.

ASDF as a system building tool is widely used in CL-land.

> To be fair this seems like a pretty common mindset in CL-land.

My Lisp Machine has around 60000 functions, and I have only written a tiny fraction of them... Strange. If nobody else has written them, where are they coming from?

Re: Racket – Lisp beyond Clojure

#149

Post by imagist »

Jach wrote: post #141
imagist wrote: post #138

Earlier quoted context omitted.

> I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common. I just don't think "correctly" and "incorrectly" are words that have meaning when it comes to semantics. I care more about your goals. If your goal is to have "Lisp" mean "Common Lisp", then you can try to enforce that, but it's a strange goal…

Here are some ways words can be incorrect: http://lesswrong.com/lw/od/37_ways_that_words_can_be_wrong/ In the end it's not a very fulfilling battle even if won, to preserve the meaning of a word. I always liked the line "In the face of ambiguity, refuse the temptation to guess" as a guide to be more explicit and ask for clarification in general communication.

Yeah, 17-20 in that link do a better job of expressing what I wanted to express than I did. :)

Re: Racket – Lisp beyond Clojure

#150

Post by imagist »

junke wrote: post #139
imagist wrote: post #138

Earlier quoted context omitted.

> I agree with your argument about common usage but I'm not sure what the common usage on HN really is and what's a vocal minority using it incorrectly until it becomes common. I just don't think "correctly" and "incorrectly" are words that have meaning when it comes to semantics. I care more about your goals. If your goal is to have "Lisp" mean "Common Lisp", then you can try to enforce that, but it's a strange goal…

An article that would title "Lisp beyond Clojure" would indeed talk about the Lisp family of languages. What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure" . And that is the main problem I have with the title. The ideal title would be IMO "What could Clojure learn from Racket" .

If you understand what the title means well enough to object to its usage, that's solid proof that the title has communicated effectively.

> What is a very bad in that title is that it focuses on Racket, just as if the title was: "Racket - this is how Lisp looks like beyond Clojure".

That's your own interpretation--you could easily have interpreted it as "Racket--an example of a Lisp beyond Clojure".

Post reply on HN