# if the partisans of LISP loved it so much, why didn't they adapt it to other frameworks? **URL:** \ **Category:** Factual Questions\ **Created:** [April 12, 2011, 5:08pm UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113 "2011-04-12T17:08:27Z")\ **Posts on this page:** 8\ **Page:** 3
**Author:** ![Superfluous\_Parentheses](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@Superfluous\_Parentheses](https://boards.straightdope.com/u/Superfluous_Parentheses)\ **Post date:** [April 16, 2011, 12:17am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/41 "2011-04-16T00:17:21Z")
> [@ultrafilter](#): > > (4) is a bit eccentric, but there was a time when not every C++ compiler implemented operator precedence correctly, so it did pay to be explicit about how expressions should be evaluated. But that still doesn’t explain _that_. There is no sense in C++ that (a OPERATOR b) is ever going to give you a different result from ((a) OPERATOR (b)) if a and b are atoms/symbols/whatever-you-call-them. No matter how many bugs or misunderstandings there are about precedence. ---
**Author:** ![Derleth](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Derleth](https://boards.straightdope.com/u/Derleth)\ **Post date:** [April 16, 2011, 12:18am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/42 "2011-04-16T00:18:59Z")
> [@Superfluous\_Parentheses](#): > > But that still doesn’t explain _that_. There is no sense in C++ that (a OPERATOR b) is ever going to give you a different result from ((a) OPERATOR (b)) if a and b are atoms/symbols/whatever-you-call-them. Hm… is it possible to overload the parentheses in C++? (Wonderful (username), (by) the (way)!) ---
**Author:** ![Superfluous\_Parentheses](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@Superfluous\_Parentheses](https://boards.straightdope.com/u/Superfluous_Parentheses)\ **Post date:** [April 16, 2011, 12:28am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/43 "2011-04-16T00:28:06Z")
> [@Derleth](#): > > Hm… is it possible to overload the parentheses in C++? Argh. Oh god. Yes there is, but AFAIK not for (parentheses); but you can overload parentheses(…), and I think also parentheses[…] - like that; based on the type of the var named “parentheses”. Pure “grouping” parentheses cannot be overloaded I think. > [@](#): > > (Wonderful (username), (by) the (way)!) Cheers 🙂 ---
**Author:** ![Derleth](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Derleth](https://boards.straightdope.com/u/Derleth)\ **Post date:** [April 16, 2011, 12:45am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/44 "2011-04-16T00:45:26Z")
> [@Superfluous\_Parentheses](#): > > parentheses(…), and I think also parentheses[…] [Hum, terminology.](http://i237.photobucket.com/albums/ff28/beatonna/DSC_4923-1.jpg) ([Via](http://beatonna.livejournal.com/143952.html)) I’d only call the first set of groupers (parentheses), and the second [square brackets], as distinct from \ and {curly brackets}. But then, I’m an American. [Here’s some other schemes I know of](http://www.elsewhere.org/jargon/jargon.html#ASCII) and [an apposite poem.](http://www.ascii-art.de/ascii/pqr/poem.txt) ---
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [April 16, 2011, 8:22am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/45 "2011-04-16T08:22:06Z")
> [@Derleth](#): > > No, the strongest argument is that if Lisp had a different syntax, it would be more difficult than necessary to make macros work, and macros are central to the Lisp universe. Macros really make Lisp as powerful as it is. Sure, but the reason it would be more difficult than necessary to make macros work would be because of the introduction of irregularity into the syntax… The reason that Lisp is such a macro-friendly language is precisely because the syntax is so simple and uniform. ---
**Author:** ![Derleth](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Derleth](https://boards.straightdope.com/u/Derleth)\ **Post date:** [April 16, 2011, 8:36am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/46 "2011-04-16T08:36:12Z")
> [@Indistinguishable](#): > > Sure, but the reason it would be more difficult than necessary to make macros work would be because of the introduction of irregularity into the syntax… The reason that Lisp is such a macro-friendly language is precisely because the syntax is so simple and uniform. Right. I was just aiming my reply at people who want a tangible result as opposed to a theoretical one, but of course the tangible result is a direct consequence of the improved abstract purity. ---
**Author:** ![Indistinguishable](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@Indistinguishable](https://boards.straightdope.com/u/Indistinguishable)\ **Post date:** [April 16, 2011, 8:37am UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/47 "2011-04-16T08:37:34Z")
Ah, gotcha. ---
**Author:** ![Heracles](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/heracles/32/487_2.png) [@Heracles](https://boards.straightdope.com/u/Heracles)\ **Post date:** [April 16, 2011, 4:37pm UTC](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113/48 "2011-04-16T16:37:04Z")
> [@Superfluous\_Parentheses](#): > > But that still doesn’t explain _that_. There is no sense in C++ that (a OPERATOR b) is ever going to give you a different result from ((a) OPERATOR (b)) if a and b are atoms/symbols/whatever-you-call-them. No matter how many bugs or misunderstandings there are about precedence. That habit may be a holdover from when macros ruled the C/C++ world. Given #define MULTIPLY(a, b) a \* b and k = MULTIPLY( 3 + 4, 5 + 6 ); you’d get k = 29 and scratch your head a lot. And then you’d start putting parentheses everywhere, just in case. [Previous page](https://boards.straightdope.com/t/if-the-partisans-of-lisp-loved-it-so-much-why-didnt-they-adapt-it-to-other-frameworks/578113.md?page=2)