Relational Lisp Weenie

Combines the best aspects of the Relational Weenie and the Lisp Weenie! Annoying because she's usually right. -- AnonymousDonor

See http://www.ap5.com/ and http://www.common-lisp.net/project/sqlisp/ for examples of what I'm talking about. Like I said: "usually right".

I once called TableOrientedProgramming "relational meets Lisp", and it raised a few eyebrows. (Somebody deleted that exchange from this wiki.) However, I also suggested replacing (or enhancing) the concept of lists with tables, sort of like adding another dimension to S-expressions, which some Lisp fans objected to. Lisp tends to be hierarchical in nature (nested lists), which tends to cause indigestion in the relational perspective -- Trees and sets don't mix well. Some convenient way to marry them or make them interchangeable is still needed so that one can practice CodeAvoidance if they want, but still have the text option.

A Lisp program (or any program) is just a big data structure in the end. How that structure is represented as text is a presentation detail. DataAndCodeAreTheSameThing. Somewhere there is a Grand Unifying Concept waiting to be discovered, but nobody has been able to pull the sword out of the rock yet. Topics like EvalVsPolymorphism suggest that the blurring of behavior into data in a Lispish way is useful and natural. We keep smelling something in the merging of the two, but just can't quite find it. The beauty of Lisp is that the text is very close to the actual structure. You don't have funny syntax that translates into something that does not resemble the original text representation. It is one of the most WYSIWYG languages. Interesting to ponder and ponder.....

--top

Table-like structures are easily enough represented using s-exprs, or by other data structures available natively in Common Lisp. No need to enhance s-exprs. BTW, table representations are also hierarchical, but with a limited depth of hierarchy, depending on how you look at them. -- DanMuller

I did not question the ability of Lisp to represent tables, just it's "flavor". It is sort of a TuringEquivalency of data structures. Similarly, tables can represent anything S-expressions can. I wonder if there is not a "dictionary Lisp" such that the primitives to the language are dictionaries (associative arrays) instead of lists? I generally view general-purpose data structures in sort of a ranking:

lists
dictionaries (maps)
tables

It would be interesting to see a language built around the last two as the only primitive. Sort of a experimental journey to EverythingIsa Land. Or at least #2 as a stepping stone. "misp"? - "Map Interface & Structure Programming"? Uh, needs work. Related: UniversalStatement.

Strange here, from other pages, I have never seen TopMind appreciate anything about Lisp; It lacks visual clues; It's higher order function is better replaced by Eval. And the CLOS/Predicate-Dispatch is never needed in TableOrientedProgramming. Now he is saying TableOrientedProgramming, which he is trying to promote, is half Lisp. Is it actually Lisp? Or is it Pascal with parentheses around?

But what do I know. From the view of top, all Lisp has is only Cons and List anyway.

I am intrigued by some of the concepts of Lisp, not its practicality as a language that I would want to use (at least not in a team environment where readers and writers may change). I enjoy pondering how to transfer these concepts to TableOrientedProgramming. For example, code and attributes in tables could be represented as linguistical code or as tables. One's viewpoint would be a presentation choice (SeparateMeaningFromPresentation). Think of it like being able to have EssExpressions be representable as clickable graphical trees or as a textual language. One could add the visual cues that the text versions lack (see LispLacksVisualCues) by tweaking the tree browser. EssExpressions, or something like it can pull this off because it is based on simple building blocks. You generally need simple building blocks to build "meta" tools that let one customize their view of stuff. But the problem is that EssExpressions are navigational in structure and are thus hard to grok and manage on a non-trivial scale. I am seeking some kind of relational analog to EssEspressions?. Does this make sense, or do I need to rework the wording? Related: YinYangVersusSinglism -- top

Similarities between TableOrientedProgramming and Lisp:

DataAndCodeAreTheSameThing
Everything should be meta-enabled, including code
Based on a single "general-purpose" data-structure - AreTablesGeneralPurposeStructures shares a lot with EssExpressions. Tables and Essex. are roughly "equal" competitors.

Differences:

EssExpressions is the primary/key data structure instead of tables.

I think some of the ideas in SubtextLanguage connect with top's notions here.

If you want the goodness of declarative / relation-oriented programming, with something lisp-like, why not go the whole hog and try PrologLanguage? -- PhilJones

It's generally difficult to "escape" into procedural when one wants. Declarative can be nice, but there's times when procedural diddling is easier to formulate for a part of a problem, at least for most people. Good declarative techniques allow easy mixing into non-declarative when needed. To facilitate this, I gravitate toward the attribute-based aspects side of "declarative" over the logic side. Attribute-centric declarativeness "mixes better" with other paradigms and techniques than logic. Behavior is more difficult to share than attributes. -t