This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
On 09/17/2012 07:45 PM, David A. Wheeler wrote:
Different goals, thus, different choices. I'm not trying to design a different, "more user-friendly language". I'm not saying that's a bad goal, it's just not *my* goal. Instead, I wish to use Lisp-based systems (especially Scheme) as they are, *retaining* their power. What I want instead is a nicer, more convenient, and mainly-backwards-compatible *notation* for their programs *and* data.
Fair enough.
Many people have created notations exclusively for programming Lisp systems (from M-expressions on down), but their approaches quickly lose the power of Lisp systems. For example, you should be able to use a macro (say, for a new control structure) the instant you define it, with 0 changes to the reader. Historical "friendly" notations generally couldn't, and thus, the "friendly" notations were either abandoned (M-expressions, IACL, etc.) or became a different language that was capable but not really useful for the same tasks (Logo, Dylan). For use *as a Lisp*, the notation needs to be *general*.
The Q2 parser generates S-expressions, which are then re-ordered (taking precedence into account) into more conventional prefix S-expressions. It's been a while since I've looked into it, but I'm hoping that it is compatible with Scheme-style macros, in the sense that you could define a macro using Q2-notation, and use it in a Q2 program. Admittedly, I haven't tried that yet. (Actually, I did but ran into a reader bug I need to fix first.)
All things have a learning curve. But:
{a + {b * c} + cos(x)}
should be easy-to-read by *everyone*, including both the unwashed through and the old hands.
My concern: It's not easy-to-write by the unwashed.
One idea I've considered is to distinguish commands from functions. A command is lexically bound, rather like a macro, but with normal evaluation. Commands (and macros and builtins) may have have variable arities, keyword arguments, and so on. They do not have run-time representation. In contrast, a function is a value. It is created with a lambda expression, and used with an explicit apply command. This of course takes us further from Scheme/Lisp, but may be worth considering.Interesting approach. Since I'm trying to *not* devise a different language, I don't think it'll work for my current goals, but that might produce a different language with a pleasant result. I'd be curious to see how it turns out!
In this model, one might have an operator that turns a command into a function, rather like Common Lisp's function operator. E.g. map (function sin) lst (This might be only allowed for commands with non-zero and fixed arity.)
In both cases, having to end each expression with ENTER ENTER seems unfriendly.I've been using it for a while, and it actually works well. Pressing a key twice is actually really easy to do, and is much simpler than many alternatives. From a usability point-of-view, pressing the same key twice is almost the same mental energy as pressing it once. I'd be open to other ideas, but the challenge is to make it work exactly the SAME way inside a REPL and in a file. Python doesn't try to do that, with the result that some cut-and-pastes fail nastily. Lisp REPL use tends to be even more exploratory, making such a difference even harder to justify. A special "I'm done now" marker could be used, but I don't think that's improvement. A "to be continued" marker could be used (like Python's ":"), but they have their own problems.The Q2 convention is simple and works pretty well. It's not going to always work correctly if you feed a "program" to the REPL line-by-line, but I don't see that is a priority.Again, different goals. I *do* expect to feed programs to the REPL, and put commands in a file, and be able to cut-and-paste between them.
Perhaps it might be useful to have two modes in a REPL: One where you have to delimit a command with enter-enter, and another mode where an input line is assumed to be complete if that makes sense. Switching between the modes can be done with a command-line flag or on-the-fly, without changing the language semantics - just the REPL UI would change. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/