As a former Racket user but not a current member of the Racket community, I
thought I might toss in my 2c. My reasons for not using Racket are
essentially,
1. Parentheses make my head hurt.
2. DrRacket is slow, and VSCode integration is weak.
I've heard the "surface syntax doesn't matter"
On Mon, Jul 22, 2019 at 7:15 AM Alexis King wrote:
>
> On Jul 22, 2019, at 14:16, Dexter Lagan wrote:
> To say that Racket is so defined by its syntax that it will cease to be
> distinguishable from any other language if it is changed is absurd, and it’s
> frankly insulting to all the people
More specifically, I was referring to design goals for S-expressions:
-- generality: S-expressions should be good at representing arbitrary data.
-- readability: it should be easy for someone to examine and understand the
structure of an S-expression.
-- economy: S-expressions should
Like I said, my limited experience makes my opinion of limited interest. I’m
really only speaking from a practical standpoint, meaning, how a Python or Java
programmer would see Racket. For example, I have no experience with language
design, and I only used Racket and Scribble as-is. Most
> On Jul 22, 2019, at 14:16, Dexter Lagan wrote:
>
> A parens-less Racket2 would become Crystal.
No it won’t. I am quite confident that Racket with any syntax will not be like
any other language that currently exists. What other language has Racket’s
advanced, robust compile-time
On Sun, Jul 21, 2019 at 1:12 PM Alexis King wrote:
> It is easy to foresee a transition away from s-expressions as a restriction
> on what can be expressed via macros, mostly since non-s-expression languages
> with macro systems (such as Haskell and Elixir, to name just two) usually
> impose
> On Jul 21, 2019, at 00:19, Matthew Flatt wrote:
>
> I have in mind "Honu: Syntactic Extension for Algebraic Notation through
> Enforestation", GPCE 2012. It shows how we can bridge the relatively linear
> structure of non-() programs to the tree structure of S-expressions.
> Specifically,
On Sat, Jul 20, 2019 at 08:53:17PM -0700, Andrew Gwozdziewycz wrote:
>
> I'm in favor of a different syntax if it doesn't add new semantics
> along with it. I'm also in favor of an s-expression based syntax that
> uses less parens all together. In other words, I think a way to
> proceed might be
On Sat, Jul 20, 2019 at 06:07:40PM -0400, Christopher Lemmer Webber wrote:
> Hi Matthew,
>
> As someone who (unintentionally) caused maybe some of the debate to get
> out of hand (or did I?) I would like to open by saying that both your
> last email to the prior thread and also this email are
At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote:
> As you said, changing the surface syntax is high-risk, possibly
> high-reward. I agree with that, though I think Racket is uniquely
> positioned to lower the risk dramatically *because* of the #lang
> infrastructure. Is a
Thank you for writing this.
On Sat, Jul 20, 2019 at 11:49 AM Matthew Flatt wrote:
> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2. Here
> are a few potential changes from the wish list:
I like this list of changes.
As a procedural matter, I think that the Github repository is a great
way to communicate about specific ideas in way that ideas stay
connected and don't get forgotten.
https://github.com/racket/racket2-rfcs/
Right now, basically all of the discussion is in the issues, as people
work together to
Let's keep this light and fun, especially for the implementor, who
shouldn't be bogged down with parens-or-die commentry. How about treating
it as yet another #lang, albeit one of interest as core members have an
itch to scratch. Let's cross the bridge of moving docs/website/drastic
stuff when
Hi Matthew,
As someone who (unintentionally) caused maybe some of the debate to get
out of hand (or did I?) I would like to open by saying that both your
last email to the prior thread and also this email are both very
encouraging.
I'll skip everything else and jump straight to:
Matthew Flatt
Matthew Flatt wrote on 7/20/19 2:49 PM:
We need concrete examples to discuss the possibility of changing syntax,
potential roadmaps to see whether there's anywhere we want to go, and so on.
Procedural suggestions people might want to do:
* There's a lot of prior work, and it might really
15 matches
Mail list logo
