Nested Lists As Dictionaries

Largely for top's benefit, a quick illustration of how nested lists can be used to express dictionaries and even (*gasp*) tables.

    ;; A key -> value mapping, called an alist (association list) in Lisp
    (setf an-alist '((employee-name   "George")
                     (hire-date        "10/10/1951")
                     (salary           1000.0)))

    ;; Fetch the 'employee-name' field
    (cadr (assoc 'employee-name an-alist))

    ;; Give him a raise
    (setf (cadr (assoc 'employee-name an-alist)) 1100.0)

    ;; Now, suppose we have a whole list of employee records like that one . . .
    ;; Find all of the employees with a salary greater than 1000.0
    (find-if (lambda (employee) (> (cadr (assoc 'salary employee)) 1000.0)) employees)

    ;; ...

Whether tables can be encoded as EssExpressions (or using any other reasonable data model) is not the issue. How prevalent is language or standard library support for using AssociationLists as RelationalTable?s -- for example, doing RelationalAlgebra on them? -- DavidSarahHopwood

It ain't exactly SQL, but I fail to see that there's anything tables can express better than sexps.

Sexps require one to align stuff up in columns to see 2D nature. Table browsers do this automatically. Something is either in a cell or not in. There is no visual ambiguity, and no alignment bumping issues such as TabMunging. Sexps and tables are TuringEquivalencyForDataStructures, so the issue is human convenience, not ability. -- top

Sexps require one to align stuff up in columns to see 2D nature. Table browsers do this automatically.

That's true when you print out the tabular data. But that is also true for Sexpr if I define a pretty printer for it, right? In case of typing in the 2D structure, I see no different between the Sexpr solution and The table solution (you will both need to indent it by hand, or use editor, in source code).

I don't dispute sexps TuringEquivalencyForDataStructures. It is not so much printing, but also editing, I would note.

But editing capability of Dictionary and Nested List are both as convenient in source code. How is the nested list version below harder to edit

 #list version
 (setf dict '(
     (employee-name "George")
     (hire-date        "10/10/1951")
     (salary           1000.0)))

than the dictionary version?

 #dictionary version
 dict = Hashtable new 
 dict[:employee-name] = "George"
 dict[:hire-date] = "10/10/1951"
 dict[:salary] = 1000.0

Some languages can use dot-notion if there are no special characters in key:

 #dictionary version
 dict = Hashtable new 
 dict.employee_name = "George"
 dict.hire_date = "10/10/1951"
 dict.salary = 1000.0
 dict['stuff#with#special#characters'] = "bar"

And, yes I do prefer that over sexp's because all sexp's look the same, but array assignments stand out as being visually different, as described in LispLacksVisualCues. Ideally, however, some kind of grid-based (tabular) entry is my preference. (Ideas for incorporating spreadsheet-like features into a language or IDE are described under TableOrientedProgramming.)

Okay, then what if it define := macro so that I can do

 (:= dict employee-name "George")
 (:= dict hire-date           "10/10/1951")
 (:= dict salary           1000.0)

what is the different? And you completely miss the topic. because what I was pointing to was that the code "dict[:employee-name] = "George"" or "dict.employee_name = "George"". Can not be browse by Attribute browser or Table browser, whatever you use.

That is a separate issue. I did not mean to apply they were related. As far as visual-ness, the ":=" in the middle helps visually separate the key from the value faster, at least for my eyes. One has to "read" the pre-fix version, whereas with the infix version, I immediately recognize the separator without going through the "read" step. I want to glance and have brain's pattern recognition identify patterns rather than wait for the word-at-a-time mental parser to do the work because it's slower. - top