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.
Per Bothner:
> Why? And what does that mean? I guess it might be neat to have an
> alternate notation that maps bi-directionally to S-expressions, but
> that seems like a needless constraint if you're trying to design a
> more user-friendly language. I think the better goal is a language that
> is *compatible* with Scheme, in that you can seamlessly call between
> the languages, including compatible data types.
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.
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*.
> Well, if you want to support the infix expressions people are used to,
> need to at least support multiple operators:
> 3 + 4 + 5 + 6
That's already there. {3 + 4 + 5 + 6} works as-is.
> And of couple people are used to parenthesis as grouping.
Grouping yes, just use {...} instead of (...). E.G., {a + {b * c * d}} works as expected.
> If you're not going to support those, what is the point?
> Yes, curly-notation looks more readable than Lisp-notation to
> someone not familiar with the latter, but it's still going to be
> bit of a learning curve to write programs in that notation, and
> it's still going to require a learning hurdle.
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.
> Also, precedence is handy in some cases. For example assignment:
> x := x + 1
> I agree it's not essential, but I think allowing multiple operators is.
Multiple operators is absolutely essential, I agree, but that's already there.
Precedence *could* be supported. That is probably a separate thread, so let's talk about that on another thread.
> One rationale for "naming a zero-argument function applies it" is
> command-line/shells - REPLs and simple scripts. Considering typing
> a command to a Unix shell. People expect if you type a command with
> no arguments that it is applied with no arguments. That part at least
> seems natural and expected. Using () as a magical suffix to indicate
> application - but *only* for the zero-argument case - is IMO ugly.
> I'd rather come up with a semantics so I don't have to do that.
It's actually a general case. In sweet-expressions, functions can be called using f(...), and if there are no parameters, that's represented as f(). cos(0) does the obvious thing, too.
> 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!
...
> I think there are two primary uses of a REPL:
> (1) Running pre-existing commands with appropriate arguments.
> (Think: command shell.)
> (2) Trying out expression and commands to see how they work, to explore,
> and/or to learn a language or feature.
> 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.
--- David A. Wheeler