I thought I'd add my two cents here, as someone who's been using a mixed-syntax
Lisp[*] daily for 15 years now. I've been working with electrical engineers,
who aren't programmers, but obviously have a strong technical background.
Traditional algebraic notation for math (what Matthew noted as <expr> + <expr>)
is a huge help. +-*/ and < <= == != >= > are all widely used and appreciated. =
to mean set! was a bad idea. Programmers like it, but I've seen endless
mistakes where someone meant it as equal.
It's helpful to have the functional version of these operators, too. I've seen
people use especially add( expr expr expr ), where the sub-expressions were
complex enough that you'd run into confusion about precedence when trying to
add them together. add and times for + and * seem to be particularly helpful.
No one ever uses {} instead of begin. table[idx] is popular for numeric indexes
(both forms are evaluated). As is table->name for symbolic indexes (only table
is evaluated).
We have parentheses for disambiguation (ie, (a+b)*c vs a+(b*c)), but not
arbitrary amounts of them. So ((a+b)) is going to complain that some number is
not a function. I've almost never seen an over-parenthesized expression, and
when I did, the engineer immediately understood what had gone wrong.
There are a few ways functions can be called: fn(arg arg arg), fn(arg,arg,arg),
or (fn arg arg arg). People mostly use the first, and never or almost never use
the second. The classic Lisp syntax is mostly used for syntax forms, where the
puttuing the function name before the paren leads to a pileup of parens. Let is
a good example:
(let ((a 1) (b 2))
...)
Noone writes
let((((a 1) (b 2))
...)
Instead you'll see either the Lisp style, or
let( (a b)
a=1
b=2
...)
Another example is foreach, which is like a more limited version of Racket's
for:
foreach( elt lst
println(elt)
)
But with multiple lists, people will revert to the Lisp style:
(foreach (a b) lstA lstB
printf("a is %L, b is %L\n" a b)
)
This mixed-mode with some Lisp-style function calls, and some C-style ones
works out pretty well. Some of our syntax forms were adapted to work well with
C-style, but if you get too many close parens, you'll start to see horrors like
this:
) ; let
) ; if
) ; let
) ; define
Paren-matching in the editor doesn't seem to help dissuade them.
Those are the relevant bits of experience that I can think of. At a personal
level, you get used to the syntax pretty quickly, and it doesn't make it feel
less like a Lisp.
In the meantime, I no longer try to teach engineers classic text-based
programming, unless they're independantly motivated. Instead, we built a visual
programming system in which people who never would have touched a two-list
foreach are happily building very complex programs, and even use the each2
iterator. They happily write individual expressions textually (of the x+sin(y)
sort, or string formatting or similar). I don't have the impression that an
even better textual syntax would have made things much more accessible for
assembling larger programs. But this is only glancingly relevant to Racket.
Cheers,
Thomas
[*] SKILL, which is a proprietary Lisp used in microelectronic CAD in Cadence
Design Systems products. It has a weird history, with a Franz Lisp derived
dialect, and a Scheme derived dialect. They both coexist in the image, and both
use the same reader.
> Le 15 juillet 2019 à 04:29, Matthew Flatt <mfl...@cs.utah.edu> a écrit :
>
>
> tl;dr DON'T PANIC
>
> At RacketCon today, after summarizing the state of work on Racket CS, I
> recommended that we next explore the possibly of changing to an
> infix-oriented syntax in "Racket2".
>
> You can find the recording here:
>
> https://www.youtube.com/watch?v=dnz6y5U0tFs
>
> Start at 32:27 for the part about what Racket2 could be.
>
> I'll produce a text version of the rationale soon. For now, I'd like to
> offer a few clarifications:
>
> * There is no specific proposal for a new syntax, yet. Our next step
> will be creating a process to explore a possible new syntax.
>
> * The talk does include some initial constraints that might guide the
> choice of a syntax. Even that meta level (i.e., the set of
> constraints) remains subject to a community process.
>
> * `#lang racket` is not going away and will always have its current
> parenthesis-oriented syntax. In the same way that Racket still
> supports `#lang scheme` and `#lang mzscheme` and even `(module
> <name> mzscheme ....)` and even top-level programs, the Racket
> compiler and runtime system will always support `#lang racket`
> programs. We believe that Racket's `#lang`-based ecosystem makes it
> uniquely positioned for trying new language variants while
> preserving and building on our past investments.
>
> * Any new syntax must specifically preserve Racket-style
> language-oriented programming, which means everything from defining
> simple pattern-based macros to building whole new `#lang`s with a
> smooth path in between. Again, our current macro technology must be
> an enabler for a new surface syntax, not a casualty.
>
> As I hope comes across in the talk, I like the current Racket syntax
> --- and how could I not, after 24 years of helping to define it? ---
> and I am aware of many potential technical and social pitfalls that
> this kind of shift could create. Still, in addition to keeping the core
> Racket implementation running, I feel obliged to recommend changes that
> I think would be good for the Racket language and community. We've been
> lining up some technical solutions for a while. I don't know where the
> community discussion will lead, but I'm pretty sure it's time to start
> the conversation.
>
> Whether or not we eventually decide on a different syntax, the design
> of Racket2 will require community input and participation. If you want
> to know more about how we're thinking about that process, see the
> keynote by Aaron Turon:
>
> https://www.youtube.com/watch?v=xSjk2PdQm5k
>
> (We'll have professionally edited videos of all talks available soon.)
>
> Thanks,
> Matthew
>
> --
> 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/5d2be52a.1c69fb81.f77b6.e393SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
> For more options, visit https://groups.google.com/d/optout.
--
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/384650361.62834.1563265764863%40office.mailbox.org.
For more options, visit https://groups.google.com/d/optout.
