Masp Brainstorming

Move the concepts of lisp to different atomic data-structures based on the belief or assumption that Lisp has the right ideas, but the wrong atomic structure.

This is a place to brain-storm a language/system that is based on maps (associative or hash arrays) instead of nested lists, as found in Lisp. (Thus, "masp" instead of "lisp".) It's my belief that being map-based would facilitate not only a powerful dynamic language, but also TableOrientedProgramming.

Further, maps are closer to the languages we actually end up using compared to nested lists. In other words, the languages that actually end up being chosen for production software are much closer to being map-based or map-like than nested lists. I believe this to be B-grade evidence supporting the conjecture that one of Lisp's biggest problems is its root structure. Maps may just better fit the WetWare of more people than nested lists. The concepts of Lisp are very intriguing, but it's just missing something syntactically.

Here are some features to consider:

--top

[anti-top rant removed]

If you [the ranter] have to actually have an implementation in hand to comment on it and make general suggestions or scenarios, then you lack imagination. LearningWithoutImplementation. More specifically, you lack mental emulation capabilities. I generally learn more about a language or tool from reading the manual and examples than from actually using it. Both are useful learning tools and ideally should work together, I will agree, but a lot can be understood just from documentation. Idle speculation is not evil. Many useful tools came from it. How does one measure "idle" anyhow?

And I'd like comments about features or abilities you'd like in such a language/tool. I wish other language designers kicked around their idea in public before actually making something. GoldenRule.

Think of it roughly comparable to taking 2D math and seeing if the concepts can be applied or adapted to 3D math. I'm simply trying to do the same by using reference-able maps instead of nested lists like Lisp uses.

Unless you want to argue that EssExpressions and the fundamental characteristics of Lisp are inseparable.

Sounds like you want LuaLanguage.

Perhaps, but I wonder about its nested table construct. I picture one big table ("God Table"). Any nesting should be reference-based nesting (such as a Parent_ID), and each table would be identified by something like "entity_ID" (table name), although special syntax may make it look like direct nesting or direct tables. Also unknown is how or if it supports table persistence, indexing, concurrent use, etc. If it didn't support these well, I'd be more inclined to use Perl due to its larger libraries and support base. And meta programming? More study needed.... -t

Lua handles persistence and concurrency for its tables just as ineffectively as Lisp handles persistence and concurrency for its lists. But it seems like you want something much further removed from Lisp and 'maps' than connotated by your opening comments and naming convention.

As stated above, it would be nice to based on something close to DynamicRelational. Perhaps I should call it Masp++ :-) But exploring the idea of the language and the idea of the underlying table engine could perhaps be separated. For example, in a mobile phone, we may not want the overhead of indexing and concurrency, and thus a RAM-only or RAM-centric engine may be sufficient.

A distinction needs to be made between a language that makes it easy to create, manage, and/or read/write to tables; and a language that is inherently built on tables. For example, a language that makes it easy to create, manage, and/or read/write nested lists is not necessarily "Lisp" just by having those properties. The distinction starts to become apparent, for example, when you want to put code inside the structure and start to do more complex things with that code, beyond mere "eval", including managing the scope of it and its variables.

I'd like to see a language which has even better atomic structures than Lisp. But one has to ask: Why didn't Lisp succeed?

"At least 3 "view types" supported."

At this point I definitely wouldn't 'support' anything but rather make views an essential feature of MASP. This is something done conceptually right by SQL (albeit much too seldom used; probably because of the overhead). -- GunnarZarncke

"Supported" is perhaps the wrong word. Lisp can be represented as a graphical tree diagram in an editor, for example. Maybe say that "X viewing tools/parsers are available as part of the release kit". The point is to have interchangeable representation choices without fiddly installations.

I didn't mean superficial (UI) views. Maybe I got the intent of top on this wrong. But I meant logical views. And even Lisp has no logical view concept (that I know of). Of course you can write methods which reinterpret your cons tree any way you want (and easily so), but then this is a new tree. The idea of a view (e.g. an SQL view) is than you can use it to not only read but also update the underlying, viewed structure. A language with a clean semantics for that is what I want.

Perhaps you meant something kind of like MicrosoftAccess's "queries" or RDBMS views, where the name of a query/view and "raw" table are treated equivalent in an SQL statement (at least for reading). I mistook "view" for the developer's code management view. I agree with such interchangabliligty, but that may be a library design issue rather than a base language issue. More brainstorming needed...

"But one has to ask: Why didn't Lisp succeed?"

Actually, one has to ask: Why is there a perception that LISP didn't "succeed"?

More importantly, how does one define "succeed"? To "succeed", does LISP have to beat JavaLanguage on the TiobeIndex? Or, does it only have to appear on the TiobeIndex? (Spoiler: as of May 2011, it's in the top 20 twice as "Lisp" and "Scheme".) Or, does it only need to have had a significant impact on Computing in general, which it undoubtably did?

Lisp didn't succeed in bringing homoiconicity to the masses.

Yes, it did. The fact that so many programmers know what homoiconicity is -- and the fact that we can have watercooler debates over its merits rather than scratch our heads when we run across it in obscure research papers -- is attributable to LISP alone.

Yeah, yeah, it did succeed in that. But not by being used for it.

Huh?

So Lisps place is in academics. But MASP could target a wider audience.

I don't know where you got the idea that "Lisps [sic] place is in academics." Neither AutoCad's AutoLisp nor Emacs's EmacsLisp are particularly academic. PaulGraham does have a doctorate degree, but he isn't an academic. ClojureLanguage is a general-purpose language built on the JVM -- hardly an "academic" language.

GreatLispWar has more on Lisp's market penetration.

With regard to AutoCad's dialect of Lisp as alleged evidence of Lisp's acceptance, keep in mind that many may use it simply because it's embedded with the CAD tool, not because it was their first choice of language. That's essentially a "coattails" benefit (borrowed from political idioms). EditHint: spin popularity issues off as PenetrationOfLisp?, or the like. Although, the semi-failure of Lisp's acceptance is a key part of what to add to Masp to try to remedy it. Further, even non-fans of Lisp often admire some of it's qualities without having to love the whole package. It's a language that makes one think. It's way up there as a MentalMasturbation language with hints of potentially grand power, similar to ProLog and the APL family. -t

I cited AutoLisp not as evidence of LISP's acceptance, but as evidence that LISP doesn't just have a "place ... in academics."

LISP has been in continuous use, in one form or another, since 1958. It's ranked 15th on the TiobeIndex. It's influenced and inspired legions and generations of programmers. Thousands of programming languages have been devised, used, and are now essentially forgotten (or were barely known), but LISP endures and every programmer at least recognises it. True, it's currently not as popular as C# and Java, but neither is Ruby, Python, Perl, or other languages that we easily deem to be "successful". How likely is it that C# and Java (or Ruby, Python and Perl) will inspire debate and development, like LISP does, for more than 50 years?

Why, then, is LISP considered a "semi-failure"? Instead, why is it not considered one of the most influential, enduring, and successful programming languages?

It should be, because it is.

It has some cool ideas behind it; few dispute that. But it's a Teaser. Many feel it's still missing something(s) to make it more practical and/or human-friendly. This topic explores fiddling with the root structure.

There's no evidence I've seen that putting lisp into a product significantly increases sales/use unless it's targeted at existing Lisp fans. -t

Ordering

I will agree that EssExpressions have better/easier support for ordering (sequencing) of items than maps. Ordering takes a bit more work with maps. However, I still feel that up-sides outweigh this weakness. It could perhaps be remedied by using an ordered map, but it may add unsatisfactory processing overhead. (One simply ignores ordering info if they don't need it.) If we want our syntax to be convertible to maps and back to syntax without loss of representation info, then tracking order may be necessary anyhow. OMasp? Something to ponder further. (PHP maps are allegedly ordered maps, but I never relied on that feature and thus cannot yet evaluate its utility and efficiency.) -t

Over time I'm warming up to the idea of ordered maps being the base structure. I keep encountering situations where ordering simplifies things, and ordering can be ignored if not wanted for a given situation. -t

"But one has to ask: Why didn't Lisp succeed?"

Sometimes it's visually easier to read and/or enter info as lists, and sometimes better as maps. Maps-only may make doing "listy" more cumbersome and list-only makes "mappy" things more cumbersome. Is there a way to cater to both without making a mess? I haven't found one yet.

For example, concatenating strings to build say HTML or SQL or URL expressions seems easier in a list kind of format: 

  result = s . "ttt" . u . vvv . "w" . x . "yyy" . z;
Lisp-style: 
  (concat s "ttt" u vvv "w" x "yyy" z)
This would probably be ugly in map-centric syntax. It's also ugly in "append operation" format: 
  result.appendString(s);
  result.appendString("ttt");
  result.appendString(u);
  result.appendString(vvv);
  etc...

See: CodeInaNewFormDiscussion MaspImplementationDiscussion

JuneEleven

CategoryCodingIssues, CategoryMetaprogramming, CategoryLisp, CategoryDataStructure, CategorySpeculative

EditText of this page (last edited May 27, 2014) or FindPage with title or text search