
Racket2 Possibilities - mpweiher
https://groups.google.com/forum/#!msg/racket-users/HiC7z3A5O-k/XPR2wbSJCQAJ
======
dreamcompiler
The best way to kill a good Lisp is to remove the parentheses.

The people who complain about parens are still going to ignore your language
even after you remove the parens, and then the Lispers will ignore you too.
See Dylan.

This debate is exasperating. It's like hearing people say "I'm not interested
in that Ferrari because it has a manual transmission." The only response to
which is a silent, cold stare.

~~~
mark_l_watson
It is a great shame that I can only give you one upvote, you have it exactly
correct. Removing parents ruins Lisp languages.

That said, I consider Haskell to be a Lisp language. But, Haskell was designed
from the ground up, from ML, to be as it is.

~~~
nudpiedo
Why is Haskell a lisp? It is the first time I hear someone classifying Haskell
in the “List Processing” family of languages, and although it does process
lists I thought its main paradigma symbol and code representation goes in a
complete different direction, more into pure function oriented programming.

~~~
dreamcompiler
When people say something "is a Lisp" that usually has little to do with list
processing. It's about whether it inherits more from lambda calculus than from
Turing machines.

~~~
lispm
Lisp literally stands for 'List Processor'. To claim that it has little to do
with it, is really really strange. One of the main reasons to create Lisp was
being able to compute with 'symbolic expressions', represented as linked cons
cells in the form of lists...

McCarthy about Lisp:

===

As a programming language, LISP is characterized by the following ideas:

computing with symbolic expressions rather than numbers, representation of
symbolic expressions and other information by list structure in the memory of
a computer, representation of information in external media mostly by multi-
level lists and sometimes by S-expressions, a small set of selector and
constructor operations expressed as functions, composition of functions as a
tool for forming more complex functions, the use of conditional expressions
for getting branching into function definitions, the recursive use of
conditional expressions as a sufficient tool for building computable
functions, the use of lambda-expressions for naming functions, the
representation of LISP programs as LISP data, the conditional expression
interpretation of Boolean connectives, the LISP function eval that serves both
as a formal definition of the language and as an interpreter, and garbage
collection as a means of handling the erasure problem. LISP statements are
also used as a command language when LISP is used in a time-sharing
environment.

===

[http://jmc.stanford.edu/articles/lisp/lisp.pdf](http://jmc.stanford.edu/articles/lisp/lisp.pdf)

'lambda calculus' wasn't even explicitly mentioned. But he mentions
s-expressions, list structure, multi-level lists, ...

~~~
dreamcompiler
The Lisp community has moved on from McCarthy's taxonomy. In McCarthy's day,
there were two high-level computer languages (Lisp and Fortran) and now there
are thousands. Today we have different notions of what constitutes a "Lisp-
like" language and what doesn't. By McCarthy's strict definition, Clojure is
not a Lisp because it doesn't use real cons cells. But I think most people
nowadays would agree that Clojure belongs in the Lisp family more than in the
Algol family.

Haskell has (very!) first-class functions and is even more naturally
compositional than most "classical" Lisps. It feels to me like a Lisp with
static typing, laziness, and automatic currying cleverly incorporated.

Likewise Javascript. Javascript feels like a Lisp to me because it has lexical
closures. It gets in my way because its syntax and many other design choices
are terrible, but it still feels like it descends from lambda calculus.

I guess my point is that whether a language is a Lisp or not can't be reduced
to a simple list of bullet points.

~~~
lispm
Neither Clojure, Haskell nor Javascript are Lisp. Haskell and JavaScript are
not even directly derived from Lisp.

Your idea of Lisp lacks any concrete features and suddenly all languages would
be Lisp: Prolog, Haskell, ML, SML, Javascript, Java, ... all of them have sone
form of functions.

This then is arbitrary. Lisp is a family of languages which share concepts and
code. There are a number of concepts (you call it bullet points) which make a
language a member of the Lisp family in a wider sense and it may not be that
all members share all concepts, but MOST and the important ones,

Haskell for example is very very different from Lisp: syntax, semantics and
pragmatics. There is no way one would consider Haskell a member of Lisp
languages. Lisps are not statically typed, they are not lazy, they don't use
currying, they are not side effect free, etc. If a languages has all these
features at its core, it's not Lisp. Claiming that it is Lisp is just creating
confusion. Give a student a Lisp book (say Peter Norvig's PAIP) and a Haskell
compiler: nothing runs, the concepts and architectures are different, the
development style, basically everything.

Pure Functional Programming has been split from Lisp decades ago in the 70s
and 80s and we have now thousands of language camps (not just two: Fortran and
Lisp). The core of Lisp is still the same:

List processing, dynamically typed, a specific form of evaluation, garbage
collection, s-expressions with symbols, code represented as s-expressions,
built-in code transformations over s-expressions, procedures are called
functions, higher-order functions, eager evaluation, optional interpretation
of code in the form of s-expressions, interactive development with read-eval-
print-loops, etc etc.

From there new languages families have been forked or maybe only influenced:
purely functional PLs (Haskell), logic languages (Prolog), object-oriented
languages (Smalltalk, Self) and many others.

Smalltalk is also not Lisp, even though it got stuff like images, GC, blocks,
interactive interface, and others via Lisp influence...

------
skybrian
Rather than discussing "not lisp syntax" I suggest reading the Honu paper,
which is pretty neat:

[https://pdfs.semanticscholar.org/812b/92f2fa587ff78d727c7495...](https://pdfs.semanticscholar.org/812b/92f2fa587ff78d727c749528f5a6411ac0e2.pdf)

~~~
satya71
Cadence had a Lisp/Scheme with infix operators a long time ago. See
[https://community.cadence.com/cadence_blogs_8/b/cic/posts/sk...](https://community.cadence.com/cadence_blogs_8/b/cic/posts/skill-
for-the-skilled-what-is-skill)

~~~
skybrian
Did you mean to link to another page? I don't see anything about infix
operators on that one.

------
eggy
I am not a fervent Lisper, but dropping the parentheses will take me away from
the times I do go to Racket, and just go back to SBCL or Gambit or Chicken
Scheme. The article admits it is to try and win more share of users, but that
is not a good reason for a predominantly academic language. I would even go to
Haskell, which avoids success at all costs ;)

~~~
seisvelas
Ironically, I think most of Racket's popularity is _driven_ by its Lispiness.
People want to get into this 'Lisp' stuff and everyone recommends Racket. I
personally learned Racket because as a dumb teen Googled "how to become a
hacker".

The first result was Eric Raymond's article How To Become A Hacker, which
recommended learning Lisp. I looked into Lisps and ran into the book How to
Design Programs which recommended the IDE DrRacket.

------
anaphor
I quite liked this proposal from a while ago:
[http://shriram.github.io/p4p/](http://shriram.github.io/p4p/)

The idea is basically to remove implicit `(begin ...)` and then remove the
trailing parentheses from many things.

For example:

```

(define (f x y) (* x y))

```

vs.

```

define (f x y) (* x y)

```

It works because now you can only have a single expression as the body.

Similarly you get the same kind of thing with many other forms that have
`begin`.

It also proposes adding some new syntax for various things, replacing `begin`
with `do` and a bunch of other stuff related to indentation. You can easily
pick and choose which parts you like though and still get some benefit, which
is what I like. And it is still homoiconic.

If I wanted a quick and dirty way of making lisp "more readable", then this is
what I'd do.

I even created my own half-assed implementation[1] of this idea years ago (In
JavaScript). Disclaimer, it's really messy and incomplete code from when I was
just learning how to write parsers/lexers/etc. One other idea I implemented
was the ability to mix infix and prefix expressions. I'm not sure if I still
think it's a good idea, but it worked (it had to know whether a token could be
interpreted as a binary operator ahead of time and it was a bit janky, but you
could even add your own custom operators)

[1]
[https://github.com/weskerfoot/JLambda/blob/7508af2c9dcc4db02...](https://github.com/weskerfoot/JLambda/blob/7508af2c9dcc4db0214853036201211d8fbd09cb/server/fib.jl#L1-L8)

------
agumonkey
I trust M. Flatt to know what he's talking about but really the 'potential
users 'argument has always been weak to my eyes (both in breadth and depth).

prefix nested parens are ultra generic, I bet those who don't like that won't
like the genericity of the paradigm and idioms either, no matter how
mainstream the syntax

------
User23
Dijkstra's last published thoughts on the merits of infix notation for
associative operators come to mind[1]: "It made me realize why I like it so
much for associative operators: it allows us to write p+q+r without being
forced to choose between (p+q)+r and p+(q+r); in prefix notation, the choice
between ++pqr and +p+qr would have been unavoidable."

This show the obvious merit of parenthesis for prefix notation, since then one
can write (+ p q r). In essence, the + operator distributes over the operands.

[1]
[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html)

------
namelosw
I'm not totally against Racket without parens, but to gain popularity this
seems not to be the first action should be taken. Like IDE, tooling,
libraries/ecosystem improvements.

For example, the documentation is really great, but Drracket is only good, not
great. Probably good VSCode integration would help a lot, since not everyone
is using Emacs for serious work.

~~~
galfarragem
Instead of moving to a new market, with more _potential_ users - but also with
fierce competition - it makes more sense to stay where they are and invest in
"being so good that they can't ignore you" by investing in quality, and that
means outstanding tooling and ecosystem.

Recently somebody in HN also noticed the need for a "browser scheme" to take
advantage of code and data being the same. That might be also an interesting
path.

------
tosh
RacketCon 2019 talk "State of Racket" by Matthew Flatt

[https://www.youtube.com/watch?v=dnz6y5U0tFs&t=390](https://www.youtube.com/watch?v=dnz6y5U0tFs&t=390)

------
breck
Disclaimer: I work on Tree Notation
([http://treenotation.org/](http://treenotation.org/)),
([https://twitter.com/breckyunits/status/1153016840769007616](https://twitter.com/breckyunits/status/1153016840769007616)).

Prediction: In 10 years the most popular programming languages in the world
will not use the current BNF or () style syntaxes but instead will use Tree
Notation (with Racket like "Language Oriented Programming" on top), OR will
use some other "black swan" syntax that I haven't seen, that is even better
than Tree Notation...

I think we're all going to learn that syntax does indeed matter, once machines
are writing most of the code.

I'm willing to give even odds for that bet, if there is some type of charity
betting site that supports that sort of thing, if anyone disagrees. (Even if
you don't disagree, it would be silly to not take that bet for even odds,
given fewer than 500 people are actively using Tree Notation today).

~~~
jcelerier
> Prediction: In 10 years the most popular programming languages in the world
> will not use the current BNF or () style syntaxes but instead will use Tree
> Notation

Prediction: in 10 years the most popular programming languages will still be
C, Java, Python, Javscript, C++ and C#

~~~
juskrey
Correct!
[https://en.wikipedia.org/wiki/Lindy_effect](https://en.wikipedia.org/wiki/Lindy_effect)

------
badtuple
Serious question: Why do parens matter so much?

I read the post and all the comments here, where people are very adamant about
their opinions on parens. It seems to me that while syntax is important,
parens in this context is about as close to "just syntax" as we can get.
Racket-sans-parens would still be Racket.

Am I missing something fundamental?

~~~
gus_massa
IMHO the main problem are macros. Macros in racket/scheme/lisp/clojure are
very powerful. You have the complete language available to make any
transformation you want.

The idea is that the language look like an AST written as a list of list, and
the tools to write macros look like some pattern matching to transform lists
of list into lists of list. (In spite they are not lists of list but syntax
objects that have much more information.) (And you are not forced to use some
subset of tools, you can write arbitrary code in the macros, but some tools
make the common tasks easier.)

For example, to create a new macro that run some block of code n times, you
can write

    
    
      (define-syntax-rule (repeat n boby ...)
        (for ([i n])
          body ...))
    

and now you can use that as if it is part of the language:

    
    
      (repeat 5
        (displayln "Hello, Word!")
        (displayln "------------"))
    

(Note that, you don't have to worry that the counter i in the macro will
overwrite a variable i in the main part of the code.)

Nobody is sure where is the magic, but writing macros is easies because the
code in the main program and the patterns in the macro look very similar.

It's more difficult to work with a language with more syntax. Is the code
desugared before going to the macro? Can you use some sugared version inside
the macros? Does the user have to learn the main sugared version of the
language and then learn the desugared forms?

What if one of the "arguments" of the macro is an infix operator? How does it
interact with the other operators?

What if you have two interoperable languages running side by side? Racket
ships with something like 10 or 20 internal languages, and you can download 5
or 10 or 20 or 1000 more. And all of them are (somewhat) interoperable. So you
can most of the time use the libraries written in one of them in the other.
You can even share macros between languages.

What if you have two interoperable languages running side by side? What if you
write a macro in the sugared language and try to use in the other, or vice
versa? Does they work? How?

Nobody is sure about the details, but Matthew is optimistic that this is
possible, and he is usually right.

~~~
ddragon
At least in Julia, which is a Lisp-inspired language without s-expressions,
what you have is a dual representation for all code [1] in which you can
manipulate either directly on the normal infix notation with quote and
unquote, which is good for code injection [2], or in the s-expression-like
representation (Surface syntax AST) [3] in which you have the full control
over the structure but you have to deal with a different syntax. Using the
s-expression-like is more powerful, but for the function user it doesn't
really matter which you use.

[1]
[https://docs.julialang.org/en/v1/manual/metaprogramming/inde...](https://docs.julialang.org/en/v1/manual/metaprogramming/index.html#Expressions-
and-evaluation-1)

[2]
[https://docs.julialang.org/en/v1/manual/metaprogramming/inde...](https://docs.julialang.org/en/v1/manual/metaprogramming/index.html#Code-
Generation-1)

[3] [https://docs.julialang.org/en/v1/devdocs/ast/#Surface-
syntax...](https://docs.julialang.org/en/v1/devdocs/ast/#Surface-syntax-AST-1)

------
kamaal
This just now settles that anyone wanting to use Lisp to do anything practical
has only one option: Clojure.

It's a shame, because Racket had the promise to be something really useful.
Also throwing your dedicated 1% users under the bus, to attract 99% users who
won't use your tool no matter what, is bad idea from a product management
perspective.

I honestly feel f# has won the ML family language wars, and you won't be able
to do much there. Even if you have decent ideas, you still have to solve the
library problem. And yeah, given how scanty your user base is going to be, not
many are going to write books either.

The fact that they even consider this idea seems shocking to me, let alone
announce such a thing on a mailing list.

~~~
dTal
Calm down. They're not throwing anyone under the bus. The post starts with "No
matter how Racket evolves, the community is committed to preserving what we
have achieved: today's `#lang racket` programs will run in the future, and
today's `#lang racket` modules can be used in future Racket programs".

Also, basically the point of Racket is solving "the library problem". Every
fancy new language you make _in Racket_ has access to every library ever made
with Racket.

~~~
kamaal
>>"No matter how Racket evolves, the community is committed to preserving what
we have achieved: today's `#lang racket` programs will run in the future

So to put it clearly, the current programs would run, but no new features,
fixes and enhancements.

Basically you can't use it for anything production.

>>Every fancy new language you make in Racket has access to every library ever
made with Racket.

Libraries, means more number of libraries for the same language. Not same
number of libraries for more languages.

~~~
dTal
In Racket, it's the same thing. Racket #langs are interoperable. Which is why
it's untrue to say "no new features, fixes and enhancements". Any improvements
to the semantics of the language will be usable from both #lang racket and
#lang racket2; any libraries written in #lang racket2 will be usable in #lang
racket. This is merely a proposal for an official alternate _syntax_ , which
you are entirely free to ignore. It doesn't take anything away from Racket to
have this.

Bear in mind that Racket already comes with a plethora of officially supported
#langs, many of them with highly non-lispy syntax. The ability to do this is a
major part of Racket's unique value proposition in the first place.

~~~
neilv
At this point, it's not necessarily just an alternate syntax.

Given that, #langs _can_ be interoperable, and are encouraged to be, but not
necessarily.

For a simple real-world example of interoperability problems, of the kind we
could plausibly encounter between two very similar #langs... Consider that
RnRS Scheme wants to use mutable lists, but modern Racket wants to use
immutable lists. Code in the two #langs might even look almost identical, and
even use the same names and calling conventions, but in practice you have
trouble interoperating.

There's also factors like: what syntax is in the documentation everyone reads.
If all the manuals people see are in a new syntax, the old syntax effectively
becomes a dying language, whether or not it's still implemented.

With priorities and/or work, we can support a high degree of interoperability,
as well as keeping the current syntax genuinely supported, but we shouldn't
assume we get that for free. Nor should we assume it will happen, unless we
make it a top requirement that's tracked and remains a consideration in every
change.

------
darkpuma
> _" From a community perspective, the rub is that the "many people" for
> Racket syntax is a barrier are mostly people outside the community. It's
> fair to ask who would benefit. It's difficult to ask a community to tackle a
> problem whose solution targets a different community."_

Yeah no shit, alienating the 1% of the general population who uses your tool
to appease to the 99% who don't currently use it might work sometimes, but you
could just as easily lose that 1% and pick up jack shit, because the
grassroots advocates for your language just evaporated. Dropping s-expressions
from the primary lang would likely prove to be the kick in the ass I need to
switch to CL.

(Other proposals listed sound a lot better. This syntax matter is my one
serious grievance here.)

Edit:

> _" From what I've seen there is no advantage that editors can give you with
> parens, that they can't do better without parens, given that you've written
> loads of tests and done the grunt work to make that happen."_

This seems like one of those cases where lack of editor diversity among a lisp
community once again threatens to cause trouble for anybody who doesn't use
emacs (see also: terrible default REPL experiences because the devs all use
racket-mode or geiser-mode.) What am I meant to replace the % command with
when using vim or evil-mode? I don't want to do _" loads of gruntwork"_, nor
do I wish to rely on editor extensions for a matter that should be so straight
forward. I want to press % and jump to the matching paren.

------
tosh
I think there are lessons to be learned from Python, Perl and Osborne [0].

New and arguably better things aren't created in a vacuum. They are perceived
and judged in their context. Irritating users of A with A' can handicap the
env of A as well as the env of A'.

I think this is often not thought about well enough.

[0]
[https://en.wikipedia.org/wiki/Osborne_effect](https://en.wikipedia.org/wiki/Osborne_effect)

~~~
tosh
related:
[https://en.wikipedia.org/wiki/Path_dependence](https://en.wikipedia.org/wiki/Path_dependence)

The evolution of projects and their environments is a difficult endeavor.

------
a_lieb
Forgive me if the answer to this is already widely-known, but at this point is
Racket making a play to be a general-purpose, "batteries included" Lisp,
rather than a stripped down tool for PLT stuff and making languages? It seems
like there's room in the market for something like that. A _bit_ like Clojure,
but without all of the big design commitments that Clojure makes, like the
deep integration with Java and focus on immutability.

~~~
59nadir
It's already been positioned as a batteries included lisp and arguably has had
the best standard library offering + documentation for it of any lisp out
there. This move has nothing to do with that, but rather the possibility of
having less (to some) off-putting syntax.

------
laughinghan
Other comments make it sound like dropping parentheses is just a craven
attempt to make Racket more popular. To me, this epitomizes the distinction
that the maintainer drew between trying to get more popular, and lowering
barriers of entry. If Racket 2 is no more popular (it loses as many community
members as it gains), but the new community members had an easier time joining
the community yet still love Racket 2 just as much as the old community loved
Racket 1, isn't that still a win?

Conversely, if it turns out that everyone loved Racket 1 not because of the
design elements that the maintainer put so much blood, sweat, and tears into,
but because of the high barrier of entry due to the parentheses (the one thing
that the maintainer _didn 't_ put effort into), how is that at all motivating
to the maintainer?

I'm less of a community member and more of an admirer of Racket from a
distance (and I don't mind parentheses, really, I've used Clojure
professionally and it was great), but I look forward to seeing how this
initiative turns out.

~~~
anaphor
From some of the comments it feels like this is also intended as a way to
research different ways of doing Lisp surface syntax without sacrificing the
features of the macro system. I'm not sure if it's possible to do both at the
same time.

~~~
laughinghan
Did you miss the "How?" section of the post? He wrote a research paper showing
it was possible in 2012, "Honu: Syntactic Extension for Algebraic Notation
through Enforestation".

~~~
anaphor
Yes I read the paper, but he also makes it clear that there's still lots of
work to do (e.g. how to make it work better with macros)

------
didibus
Ignorant question: What's Racket's value proposition beyond being a well
maintained Lisp?

What's this Language of Language thing, and is it so awesome that I'd be
tempted to learn Racket only for it? Since otherwise its syntax and semantics
might be too similar to say Python? (Assuming it drops all the Lispy stuff)

~~~
nudpiedo
I look a few times to racket in the past. It's distinctive features are:

\- Pedagogy first: easy to learn, cute visual tutorial with support for
desktop UIs, nice tutorials on the language itself and how to learn several
aspects of programming such as sockets etc.

\- Very Easy to write a programming language on top of it by creating a new
lisp reader (#lang) which transforms the given code and makes the access to
the rest of racket's ecosystem very easy.

It is not industry-focused, therefore you might end up frustrated if your
main/only goal is to write single web applications or you need good support
for commercial libraries, databases etc. On the other hand in software
everything is possible so you could always find your way to access those
libraries and leverage the existing ecosyste,

------
tgbugs
Having followed this fairly closely, I will drop a though here while it is in
my head. Surely there would be no obstacle to supporting s-expression syntax
and allowing additional syntax around it. Everyone seems to see this as
either-or, but is it really truly impossible to have a set of rules that say
"you can't start a valid sexp with `(4` so this must be the start of an infix
expression" and "you can start an sexp with `(add1` so I'll keep going"? Yes
there will be a cost in the reader, but moving away from sexps is already
going to be costly in that sense. Further, if we are going to incur the cost
of a major complication of the parsing implementation, then why not go all out
and allow interleaved expressions? What are the ambiguous cases that make this
impossible?

~~~
a_lieb
I've always wondered if a good way to do infix would be to simply have the
ability to mark an item with a character that means "move this to the front of
the expression." Let's say the char is ":". Then this:

    
    
      (1 :+ 2)
    

Would be converted to this:

    
    
      (+ 1 2)
    

It would also allow for arbitrary placement, so you can do goofy stuff like
pretend to be Forth without writing custom macros for the situation:

    
    
      (1 2 3 4 5 :+)
    

Whether or not that part is an advantage is another story ;)

This doesn't solve the "too many parens" problem, because you still have
parens, but it does solve the "prefix math looks weird" problem. It's quite a
bit simpler than what Dylan does, in that there's no special concept of
"binary operators" and it's obvious at a glance how everything converts to
sexps.

~~~
hyperion2010
Racket currently has something like this for certain operators. `. -> . ` will
allow the arrow to sit in between inputs and outputs in contracts.

~~~
darkpuma
> _for certain operators_

AFAIK it works for any operator that takes two operands (or more, but it makes
less sense to be using it with three or more operands.)

e.g:

    
    
        > '(arg0 . operator . arg1 arg2)
        '(operator arg0 arg1 arg2)

------
brisance
Surprised that he proposed infix operators since that is kind of contradictory
to his stated goal of improving consistency within the language.

------
jchw
FWIW, the angry negative responses to removing parenthesis from the community
would be a much bigger obstacle to adoption than the parenthesis. Nothing is
going to turn me away from a technology faster than a hostile community,
especially for a programming language, where the ecosystem is both an
important asset and an investment you make when you choose a language to write
in.

And I’m serious: I adopted Go early on for it’s ecosystem and community. Rust
was harder _in part_ due to its early negative reputation for overzealous
fanatics, which thankfully no longer feels like an issue (and the ecosystem is
getting there, too.)

~~~
darkpuma
I'm not angry yet, I'm just concerned. If it actually happens, _then_ I'll be
angry.

