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

Differences with other Lisps

clojure.org

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Differences with other Lisps

#41

Post by tralarpa »

linguae wrote: post #28
rawoke083600 wrote: post #25

Maybe a more seasoned LISP-`aterian` can answer me ? I'm in the process of learning ClojureScript - real fun so far. I have of course also looked at other LISPs and have noticed that in CJS the use of square brackets[] for vectors, let and `function params` (defn myfunc [] (let [some-var (:some-key some-state)]) (.log js/console some-var) ) I almost never see square brackets in other LISPs (yes I'm truly a beginner a…

Racket also optionally supports a square bracket syntax for cons clauses. For example, in traditional Scheme one would write: ; this is in R5RS Scheme (define (length elems) (cond ((null? elems) 0) (else (+ 1 (length (cdr elems)))))) But in Racket one would write: ; this is in Racket (define (length elems) (cond [(empty? elems) 0] [else (+ 1 (length (rest elems)))])) It is also used in let/let*/letrec bindings in Rac…

> It is also used in let/let*/letrec bindings in Racket

I suppose this is just a personal choice of the author of the manual, right? Please correct me if I am wrong but I thought Racket doesn't care whether you use brackets, parentheses, or even curly brackets.

Re: Differences with other Lisps

#42

Post by mathisonturing »

staplung wrote: post #10

In many ways I feel like Clojure is a better Lisp than Lisp itself. Syntactic niceties like support for vectors/maps/sets are, once you've gotten used to them, hard to do without. And although it's orthogonal to the syntax, I also appreciate its focus on immutability. I just with there was a Lisp like it that didn't run on the JVM.

Curious - why is running on JVM bad?

Re: Differences with other Lisps

#43

Post by [deleted] »

fiddlerwoaroof wrote: post #39
remontoire wrote: post #24

Earlier quoted context omitted.

I've used fset and cl21. The problem is that once you start using those you no longer are able to use libraries. Data structures have to be built into core. The common lisp community has rejected reader macros for interop reasons the last time I checked (in the case of cl21) Even the docs for fset doesn't show the use of data literals. it does things like (set) and (isetq s2 (set 'c 1 "foo" 'a 'c)) This pretty much p…

> once you start using those you no longer are able to use libraries This isn't true: if the libraries you use are designed to use generic functions for their internals, rather than normal functions. I've written code using custom data structures heavily, with little or no impact on which libraries I could use. > The common lisp community has rejected reader macros cl21 is just confusing matters here. Plenty of code…

[deleted]

Re: Differences with other Lisps

#44

Post by patrec »

bjoli wrote: post #38
patrec wrote: post #33

Earlier quoted context omitted.

The reality is that just about every single lisper will insist how they don't see the parenthesis and they are not a problem, and just about every single lisp has some ugly ad hoc hacks to reduce their clutter. They just differ somewhat between lisps. Scheme (and descendants like racket) went so far as to make [] and () interchangeable. So you will in fact see brackets in some scheme most e.g. (let ([a 1] [b 2]) ...)…

Only R6RS made () and [] interchangeable. That was hugely controversial, with opponents (myself included) thinking it was a waste of 1/3 of the matching pair symbols. And the suggested use was not quite the syntax you showed: http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-5.html

I fully agree (and thanks for the idiomatic let bracket ordering correction). But the fact that terribly hacks like this are nonetheless adopted shows how much of a pain the paren clutter is and that claims to the contrary are pure cope.

Re: Differences with other Lisps

#45

Post by Jach »

rawoke083600 wrote: post #25

Maybe a more seasoned LISP-`aterian` can answer me ? I'm in the process of learning ClojureScript - real fun so far. I have of course also looked at other LISPs and have noticed that in CJS the use of square brackets[] for vectors, let and `function params` (defn myfunc [] (let [some-var (:some-key some-state)]) (.log js/console some-var) ) I almost never see square brackets in other LISPs (yes I'm truly a beginner a…

Using [] for syntax like Clojure does is kind of weird and not too consistent IMO. As for data structures, CL has vectors (and more complex arrays), with #() as a literal syntax or my preference just the function (vector ...). But beyond that, CL is just not nearly as opinionated as other languages. You are free to define a function named [] as a wrapper around aref, if you wanted to write things like ([] array index), or you can define a reader macro that uses [ or ] and use them to implement whatever syntactic sugar you desire. That might be as an alternative to #() for vector literals and similar to Clojure, or something that mixes in commas and is more similar to JSON (https://gist.github.com/chaitanyagupta/9324402), or it could be to use them as syntax where you'd usually use ()s, or as some lambda shorthand e.g. [* _ 10] as shorthand for (lambda (_) (* _ 10)), or as sugar to wrap a special text type (e.g. [hello world] produces an object that wraps the string "hello world"), or to have List Comprehensions e.g. this paper from 1991: https://3e8.org/pub/scheme/doc/lisp-pointers/v4i2/p16-lapalm... whose code (that still works) in figure 2 + the bits right after to the set-macro-character calls lets you write things like [x (x <- xs) (oddp x)] to filter out odds, or [(* x x) (x <- xs)] to get squares, and you can do things with multiple lists. Or something else. Ultimately, it comes back to CL letting you do what you want.

Re: Differences with other Lisps

#46

Post by deckard1 »

bjoli wrote: post #38
patrec wrote: post #33

Earlier quoted context omitted.

The reality is that just about every single lisper will insist how they don't see the parenthesis and they are not a problem, and just about every single lisp has some ugly ad hoc hacks to reduce their clutter. They just differ somewhat between lisps. Scheme (and descendants like racket) went so far as to make [] and () interchangeable. So you will in fact see brackets in some scheme most e.g. (let ([a 1] [b 2]) ...)…

Only R6RS made () and [] interchangeable. That was hugely controversial, with opponents (myself included) thinking it was a waste of 1/3 of the matching pair symbols. And the suggested use was not quite the syntax you showed: http://www.r6rs.org/final/html/r6rs-app/r6rs-app-Z-H-5.html

Scheme reports lag, though. They usually codify what existing Scheme compiler/interpreters are already doing. I know I've seen plenty of Scheme code in the wild using square brackets interchangeably long before R6RS came out. You can even see the rationale behind this in the Scheme FAQ on Scheme Wiki, which seems to not have been updated since R5RS was current [1]

[1] http://community.schemewiki.org/?scheme-faq-language#H-yoyi8...

Re: Differences with other Lisps

#47

Post by remontoire »

fiddlerwoaroof wrote: post #39
remontoire wrote: post #24

Earlier quoted context omitted.

I've used fset and cl21. The problem is that once you start using those you no longer are able to use libraries. Data structures have to be built into core. The common lisp community has rejected reader macros for interop reasons the last time I checked (in the case of cl21) Even the docs for fset doesn't show the use of data literals. it does things like (set) and (isetq s2 (set 'c 1 "foo" 'a 'c)) This pretty much p…

> once you start using those you no longer are able to use libraries This isn't true: if the libraries you use are designed to use generic functions for their internals, rather than normal functions. I've written code using custom data structures heavily, with little or no impact on which libraries I could use. > The common lisp community has rejected reader macros cl21 is just confusing matters here. Plenty of code…

It looks like you're right for the most part. Literals are supported if you use https://github.com/vseloved/rutils. If your cl-edn actually works then a combo of rutils and cl-edn could bring most of the value I found in clojure to common lisp.

Re: Differences with other Lisps

#48

Post by slgeorge »

rawoke083600 wrote: post #27
naruhodo wrote: post #15

Earlier quoted context omitted.

> I just with there was a Lisp like it that didn't run on the JVM. There are a few, with varying degrees of distance from the JVM and varying degrees of similarity to Clojure. - There's ClojureScript, which is Clojure transpiled to JavaScript. - See also Lumo ( ) and Planck ( ) - There's Babashka ( https://github.com/babashka/babashka ), which is a natively-compiled Clojure interpreter, implemented with the Small Clo…

These projects are great and definitely needed as a first requirement for an extensive 3rd-party-library. Been looking around at LISPs/CJ and there doesn't seem a very up2date library for dynamic-web-scraping or controlling headless-Chrome. Compared say to Golang. Of course this a nitpick and a sample size of one :)

For Clojure on the JVM I've seen etaoin (https://github.com/igrishaev/etaoin) and there's clj-chrome-devtools (https://github.com/tatut/clj-chrome-devtools). I would ask on Clojureverse or the Clojure Slack/Zulip for opinions.

For ClojureScript I guess there's lots of options since you can access the Javascript ecosystem.

One of the benefits of being hosted is that we can always fall back on the host language's options.

Re: Differences with other Lisps

#49

Post by lispm »

The bigger picture: Clojure was designed with no backwar(d/t)s compatibility.

https://clojure.org/about/rationale#_lisp_is_a_good_thing

> Clojure is a Lisp not constrained by backwards compatibility

Which means that basically no (!) Lisp software from the past ran in Clojure and trying to make it results in a re-implementation and re-architecture of that software.

Re: Differences with other Lisps

#50

Post by kaba0 »

lispm wrote: post #49

The bigger picture: Clojure was designed with no backwar(d/t)s compatibility. https://clojure.org/about/rationale#_lisp_is_a_good_thing > Clojure is a Lisp not constrained by backwards compatibility Which means that basically no (!) Lisp software from the past ran in Clojure and trying to make it results in a re-implementation and re-architecture of that software.

So the 3 lisp programs will be missed..

Sarcasm aside, seeing the resulting popularity of Clojure, I don’t think at all that this tradedoff was not worthy. Depending on Java/Js’s much much richer ecosystem is a win.

Post reply on HN