Is a lisp with only functional parentheses possible?

[newdep]

Im poisend at the moment by Functional programming and an overload on parentheses.

I urged myself to build a small parser that removes the very first parentheses

from newlisp in the hope to create/execute visability into the code.

That results indeed in clearer code and is executable but also a disabled language.



When long enough removing parentheses from lisp you will endup killing lisp.

...parenthese per parenthese...  



The question is -> "Is a lisp with only functional parentheses possible?"



- "What is a functional parenthese?"

- "Can a lisp exist with only functional parentheses?"

- "Will a lisp be more practical/attractive in use this way?"



Having less parentheses doesnt say you cant have another grouping mechanism.



And, having anonymous functions in the language doesnt make it a lisp!





PS: If i only could move these questions through a functional programming language and see the result..

[Ryon]

One of the beauties of Forth is its use of the data stack. Not only are parentheses unnecessary, but the operands are securely hidden as well. The listing is factored down to a short series of well-named actions.



I remember some experiments with a stack lisp, but don't recall where one would find them. Possibly in the journal Forth Dimensions.

[Elica]

When long enough removing parentheses from lisp you will endup killing lisp.

If you remove parentheses carefully you will not kill Lisp, but will end up with Logo.



A Lisp with reduced number of parentheses may appear simpler to novice users, but will definitely be harder to implement (from developer's point of view). For example, the last two Logo dialects which I implemented both had a hidden conversion from Logo to Lisp-like prefix-only full-paranthesised notation which is then used by the compiler/interpreter.

[cormullion]

I'm a big fan of parentheses, as you know...! They provide some major advantages:



- you can easily see the visual structure of your program, and the parentheses provide useful 'handles' for manipulating your source code. Assuming your editor is helping you, it must be easier to select, delete, move, copy, or otherwise manipulate significant portions of your code than it is with some other languages. Presumably you can easily step up and down through the program hierarchy, and easily manipulate the structure with your chosen editor? And also, you should be able to adjust the formatting and colouring so that the parentheses aren't too obtrusive.



- you can format your code the way you want to, since the interpreter cares only for the visible structure elements (parentheses and comments). This is great, because you, the coder, have the first choice about which white-space elements to use, and where; in many non-lisp languages, you usually have to allow the interpreter the first choice of white space, and fit in where you can.



- obviously, it's easier to manipulate the source code as data when it's so clearly delineated. (Although I still want Lutz to incorporate even better source code parsing, so I don't have to rely on  http://unbalanced-parentheses.nfshost.com/projectnestorpart1">my efforts.)



See also http://fare.livejournal.com/77842.html?thread=106770">//http://fare.livejournal.com/77842.html?thread=106770 for an interesting and forthrightly expressed viewpoint.

[newdep]

Ryon.. ;-) I do like FORTH indeed.. Have you ever tried Lutz' his

Forthscript ? http://www.newlisp.org/Projects/Gokumanual.html">//http://www.newlisp.org/Projects/Gokumanual.html



Elica..Yes true I did pass by Logo when tracking back lisp, actualky when

I look at the parentheses stripped code in newlisp it looks like Logo indeed..:)



Cormullion..I do need parentheses .I love them. Every language I hit while

programming I start with typing "(" ..even C goes in (void main()) format..

So im already poisend with parentheses too much to neglect them..





Perhpas its intresting to know how I came to the question, or not :). I checked on

some other languages I did not spent any time on latelty (last 10 years ;-)

Just to see what the advantages are compaired to newlisp. Well My conclusion

is that newlisp can do a lot. And I was wondering, why i.e. Python became so popular,

as its far from my ideal language or even Perl or Ruby. The answer is actualy

everywhere I read about 'none' mass languages and its simple,

the bulk goes where the bulk is. That doesnt say anything about the power of

the language at all. But because there is a Bulk of users they create bulks of code.

Nothing efficient nothing fancy just bulk. Which in return makes a language

intresting for....yes..the bulk.



Anyway..Personaly I need lamdba's thats something i know for sure. I    

also need nested functions, unlimited and type free & case-insensitive  

programming. But I also do want clear code. Actualy thats all inside    

Scheme Lisp and ofcourse newlisp. And it all depends on your programming

skills to make that visual attractive enough for the eye.





So Is it that Python and Ruby are so popular because, beside the bulk, have

a more 'Imperative' (uhum...) layout? Is this what catches the C programmer

or the masses? I cant emagine that Lisp or Haskell arnt attractive enough

for the bulk..just doesnt fit into my brain..



So I though..I newlisp would have less parentheses it would perhpas not

resemble Lisp too much and one could call it newScript or something to

get the Bulk into newLisp. Because why would you want Type settings

in the first place? I dont know. I can only emagin its because of the

split between scripter and compiler. People who want speed know where

to Find the C language. But if you want efficiency where do you look?

Yes..where the Mass is..the bulk user community.



So in the end I can only try and extent my newLispScript parser

and see what the result is when its done. A more attractive/effective

newLisp or a disabled Newlisp. I do question though if a disabled newlisp

is less attractive..(having less parenthesic effects thats is..)!



Its 34 Degress on the attic and time for a beer.. Actualy I dont even need

a beer ..it all did already hit my head without it...

[Cyril]

When long enough removing parentheses from lisp you will endup killing lisp.

...parenthese per parenthese...  

Hm... Then my favorite lisp-killing device is:

Code Select Expand

; This is in fact im my small library of handy tools

(define-macro (make-pass)
  (doargs (arg)
    (letex ((Old arg)
            (New (sym (append (string arg) "&"))))
      (define-macro (New)
        (Old (eval (args)))))))

; library function call

(make-pass catch not print)

; and usage

(catch& while (read-line)
  (setq line (current-line))
  (if (not& empty? line)
    (print& format "%sn" line)
    (throw 'empty)))



Maybe catch& while is not very good example (I've copied this from a very old code), but not& empty? and print& format are of everyday usage. I just consider them as names of compound concepts.

[TedWalther]

So when will get get reader-macros in newLISP?  I'm itching to embed a custom language within newlisp, and then embed newlisp within that, and then the new langauge within that, and then and then and then...



I'm thinking of a list of "hooks" you could push onto a list, and the reader would call those functions if a match is found.  Those functions of course would be able to "push back" onto the stream, and would either return a lisp object or would throw an exception saying "evaluate with the next reader on the list", with the default reader being the last one read, first reader matches.



Unlike common lisp, our reader macros could make use of (regex) for dispatching the custom reader on the source code stream.  In short, I think Lutz could quickly and simply beat the pants off common lisp reader macros, incorporating them with a very small performance hit.



Ted

[Jeremy Dunn]

Here are a couple of ideas you might try to reduce parentheses:



1. Give function names a special form such as all caps so that your translator can easily find them and have the function names double up as the left parenthesis.



2. Let the square brackets [ and ] act as a replacement for double parentheses. For instance, [ is the same as ((. This would enable clearing up long strings of parentheses. This is something that could be useful in any LISP.



Keep us informed of what you come up with!

[TedWalther]

With reader macros we could try all of these things.

[ale870]

Even if I don't like so many parenthsis, I must admit that, if you eliminate them, you can get some seriuos problems.

Rebol is a functional programming language, with several common points with newLisp. One of the biggesst problems of that language (my opinion) is there are no parenthesis, and it is very difficult to visually check/write code. In fact, without parenthesis, you cannot see where a function (or a block) terminates, and where another function (block) starts, unless you perfectly know the functions and its parameters.



See the following example:

Code Select Expand


view f: layout for n 0 19 1 [r: (random 19) + n // 20 append [across] load rejoin [ "a"n": check on [a"r"/data: a"r"/data xor on show f]" ]]


This is a small game in Rebol. As you can see, without a good Rebol programming knowledge, it is very difficult to visually understand the code.

[Ryon]

Itispos

sibletounreadablyformatjus

taboutanything.Sowhat?

[ale870]

:-)   You are right, in fact it is difficult to find the right point between usability, efficiency, performance, etc...

[Ryon]

I'm not sure the program's usability, efficiency, or performance would be affected by the formatting style, Alessandro, but my efficiency and performance sure would be!



I don't know a thing about Rebol, but I'll bet I could follow about 90% of that listing if it were formatted a bit more plainly. And I have to admit that this is something I cannot do with Lisp. It pretty much all looks the same to me.  :-(

[Elica]

There is one easy recursive solution, but I'm afraid you will not like it, although you may enjoy it. Here it goes:



To solve the problem with parentheses, we can replace them by square brackets. However, this will introduce a new problem - a problem with the square brackets. To solve it, we can replace brackets with parentheses, which will reraise the initial problem. Fortunately, we already know how to solve it.



So, everything is OK - the initial problem is reduced to a sequence of problems, each of which can be solved trivially.

[m35]

Elica, I would reward you with an Internet for your comment if I could.





I just did a bit of searching and ran across http://www.dwheeler.com/readable/sweet-expressions.html">Sweet-expressions. I would be fascinated to see the newLISP's API wieldable with syntax used in more imperative languages.