21–30 of 46 posts
Earlier quoted context omitted.
if it's not quoted the list will be treated as an expression, and evaluate "Useless", which is probably not what you want.
Right so instead you'd write: keywords (list "a" "b") ? Which would let you also do complex things like (list (person "bob") ...)
Was the use of dict and list necessary? This is an actual question, not a rhetorical criticism. I have recently been trying to learn common lisp.
It is if you want to differentiate between a list of lists and a map. Maps are not natively supported in s-expressions. So there is a need to create a sub-language to handle special data structures. I have done this as well. But I use a special namespace '#dict' for example. So it would be (#dict (k1 v1) (k2 v2)) This way there is less of a chance of collision between data and this sub-language. It also allows for ex…
{:k1 v1, :k2 v2} ; curly braces for maps
[v1 v2 v3] ; square brackets for vectors
#{v1 v2 v3} ; pound-curly for sets
[add][item]1[/item][item]2[/item][/add]
Why are the keywords written with a quote? > (keywords '(useless microframework academic swag)) Shouldn't it be a list with strings or something? What if the keywords were complex structures not just strings?
The only Lisp I know is Racket (basically Scheme), so take the following with a grain of salt. '(foo bar baz) is almost the same thing as (list foo bar baz). However, ' also makes the contents of the list into symbols, not variable references. Basically, '(foo bar baz) returns (list 'foo 'bar 'baz), not a list containing the values of the variables foo, bar, and baz. Symbols aren't much like strings. They're immutabl…
'(foo bar baz)
(quote (foo bar baz))
user=> (quote (a b c))
(a b c)
user=> '(a b c)
(a b c)
user=> (list a b c)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: a in this context, compiling:(NO_SOURCE_PATH:1)
user=> (list 'a 'b 'c)
(a b c)If you love the expressiveness of S-expressions but hate the super noisy parenthesis, check the sugar version, called "sweet-expressions". http://readable.sourceforge.net/
Yet they quote pg as if he ever said that Lisp source code were ugly.
Regarding the "noisyness", I really think that the one and only place that you can really criticize is the closing of the outermost method.
And any text editor worth its grain of salt can be programmed to automagically collapse these closing parentheses. Hence preserving the eyes of non-lispers.
Also, when you're using something like paredit or subpar you hardly ever have any issue of non-matching parentheses.
I'm really surprised that people are still whining about that instead of trying to focus on the bigger picture: the benefits that homoiconicity brings to the table.
Was the use of dict and list necessary? This is an actual question, not a rhetorical criticism. I have recently been trying to learn common lisp.
It is if you want to differentiate between a list of lists and a map. Maps are not natively supported in s-expressions. So there is a need to create a sub-language to handle special data structures. I have done this as well. But I use a special namespace '#dict' for example. So it would be (#dict (k1 v1) (k2 v2)) This way there is less of a chance of collision between data and this sub-language. It also allows for ex…
> Side note: Wouldn't it be awesome if composer supported composer.sexpr files natively, so that we would no longer have to write JSON? No, not really. Why the quick dismissal? I find s-expressions much easier to work with than JSON.
Many people asked for yaml support in composer, and it was shot down. Here's why: Once you start supporting many formats you lose interoperability, as any tooling now needs to support all formats. That is the main reason why composer will not support sexpr.
Earlier quoted context omitted.
It is if you want to differentiate between a list of lists and a map. Maps are not natively supported in s-expressions. So there is a need to create a sub-language to handle special data structures. I have done this as well. But I use a special namespace '#dict' for example. So it would be (#dict (k1 v1) (k2 v2)) This way there is less of a chance of collision between data and this sub-language. It also allows for ex…
Clojure s-expressions actually have syntax for vectors, maps, and sets (in addition to the ones mentioned in TFA): {:k1 v1, :k2 v2} ; curly braces for maps [v1 v2 v3] ; square brackets for vectors #{v1 v2 v3} ; pound-curly for sets Clojure's reader also provides some mechanisms for adding readable values, which is awesome for serialization and interchange. There's more info here: http://clojure.org/reader