Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There is no need for "the system" to distinguish different uses of keywords. They are just used as names. For example, imagine two plists:</p> <pre><code>(defparameter *language-scores* '(:basic 0 :common-lisp 5 :python 3)) (defparameter *price* '(:basic 100 :fancy 500)) </code></pre> <p>A function yielding the score of a language:</p> <pre><code>(defun language-score (language &amp;optional (language-scores *language-scores*)) (getf language-scores language)) </code></pre> <p>The keywords, when used with <code>language-score</code>, designate different programming languages:</p> <pre><code>CL-USER&gt; (language-score :common-lisp) 5 </code></pre> <p>Now, what does the system do to distinguish the keywords in <code>*language-scores*</code> from those in <code>*price*</code>? Absolutely nothing. The keywords are just names, designating different things in different data structures. They are no more distinguished than homophones are in natural language – their use determines what they mean in a given context.</p> <p>In the above example, nothing prevents us from using the function with a wrong context:</p> <pre><code>(language-score :basic *prices*) 100 </code></pre> <p>The language did nothing to prevent us from doing this, and the keywords for the not-so-fancy programming language and the not-so-fancy product are just the same.</p> <p>There are many possibilities to prevent this: Not allowing the optional argument for <code>language-score</code> in the first place, putting <code>*prices*</code> in another package without externing it, closing over a lexical binding instead of using the globally special <code>*language-scores*</code> while only exposing means to add and retrieve entries. Maybe just our understanding of the code base or convention are enough to prevent us from doing that. The point is: The system's distinguishing the keywords themselves is not necessary to achieve what we want to implement.</p> <p>The specific keyword uses you ask about are not different: The implementation might store the bindings of keyword-arguments in an alist, a plist, a hash-table or whatever. In the case of package names, the keywords are just used as package designators and the package name as a string (in uppercase) might just be used instead. Whether the implementation converts strings to keywords, keywords to strings, or something entirely different internally doesn't really matter. What matters is just the name, and in which context it is used.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow do keywords work in Common Lisp?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdanlei
    1. USdanlei
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you! One more question, is it possible to check whether impleentation converts keywords to strings or not? Is is possible to reduce keywords to strings? I mean when Lisp reader finds a keyword it parses it just as a special kind of string.
      singulars
      1. PO
      1. USTheEnt
    2. COIn order to check how an implementation works internally, you'd have to take a look at the source code (or detailed implementation-specific documentation). In the case of package names, I'd assume implementations to compare the strings, because otherwise (with default reader settings) case-information would be lost. While two packages "foo" and "Foo" are different, two keywords `:foo` and `:Foo` are not. They are both interned with the same `symbol-name`, "FOO". (But then, there's also `:|Foo|` to prevent that.)
      singulars
      1. PO
      1. USdanlei
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload