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

31–40 of 108 posts

Re: Differences with other Lisps

#31

Post by rawoke083600 »

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…

Interesting ! Thank you for the examples. Yes Racket is also on my someday-soon-list !

Re: Differences with other Lisps

#32

Post by rawoke083600 »

ltultraweight wrote: post #30
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…

As someone that was a hardcore Lisper (you could find me arguing that Scheme is not a Lisp, etc.) before adopting Clojure: I thought muddying the language with a new kind of syntax was terrible. I don't suggest that this is what primarily drove the lack of adoption of other kind of braces but I, as a follower of the church of Lisp, had an immense dislike of the lack of purity. In the end vector and map "syntax" is ju…

>A pragmatic Lisp..

As a newbie(with zero social-capital) I couldn't agree more !

Re: Differences with other Lisps

#33

Post by patrec »

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…

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]) ...) is a common idiom, although old-school people stick to ().

Common lisp has stuff like loop, () aliased to nil (different connotations), and a verbose way to call passed or returned functions; it shares its infix pair syntax (head . tail) with scheme. Scheme, unlike common lisp has a pretty complex (hah) infix-syntax for complex number literals; both write rationals infix.

And have a look at the Lisp 1.5 manual some time :)

As far as such hacks go, this use of vectors in clojure is actually quite nice. Whereas the fact that clojure, unlike other lisps, uses "invisible" pairing brackets in binding constructs or "visible" whitespace in the form of commas for associative containers is a big pain in the ass for editing and formatting code.

[edit: fixed idiomatic let bracket/paren split, as pointed out by version_five]

Re: Differences with other Lisps

#34

Post by Munksgaard »

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…

In Clojure, `[1 2 3]` is a vector, which is a distinct data type from a list, which looks like `(1 2 3)`. A vector in Common Lisp is written using `#(1 2 3)`.

Using vectors for function arguments is unique to Clojure, and I'm not entirely sure why they chose to do it that way.

Re: Differences with other Lisps

#35

Post by pjmlp »

rawoke083600 wrote: post #26

I know there are some very good projects out there, but if I could "wish" any software into existence: It would be nice to have an "enterprise-level" LISP-To-GoLang environment WITH a massive library of course. There is just something nice about the Go-Lang eco-system and compiling to static binary, not too many XML/JVM magic.

It is replaced by //go:generate, interface{} and struct tags magic.

Re: Differences with other Lisps

#36

Post by pjmlp »

rawoke083600 wrote: post #29
staplung wrote: post #12

Earlier quoted context omitted.

Go (2009), TypeScript (2012), Julia (2012) and Swift (2014) are all contenders

PHP(2005..n) for when you fail the interview for the above "fancy lang" at FAANG :P PHP is like the backup-plan(welder,lawyer etc) your parents wanted you to have before going out on the road with your band and making it big :D /mostly-sarcasm - but a little true ?

It is, a friend built a consultancy doing PHP, and they have enough work to keep them going, keep the lights on, and focus on other stuff relevant to them.

PHP would actually be (1998...n), PHP 3 was when it took off.

Re: Differences with other Lisps

#37

Post by rawoke083600 »

pjmlp wrote: post #36
rawoke083600 wrote: post #29

Earlier quoted context omitted.

PHP(2005..n) for when you fail the interview for the above "fancy lang" at FAANG :P PHP is like the backup-plan(welder,lawyer etc) your parents wanted you to have before going out on the road with your band and making it big :D /mostly-sarcasm - but a little true ?

It is, a friend built a consultancy doing PHP, and they have enough work to keep them going, keep the lights on, and focus on other stuff relevant to them. PHP would actually be (1998...n), PHP 3 was when it took off.

>PHP would actually be (1998...n), PHP 3 was when it took off.

Yea was wondering what to put as a start date, I decided on the year I left varsity and walked into my first "professional job" coding C++ (Borland C++ Builder) within 6 months, we changed the "C++ Server" with Apache and some wacky PHP files.

But you are right :)

Re: Differences with other Lisps

#38

Post by bjoli »

patrec wrote: post #33
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…

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

Re: Differences with other Lisps

#39

Post by fiddlerwoaroof »

remontoire wrote: post #24
fiddlerwoaroof wrote: post #13

Earlier quoted context omitted.

This isn’t really a thing, though: Common Lisp has built-in literal syntax for n-dimensional arrays and structs and libraries like fset provide literal syntax for Clojure-style immutable data structures.

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 uses named-readtables to use arbitrary reader macros.

I don't understand the "interop reasons" you're talking about: as long as you use named-readtables, interop basically Just Works.

> It's also not possible to put those on the wire (easily) for communication between common lisp processes. Breaking the whole point of homoiconicity.

Using the reader on untrusted input is a bad idea in either Common Lisp or Clojure, because both readers can execute arbitrary code. However, there are packages like safe-read ( https://github.com/phoe/safe-read ) and Eclector ( https://github.com/s-expressionists/eclector ) that let you solve this problem pretty trivially in a safe way. Not to mention projects like my cl-edn ( https://github.com/fiddlerwoaroof/cl-edn ).

Post reply on HN