Mainstream Lisp Alteration

I have been kicking around the idea of reworking Lisp or variations of it in order to make it more "palatable to the masses". The motivation is sort of the based on the way that SmallTalk concepts can be found in Python, but Python is more popular outside of diehard SmallTalk fan circles. Sure, Smalltalk fans would prefer SmallTalk, but if there is not a large enough user base, it will be hard to find companies that use it. Thus, a popular language like Python that has SmallTalk concepts in it may be better for even SmallTalk fans because it provides a large enough user-base to make finding projects that use a "close enough" language possible. In other words, it is better to be paid to use a language fairly close to SmallTalk than having to settle for Java and C++ because there are hardly any SmallTalk projects. One has to "sell-out" a bit to get concepts into the commercial world.

Thus, I propose a Lisp-like language with the following bastardizations of Lisp:

Command on the left of parenthesis 

  foo(a b c d)
instead of 

  (foo a b c d)
Yes, I know it may reduce some of the meta-power of Lisp. That is a cost of compromise. One may have to have things like 

   list(q r s t)
Instead of just 

  (q r s t)
Each list (and commands) essentially has one "tag name". If you don't need it, then simply ignore it. It might take up space, but its existence does not prevent anything significant that regular Lisp couldn't do.

The interaction style above has a history in the Lisp commnunity. Search for "Evalquote" or "eval quote" for descriptions of this Lisp top level. --

Have Algo-based control structures (if, while, case) in the standard library 

  while(condition statement1 statement2 statement3 .... )
Usually written as: 

  while (condition
    statement1
    statement2
    statement3
  )
If examples 

  if(condition dothis)


  if(condition 
    statement1
    statement2
  elseif condition
    statement3
  else
    statment4
  )
"else" and "elseif" are library-defined constants that the IF function/macro knows what to do with. (A macro will be defined simply as a function that has been designated to evaluates its own contents.)

Note that we are abandoning the right-side ending convention of parenthesis.

This is just wild MentalMasturbation as this point, so please go easy on the idea.

- top

It's not necessarily a bad idea, but you should be aware that it has been done by at least two (relatively) well-known languages: DylanLanguage at Apple and CgolLanguage? by Vaughn Pratt. And also that JohnMcCarthy himself originally assumed that eventually there would be a higher level syntax, called M-notation (which is well-defined enough, actually, to approximately implement as a language, except that it used font changes).

See also Draft SRFI 49 (Indentation-sensitive syntax) for a proposed Python-like alternative syntax for SchemeLanguage, called I-Expressions - http://srfi.schemers.org/srfi-49/ . Two interesting qualities of I-expressions are that they can be freely combined with traditional EssExpressions, and that they can be implemented for any R5RS-compliant Scheme interpreter in only about 50 lines of code.

The proposal allows mixing I and S-expressions producing a format that is both compact and noise free. Here are samples from the proposal ... 

 define (fac x)
   if (= x 0) 1
     * x
     fac (- x 1)


 let
   group
     foo (+ 1 2)
     bar (+ 3 4)
   + foo bar

Dylan looks a bit syntax-heavy. Not really a minimalist language.

Cgol at foldoc: http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=cgol

Cgol source archive: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/cgol/0.html

Cgol probably isn't well-known outside the Lisp community, actually.

There has been debate for decades, up to the current day (including on some pages here on wiki) about whether the failure of languages like that (Lisp semantics with roughly Algol-family syntax) to appeal to the masses is because this just isn't a good idea (that Lisp non-Algol-ish syntax isn't why the masses dislike it) -- or is it just that this idea has never been executed well enough?

Hard to say. Opinions vary.

Also, some people claim that certain modern languages, like Python or Ruby or Perl, have all of the power of Lisp and thus this has already been accomplished, but that is just factually incorrect. They mean that some of those languages now have some of the expressive power of Lisp. -- dm

Maybe just enough to avoid the SocialProblemsOfLisp? Too much power is sometimes a bad thing. Otherwise, every cop would carry an Uzi.

Yes, but that's a parallel that might or might not apply, since that's not, on the face of it, the same kind of power. (We could also digress about things like the military police on every street corner in Italy carrying machine guns, but let's not.)

The question of when it's useful to limit expressive power of languages has been partially addressed on PrincipleOfLeastPower and on notes I wrote near the top of IssuesForLanguageDesigners, among other places.

Bottom line is that I disagree in this context, though. The primary argument against expressive power in a general purpose programming language seems to be "the average programmer just can't handle the power of things like higher order functions, bless their pointy little heads, so we must save them from themselves, just as we'd take an Uzi away from a baby and then spank them."

Baloney. Anything along those lines is merely an argument that there are people who are called "programmers" who in fact are not "programmers", amounting to wishful thinking on the part of those who hope for cheap semi-skilled labor from an ArmyOfProgrammers to save them money on the expensive process of software development. This is a sneaky way of claiming that there is a SilverBullet: dumb down programming languages enough so that even idiots can program, and then software development will be cheap, too cheap to meter!

Unfortunately some supposedly-brilliant big names in the field actually believe this, but they're just kidding themselves. (An editorial rant by: -- DougMerritt)

The type of supply reflects the type of demand. But the idea of this topic is to deal with reality rather than overhaul it. In other words, sneak Lisp in by making it more resemble what is favored.

If you believe a few trivial syntactic changes will do that, then you must think C++ / Java programmers are all exceedingly stupid. Nevermind.

My first attempt at writing at this wiki, don't hit me hard: can anyone show a short program in Lisp, that would do something useful, and would be hard to write in any other language? There's no problem with throwaway programs in Perl or Ruby - which is why I love them. And my love affair with Java took off because it was easy to write small applets for the browser - a previously impossible task. Is there something equally convincing for Lisp?

Lisp doesn't really need to resemble other languages. But Lisp has to be really good at some simple task. For example, if Lisp has lambda and is great for writing callback-based GUI stuff, why can't one grab a free implementation somewhere that would make native Windows GUI programming (i.e. making .exe files that show windows) really easy? (Somehow, the ObjectiveCaml people managed this with LablGtk2.)

I'm not a Lisp fan, convince me. -- VladimirSlepnev? Perhaps this request should be moved to LispShowOffExamples.

Yeah, this link feels right here. And feel free to delete my request if it doesn't fit here. --Vladimir Slepnev

EditText of this page (last edited July 26, 2004) or FindPage with title or text search