About item 1:
The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of physical
memory (magnetic-core memory).
It had a structural editor. We would change nodes, add/remove child nodes, ...
Of course there were no WYSIWYG GUIs. The representation was all text
base showing a tree shape view of your code.
Navigation was a bit akward since it was 5 years before the mouse/windows
concept came to market.
I still wonder how it could fare compared to the text base approach we are used
to these days. Maybe this is worth an attempt with the current processing power
we have at hand and graphic aids that did not exists et the time.
Item 2:
>From what I recall, there were no such confusion in a structural editor. The
>confusion
could still be removed by using proper syntax highlights even in a text base
editor.
In any case, you would not want to change the underlying representation
otherwise code that processes code would not work anymore or would become
more complex to write.
Luc P.
> On 03/08/2012 02:39 AM, Leon Talbot wrote:
> > If so, how ?
>
> Syntax is a list of arbitrary rules made by a language designers. It's
> always possible to come up with a different (perhaps more compact,
> cleaner, more readable) syntax but:
> - that means creating a new incompatible language,
> - that would exactly zero new capabilities. Power of the language is
> defined by its semantics, not syntax.
>
> If I was going to design a new LISP language, I'd consider one of these
> two possibilities:
>
> 1. Getting rid of textual representation altogether and provide tools
> (editor, diff, patch etc) handling AST semi-graphically (think of the
> way spreadsheet editors handle 2D arrays). This breaks so many
> established conventions that it's unlikely at large scale. Yet, this is
> what LISP was originally supposed to be, and technical limitations that
> forced us to use textual representation are long gone.
>
> 2. Changing some of the arbitrary decisions LISP designers have made.
>
> Specifically, they have decided that a procedure application literal is
> simply a list: (proc arg1 arg2), which then forces us to use a
> constructor syntax for getting a list: (quote a b c) or '(a b c). This
> is a very clean and compact representation indeed but it makes it easy
> for the programmer to confuse a procedure application with a list.
>
> We could reverse this design decision and make the list literal denote a
> list: (a b c), and come up with an explicit literal form for an
> application. For example:
>
> .fun <nil> ; (apply fun)
> .fun (arg1 arg2 ...) ; (apply fun '(arg1 arg2 ...))
> .fun arg ; (apply fun arg) (any use for that?)
> .fun {arg1 val1} ; (apply fun {arg1 val1}) (ditto)
>
> So instead of writing:
>
> (map + '(1 2 3) '(4 5 6))
>
> we could have:
>
> .map (+ (1 2 3) (4 5 6))
>
> A bit more complex example:
>
> (def fib-seq
> ((fn rfib [a b]
> (lazy-seq (cons a (rfib b (+ a b)))))
> 0 1))
>
> could become:
>
> .def
> (fib-seq
> . .fn (rfib [a b]
> .lazy-seq (.cons (a .rfib (b .+ (a b)))))
> (0 1))
>
> If we added one more "apply" literal:
> .(arg1 fun arg2) ; (apply fun '(arg1 arg2))
> we could even write:
>
> .def
> (fib-seq
> . .fn (rfib [a b]
> .lazy-seq (.(a cons .rfib (b .(a + b)))))
> (0 1))
>
> IMHO the result is both more explicit and more readable than the
> conventional LISP syntax (and yes, I'm using LISP long enough to be
> comfortable with its syntax). Is it worth implementing in an *existing*
> language? Nah..., maybe in some DSLs.
>
> Andrzej
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
