On 8/21/2019 11:01 AM, Hendrik Boom wrote:
On Wed, Aug 21, 2019 at 10:52:57AM -0400, George Neuner wrote:
>
> I don't like the idea of compulsory 'else' - for 'cond' or 'case' or
> 'match' or ...
>
> 'Else' isn't needed if all input cases are covered, but in almost all
> real world uses, the compiler is not able to prove the 'else' is
> unneeded so as to prevent emitting code for it. And depending on how
> the compiler structures the tests (cond is simple, case less so),
> adding 'else' into the mix may increase execution time as well.
What about treating a missing 'else' as a run-time error if and only
if control gets that far.
That would require code that intends nothing to be done to have an
explicit 'else' saying so.
Except for notation, this would seem to meet your demands for semantic
expressibility.
Not at all. Obviously, I'm not a beginner: when I choose to leave out
'else', it is not a mistake - I intend that nothing should happen if no
explicit case was matched. An implicit runtime error would represent
completely different semantics ... well defined maybe, but completely
different nonetheless.
More importantly, the code generation consequences exist regardless of
whether the 'else' is explicit or implicit: it requires extra tests
which may affect the overall structuring and performance of the [set of]
tests. As I alluded to above, 'cond' wouldn't be affected very much
because it compiles quite straightforwardly into a series of 'if's' that
correspond directly to the source. However 'case' is a different matter.
I admit that I haven't looked to see how Racket compiles 'case' ... and
there are many possible variations due to the flexibility of the
construct. However, I have some non-Scheme-related experience with
compiler implementation, and in general, 'case' presents many more
opportunities wrt 'cond' to generate better optimized, out-of-order (wrt
the source) testing. Requiring an implicit 'else' introduces
considerable extra complexity, and may (not necessarily will, but may)
hamper generating an optimal test sequence for the explicit cases.
This is something that may become more apparent with the switch to
RacketCS because the Chez compiler does much more optimization and
produces native code. From a compiler implementor's view, the surface
syntax of the language largely is irrelevant - it impacts introspection
and metaprogramming, but quite a lot of syntax related stuff has little
or no effect on generated code. However, some of the things that have
been mentioned (at various times) have very real consequences for
generated code: things like automatic currying, 'statement' vs
'expression', arbitrary numbers of return values, implicit 'else',
generic stream access to (raw) collections, generic port access to
strings, N-dimension arrays vs vectors of vectors, incremental typing,
etc. It's the features themselves which affect the generated code that
I worry about much more than what syntax is used.
That said, I *like* the Lispy syntax. I do think there are some
opportunities to reduce the number of parentheses needed, but the
consistent prefix nature of S-exprs is - I think - what makes Racket
(and Scheme and Lisp) *easier* to learn than many other languages.
Remembering all the operator precedences in infix languages is a PITA.
I dislike in some FPLs remembering that I *must* use parentheses in
certain cases, while in other cases they are optional (or even
disallowed). I loathe significant whitespace (indentation) as in Python
- counting spaces is just as stupid as counting parentheses [and yes, a
decent editor can address either problem, but jeez ... even Fortran
dropped its indentation requirements decades ago].
I don't think "popularity" is a very good reason to change language
syntax - but as long as S-expr Racket remains a viable, completely
*supported*, language, then I don't have a problem with development of a
parallel infix version.
YMMV,
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/1ebfcd3b-80da-1abf-9dff-e2a3dec62f20%40comcast.net.
