[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Little things that matter in language design

Little things that matter in language design

Posted Jun 20, 2013 6:12 UTC (Thu) by dakas (guest, #88146)
In reply to: Little things that matter in language design by erich
Parent article: Little things that matter in language design

And finding a misplaced ) in Lisp code is a masochists job.
It's rather an editor's job. Lisp does not have a program syntax, it has a read syntax: programs are just "evaluated" standard data structures (lists, usually).

The read syntax is simple enough to be amenable to a lot of automated processing. Emacs has something like M-x check-parens RET to find file-wide problems, but paren matching and indentation is also quite helpful. Even non-LISP aware editors like vi at least offer paren matching via %.

Now this is a language design choice: using macros is so much more dependable, powerful and coherent than with C/C++ that it is not funny.

Evaluating a macro call means taking the unevaluated arguments, calling the macro on it, and evaluating the result. Evaluating a function call means evaluating the arguments and calling the function on it.

Orthogonal, straightforward, powerful. There are is no technical "parser" barrier between input and code. Instead, there is a cultural barrier between code and programmer as humans are used to plenty of interpunction and semi-graphical representations (one of the reasons people prefer mathematical formulas in composed form rather than computer-language versions of them).

It is a tradeoff at a language conceptual level. It's not actually giving in to the machine (programming in assembly or machine language is that) but rather finding a common expressive ground easily manipulated by programs themselves.

Making it human-accessible involves optical patterning via programming styles and proper indentation. It's not the same as punctuation, but then punctuation without proper indentation does not really work all too well, either, and the worst case for programs generated by programs is meaning-carrying whitespace like in Python: you can't just write the program elements without knowing indentation context, running an indenter on the result if you need nice human readability.

LISP/Scheme is a superb environment for writing code that generates and/or analyzes code, because programs are not represented by a grammar but rather directly by their parse tree which has a computer- and tolerably human-readable and -writeable representation.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds