Is a lisp with only functional parentheses possible?

Kazimir Majorinc · Post by **Kazimir Majorinc** » Tue Sep 08, 2009 9:46 pm

I don't get it.

Could you write short example of the code you'd like to write, it is possible with reader macro, but not with your own preprocess function?

TedWalther · Post by **TedWalther** » Wed Sep 09, 2009 3:26 am

Kazimir Majorinc wrote:I don't get it.

Could you write short example of the code you'd like to write, it is possible with reader macro, but not with your own preprocess function?

Let's be clear. I could do anything I want with my own preprocess function. But every time the newLISP syntax changes, I would have to update it. I would have to duplicate the code by re-implementing the newLISP syntax parser.

The purpose of read macros is to avoid that overhead; use the build in reader where you can. Also, as a standard part of the language, I wouldn't have to make my pre-process binary replace newlisp as the standard binary.

read macros should be fairly simple to implement (in the larger scheme of things). I'm not familiar enough with newLISP internals to bang this out quickly, but I"m guessing Lutz could have a rough cut working in 8 hours or so. (purely a guess from the poking around I did do)

It would work like the current macros do, but operate on the input character stream rather than on an already existing parse tree.

Elica · Post by **Elica** » Fri Sep 11, 2009 11:17 am

If the idea of reducing the number of (...)'s is to make the source code easier to read by not-lispers, then you must also consider solutions which affect the IDE (or the editor) without changing anything in the language.

For example, an editor that helps with the (..)'s might solve most of the problems. Here are few options:

- changing font size/color/background
- adding graphical elements (like the box in Boxer)
- collapsing/expanding nodes and subnodes
- etc. etc.

This would keep the language pure and will move all human-computer interfacing problems to be solved by the GUI or IDE.

So, a key question is whether you like an ASCII-only solution, or you would be happy with other solutions too. For ASCII solutions the most feasible might be using macros or preprocessing.

TedWalther · Post by **TedWalther** » Sat Sep 12, 2009 4:04 am

Elica wrote:If the idea of reducing the number of (...)'s is to make the source code easier to read by not-lispers, then you must also consider solutions which affect the IDE (or the editor) without changing anything in the language.

For example, an editor that helps with the (..)'s might solve most of the problems. Here are few options:

- changing font size/color/background
- adding graphical elements (like the box in Boxer)
- collapsing/expanding nodes and subnodes
- etc. etc.

This would keep the language pure and will move all human-computer interfacing problems to be solved by the GUI or IDE.

So, a key question is whether you like an ASCII-only solution, or you would be happy with other solutions too. For ASCII solutions the most feasible might be using macros or preprocessing.

That is an interesting concept. Someone could implement it as an emacs "mode"; the text view would be sweet expressions, but underneath emacs would be storing everything as proper newLISP.

This brings us around to the ColorFORTH concept that compilation happens in the editor, word by word. Full circle. I knew Chuck Moore was LISPy at heart (and he even admitted it in person)

newdep · Post by **newdep** » Sat Sep 12, 2009 3:54 pm

Im still thinking about simplify..
And indeed an overlay-editor or a color mix is a very nice way to do this...
(so are all programming languages overlaying Assembly anyway ;-)

Getting back to newLISP though... I think that newlisp can be simplified by starting to look at its functions..

I.e. the predicates...

Using predicates one must test those against xx by use of an extra function..It isnt smart by itself..

But what if they where able to include the test-case them selfs..?

Code: Select all

This is my preference:

(integer? (integer "1") (println "yes"))

or

(integer? (integer "1") (println "yes") (println "no"))


But instead we must now write ->

(when (integer? (integer "1")) (println "yes"))

The "when" is not needed here, integer? is already testing...
if the predicate was smart enought to deal with everything within its
test argument...Rewriting this saves parentheses and a 'test function..

...still thinking...

Elica · Post by **Elica** » Sat Sep 12, 2009 5:35 pm

Try to code this: "if a is integer and b is integer then print 'yes'."

cormullion · Post by **cormullion** » Sat Sep 12, 2009 7:53 pm

The problem with this suggestion is partly that if you make functions smarter, they become less general-purpose. There's the trade-off between having simple small tools that combine well, and complex tools with more intricate syntax.

Also, one of the ideas behind Lisp is that you develop your own language for solving your own problems. If you find yourself writing this sort of thing a lot, you extend the language to meet your needs, rather than burden the base language with every possible application.

Code: Select all

(define-macro (integer??)
   (if (integer? (eval (args 0)))
       (eval (args 1))
       (eval (args 2))))

(integer?? 3 (println "yes it is") (println "no it isn't"))
;-> yes it is

(set 'a 1.2)
(integer?? a (println "yes it is") (println "no it isn't"))
;-> no it isn't

more complicated to check for all integers:

Code: Select all

(define-macro (integers??)
   (if (for-all integer? (0 -2 (args)))
       (eval (args -2))
       (eval (args -1))))
       
(integers?? 3 4 5 6 (println "yes they are") (println "no they aren't "))
;-> yes they are

(set 'a 1.2)

(integers?? a 2 3 (println "yes they are") (println "no they aren't "))
;-> no they aren't

hilti · Post by **hilti** » Tue Sep 15, 2009 11:53 am

I just found this site via twitter. Have a look at it:

http://www.genyris.com/

Cheers
Hilti

Elica · Post by **Elica** » Tue Sep 15, 2009 12:13 pm

Six years ago I presented a paper about how Elica displays source code to help users find errors. The paper is available here. You may have a look at figures:

Fig.4 - a summary of supported representations of source code
Fig.5 - fully parenthesised original Logo source
Fig.6 - graphical non-ASCII brace notation
Fig.7 - graphical non-ASCII box notation
Fig.8 - prefix-only Lisp-like indented notation

Of course, the paper is about Logo, but all results are immediately applicable to Lisp.

PS. There are other representations, but they are not related to the discussion, like assembler representation or natural language representation.