tag:blogger.com,1999:blog-6454006.post8746330703343948912..comments2024-01-16T14:32:49.175+00:00Comments on Arcane Sentiment: Why use keywords as symbols?Arcane Sentimenthttp://www.blogger.com/profile/04144052171693893368noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6454006.post-70893977165510215902016-07-25T17:38:58.395+00:002016-07-25T17:38:58.395+00:00This is an old post I know, but I have was just bl...This is an old post I know, but I have was just blogging about self-evaluating symbolic data here: http://jonathanwarden.com/2016/03/31/self-evaluating-symbolic-data-literals/Jonathan Wardenhttp://jonathanwarden.comnoreply@blogger.comtag:blogger.com,1999:blog-6454006.post-37377685938459736852012-04-29T02:22:39.161+00:002012-04-29T02:22:39.161+00:00In Scheme, of course, symbols don't have packa...In Scheme, of course, symbols don't have package baggage, but most Schemes don't have keyword arguments either. What is nice is that they are easy to get with R5RS plus records (= CL structs): a keyword is an identifier bound to an object containing its name, and keyword objects are equal iff their names are equal. See <a href="http://trac.sacrideo.us/wg/wiki/KeywordArgumentsArcfide" rel="nofollow">KeywordArgumentsArcfide</a>.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-42468451580827946532011-08-13T12:33:36.637+00:002011-08-13T12:33:36.637+00:00The (momentary) confusion I'm thinking of is f...The (momentary) confusion I'm thinking of is for humans reading code, not programs operating on it, so the issue isn't whether forms are really lists of symbols, but whether their textual representation <i>looks</i> the same. In Racket, for instance, forms aren't lists of symbols, but they look exactly alike.Arcane Sentimenthttps://www.blogger.com/profile/04144052171693893368noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-80217011456508217322011-08-12T21:15:39.473+00:002011-08-12T21:15:39.473+00:00Well, yes, code is data, but is an application a l...Well, yes, code is data, but is an application a list? I suppose what I mean is that code is a <i>separate</i> set of types, so this error is actually simply down to the popularity of representing data in a relatively untyped form with lists and symbols in Lisp-alikes.ehirdhttps://www.blogger.com/profile/01274306998660980484noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-31731442897406813202011-08-12T02:32:26.625+00:002011-08-12T02:32:26.625+00:00ehird: Of course programs are (a subset of) data! ...ehird: Of course programs are (a subset of) data! But my thinking was sloppy; what I should have said is that keywords help distinguish data that is Lisp code from other sorts of symbolic data. The issue is not confusion over whether code is data, but confusion between different types of data which require different cognitive approaches — in particular, when one looks at code, one thinks about its evaluation semantics and the resulting values, but for most other symbolic data, one thinks more directly about its structure.<br /><br />Uroš: Yes, it's to prevent them being interned, since when defpackage and in-package are read, the current package might be anything, and we don't want to pollute arbitrary packages with new symbols. Things like (cl:in-package #:foo) are a workaround for the reader's unwanted dependence on the value of *package*. (The problem isn't that symbols have packages per se, but that the package depends on the read-time environment. Clojure avoids this by resolving namespaces at compile time, not read time.)Arcane Sentimenthttps://www.blogger.com/profile/04144052171693893368noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-42406728393198195852011-08-11T16:54:52.459+00:002011-08-11T16:54:52.459+00:00I notice a third variety of symbol in Common Lisp ...I notice a third variety of symbol in Common Lisp code... #:new-uninterned-symbols<br /><br />As a relatively new initiate to CL, I find the use of this syntax instead of unquoted symbols/keywords, e.g. in defpackage, to be slightly baffling. Is it simply to prevent the symbol from being interned? However, the syntax appears to be necessary for other reasons... namely that there must be a way to textually distinguish a given package's interned symbols from other symbols with the same name.Nora Dimitrijevićhttps://www.blogger.com/profile/06778909411727988215noreply@blogger.comtag:blogger.com,1999:blog-6454006.post-14813060020813857022011-08-11T06:29:08.287+00:002011-08-11T06:29:08.287+00:00"For one thing, they help distinguish program..."For one thing, they help distinguish programs from data. Humans, even Lispers who know better, tend to see these as two different things, and get confused when they mistake one for the other."<br /><br />I keep getting the feeling that code isn't data; there's just a bijection between the two. Perhaps a Lisp with a strong type system should enforce this separation.<br /><br />(Well, not a bijection; not every piece of data is a valid AST. And I'm definitely talking in terms of inspecting ASTs, rather than the fact that evaluating a piece of code results in a piece of data.)ehirdhttps://www.blogger.com/profile/01274306998660980484noreply@blogger.com