[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Are we done? Are other changes needed to maximize adoption?

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/16/2012 06:32 PM, David A. Wheeler wrote:
Per Bothner:
You might find this interesting:

Thanks for the pointer!

This has somewhat similar goals to the "readable" project, though with a different approach.  The big difference is that I decided it was important to have a generic notation for *any* s-expression.

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.  E.g. in an R7RS world
you should be able to import an Infix-Scheme library into a Scheme
library and vice versa.

It's probably fairest to compare Q2 to the "sweet-expression" notation:
* Sweet-expressions have infix, though not precedence.  Actually, precedence *could* be added, as discussed in SRFI-105... I just don't think it's worth it.

Well, if you want to support the infix expressions people are used to,
need to at least support multiple operators:
  3 + 4 + 5 + 6
And of couple people are used to parenthesis as grouping.

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.

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.

* Both have "juxtaposition for function application"
* Q2 has "Naming a zero-argument function applies it" but this is awkward, indeed, "The exact rule for a distinguishing between a variable reference and a zero-argument function application isn't decided yet." In sweet-expressions, a zero-argument function name is called by adding () after it or around it, e.g., pi().

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.

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.

It is worth noting that pure functional languages (like Haskell) don't
have this problem, because a zero-argument function is the same as a
lazily-evaluated variable.  In an impure-functional language like
Scheme that if you seldom pass a zero-argument function as a value;
usually you apply it.  So that should happen you if mention it, without
requiring awkward syntax, at least if you have a language with
"juxtaposition for function application".  The rare case where you need
to pass a a zero-argument function un-applied is rare, and easily be
worked around, for example with a dummy argument.

* "Flexible token format" - both require operators to be delimited.
* "Use indentation for grouping" - both use indentation for grouping
* "Block expressions yield multiple values" - In sweet-expressions, you use usual Scheme procedures, including value, instead of having special syntax.

I'm not 100% sure the multiple-values semantics for blocks (along with
append-values semantics for statement separation) is a good thing,
but it does compose well and has some other nice properties.

* REPL: In sweet-expressions, you usually end a line with ENTER ENTER.  Q2 doesn't, but I worry that you have to be careful or it'll end where it syntactically might not need to.

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.
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.
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/