Re: [racket-users] Racket2 possibilities

[Andrew Gwozdziewycz]

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. I'd feel great about Racket 2 if it
doubled down on removing concrete types in favor of interfaces /
abstract types. I'd feel great about Racket 2 if pattern matching was
core, and I didn't have to think about `case-lambda` and friends. I'd
feel great about structures / records if I didn't have a million
different options when defining them. I'd feel great about Racket 2 if
we introduced "arc"-like accessors, and conveniences that removed the
need for nested function calls (e.g. `(foo-name afoo)` vs
`afoo.name`)...

I'd feel great about Racket 2 if it maintained the curation and
simplicity of R*RS Scheme, but with modern conveniences that reduced
keystrokes and line width without giving up expressivity.


> Surface Syntax
> --
>
> You won't find a wish for significant changes the Racket surface
> syntax anywhere on the Racket2 wish list. Nevertheless, I've suggested
> tacking it on.

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 to have syntax be actually surface, and completely
inter-changeable, such that if I prefer s-expressions, Dr Racket
allows me to edit that way. If I prefer an infix representation, Dr
Racket can read the s-expressions and convert it to infix, and convert
it back on save (Or the other way around depending on the code base
preferences).

As Lispers we've all argued that surface syntax doesn't matter for
years, trying to get people to not see our choices as "Lots of
Infuriating Stupid Parentheses." So, why not go all in on this and
show that we really believe it?

I realize I'm asking for a pony, _and_ a horse...

-- 
http://www.apgwoz.com

-- 
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/CADoGzscCM%3D53pBq5tVvxhVMiUc4A3bJocKo5RL3qtmpzNdJoAA%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Jay McCarthy]

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 gather ideas. I think eventually we need to try to
write longer-form proposals about the details.

I think Matthew's point about trying to write down some concrete
examples would be extremely valuable as issues to spur discussion.

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

On Sat, Jul 20, 2019 at 2:49 PM Matthew Flatt  wrote:
>
> This message is intended as a prose form of what I said at RacketCon,
> but it includes some extra explanation triggered by the discussion so
> far. Where that happens, I apologize that it isn't in the form of a
> more direct response in the original thread.
>
> The Racket2 Idea
> 
>
> Racket's design and implementation is on solid ground, and from this
> point, it can continue to evolve and improve in many ways. 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. At the same time, the current language design may be close to
> a local maximum, and it's not in the nature of the Racket community to
> be satisfied with a local maximum.
>
> By starting all programs with `#lang`, we have created a path to leap
> from one peak of design to a different, higher peak without sacrificing
> the old one and while staying Rackety. Roughly, that's what we mean by
> "Racket2". The name "Racket2" stands for some language that builds on
> the current Racket technology and implementation, but that may not
> directly accommodate the same bindings and expression forms that appear
> in the body of a `#lang racket` module.
>
> Although we could literally write `#lang racket2` for modules in the
> new language, "Racket2" is normally understood as a placeholder for a
> more distinct name. As a matter of branding, perhaps the language would
> be called "Racket X" for some good X --- shortened to "X" in some
> contexts --- and Racket X program would be written with `#lang X` line
> at the top. Maybe the name depends on how different Racket2 turns out
> to be from Racket, so it makes sense to pick a name later.
>
> Venturing out from Racket's current peak opens a large space of
> possibilities, so the first step is to agree on a set of goals to be
> met by the next peak. The goals can serve as a starting point for
> developing roadmap for deciding on technical details in a follow-up
> process.
>
> Possible Language Changes
> -
>
> The Racket community has long discussed possibilities for Racket2. Here
> are a few potential changes from the wish list:
>
> * Rename functions to make the conventions more uniform, and make
>   better use of keyword arguments to reduce names and increase
>   consistency.
>
> * Change structures types to have more or fewer features.
>
> * Use generic datatypes (such as streams) pervasively, instead of
>   writing code that expects a particular concrete representation (such
>   as lists).
>
> * Make strings immutable by default (e.g., result of `format` or
>   `string-append`).
>
> * Adjust the semantics of common syntax forms, such as raising an error
>   on fall-through for `cond` or `match`, and change the meaning of some
>   primitives, such as making `integer?` mean "exact integer".
>
> * Make pattern matching more pervasive and available by default.
>
> * Change module, evaluation, and loading callbacks (e.g., protocol for
>   `current-module-name-resolver`) to improve errors and extensibility.
>
> More changes have been suggested, and no doubt many other changes would
> make sense. As a first cut, to synthesize some principles from these
> ideas --- as a way of selecting which wishes should be tackled and how
> --- the current wish list might be organized and summarized by two
> overall goals:
>
> * Make the language more consistent
>
>   Consistency means making terminology and binding names more
>   consistent, and it means unifying related syntactic constructs. For
>   example, the `define` and `define-syntax` forms should perhaps be
>   less syntactically distinct. Similarly, pattern matching and syntax
>   matching seem closely related and could benefit from using the same
>   pattern language. Also, pattern matching should be pervasively
>   available among binding forms. Etc.
>
> * Make the language constructs more generic
>
>   In many ways, the current Racket language and libraries encourage
>   the use of concrete data structures instead of abstract datatypes.
>   The `map` function works on lists, for example, not arbitrary
>   streams, and even `for` demands concrete declarations like 

Re: [racket-users] Racket2 possibilities

[stewart mackenzie]

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 there's an implementation that passes muster. Choose a silly and
fun code name to start off with, a bit of self deprecation and irony goes
far. The new language needs to earn the title of racket2, a name with much
gravity.

I'm looking forward to #lang not(racket2) as, certainly, I'll learn new
things. A whole new world drawing from the best of research and Racket.

With that, bloody well have at this problem Matthew, more power to you.

-- 
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/CA%2BLh%3Dn2Oh_syWvM_dUGeahBHKX%3DpBJyrA1-3J1atBeeuYuGrHg%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Christopher Lemmer Webber]

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 writes:

> How to Proceed
> --
>
> Ideally, we would first decide on whether we want to try changing
> surface syntax ever. Then, only if we have enough consensus that it's
> worth a try, we could move on to setting overall goals and picking a
> roadmap. Finally, if the planing of the roadmap succeeds, we could
> follow it while getting into the details.
>
> Unfortunately, it doesn't work like that. 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. Some of the
> discussion will necessarily put a cart before a horse. Delving into
> some details may incorrectly give the impression that prerequisites
> are a foregone conclusion. We've seen all of that already, starting
> with my attempt to open up the discussion in the middle of RacketCon
> and probably continuing with this message. Perhaps we can just accept
> that this is all okay in the spirit of working together.
>
> I originally thought that we should have a more specific process in
> place for discussion at this point, but I think I've been proved
> wrong. Let's just discuss, for now. I'll be posting more myself.

For the sake of discussion, maybe it's easiest to just assume "Racket
attempts a move to a Honu derivative" as its surface syntax, which I'll
call ~Honu for now.  (I'm not saying that we know that will happen, I
just think it's a good place to start discussing.)  As you have already
said, this will not prevent the existance of "#lang racket" keeping the
syntax many in the community (including myself) already love.

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 "try it before we fully buy it" approach maybe
possible?  Maybe, for one thing, this could reduce community anxiety
and improve our chances to explore.

Here, maybe is a way it could be done:

 - First, port the teaching languages and etc over to Honu.  Try
   teaching some classes with just-Honu syntax.  This is *before*
   trying to switch the "internals" of Racket over.
 - Encourage a large portion of the community to try to write as many
   tools using ~Honu as possible.  How do people like it?  What can be
   improved?
 - Begin switching the core docs over, maybe even as a fork.  It might
   be a pain to maintain two doc forks, but maybe it is worth it.
   I suspect that Scribble might even make the task easier, since
   autogenerating two manuals from mostly the same source might not
   be too hard.
 - Switch all the default examples on racket-lang.org over to ~Honu.
 - Are people happy?  Is this meeting their needs?  Get community input.
   At this point, if the community is happy enough, and if it appears
   that *newcomers* (including in the educational space) are happy
   enough, now we can focus on switching the core Racket system over
   to ~Honu-as-the-basis.

What do you think?  This seems like a clean transition plan to me that
also allows for us to test, readjust, and even allows us to "stage
before we commit", which seems like a big win.

Thoughts?
 - Chris

-- 
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/87tvbgz7f7.fsf%40dustycloud.org.

Re: [racket-users] Racket2 possibilities

[Neil Van Dyke]

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 help discussion if we 
all have a shared baseline awareness of it.  Does someone have a 
comprehensive list of links (or want to assemble such a list) of the 
noteworthy attempts at non-paren syntax in Lisps?  (Offhand, but I know 
there's more: Honu, Shriram's work, the SRFI one, Python (which Norvig 
called a Lisp), Dylan's change, M-expressions, and some of the countless 
others, especially in CL.)  Also, maybe there's also some separate work 
in good syntax transformers for non-sexp that we should all know about 
at this point?


* With that shared baseline, would people like to highlight on 
"racket-users" promising ideas from that prior work, as well as post 
their own ideas (informed by prior work)?


* In group creative brainstorming, there's a procedural thing that's 
sometimes really helpful.  Basically, there's a phase/mode in which the 
top goal is to elicit ideas, and no critical commentary is permitted.  I 
don't presume to suggest any rules, and probably shouldn't be a hard 
rule in this case, but maybe many people will just tend to lean towards 
that, organically, initially.  Then, a little later, get more into 
critiquing, and see what new ideas/insights that then generates.  (Where 
this idea comes from, there's also a bunch of other modes and roles, and 
ways to be aware of and explicitly signal what kind of contribution 
you're making, but, to start with, I just wanted to toss out this one 
very simple idea.)


--
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/3dd5f0ea-5a65-5cd5-258d-f5c466bba2a7%40neilvandyke.org.

Re: Backing up [was: Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2]

[Matthew Flatt]

At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> [...]
> I think it would be a mistake to skip this discussion.

Agreed, so I'll offer my take on these specific questions, at least if
you'll humor my read of "more popular" as "lower barrier".

At Tue, 16 Jul 2019 21:55:03 -0400, Greg Hendershott wrote:
> 1. More popular, among who?

I think we should be aiming for programmers generally. Some of those
programmers will still be in school, but I haven't noticed a huge
difference in the way students approach things and the way practicing
programmers do.

> 2. How popular? Are we aiming for as popular as Clojure? Haskell?
>Python? Java? JavaScript?

I'll skip this one, because I don't see how to read it as "lower
barriers".

> 3. What are various possible ways to achieve this popularity, including
>-- but not limited to -- changing the surface syntax?

Other ways I see to lower barriers are more documentation, running on
more platforms/VMs (as also suggested in this thread), and improved
tools.

> 4. Which are most likely to succeed? Which are most likely to backfire?
> [...]
> 4. Do we have some sense of how to rank them on effort and risk?

Changing the surface syntax seems on the high-effort --- high-risk --
high-reward end of the scale.

Documentation is more on the medium-effort --- low-risk -- low-reward
end. We need more, but we (and you specifically) have put significant
effort here, and there's bound to be a diminishing reward to saying the
same thing a little better and in different ways unless we also somehow
find new voices.

Running on more VMs is high-effort -- medium-risk -- medium-reward. We
know how to do this, but it takes a long time. Building Racket on
Scheme, which should be about the easiest possible choice, took a
couple of years (and counting); then again, we were aiming for a very
high level of compatibility, which might not always be necessary. There
are ongoing projects here and they should certainly continue, because
they hit a good point in the risk--reward spectrum. Maybe I am
personally burnt out on this direction, so I am motivated to reason in
favor of a different problem.

Improved tooling also seems high-effort -- medium-risk --
medium-reward. I'll defer to those who concentrate more on tools,
including the author of Racket mode for Emacs, to suggest a priority
for this one.

> 5. Given all that, what should we do?

You have a more than my 2 cents already. :)

-- 
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/5d336cba.1c69fb81.f7666.34b8SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[racket-users] Racket2 possibilities

[Matthew Flatt]

This message is intended as a prose form of what I said at RacketCon,
but it includes some extra explanation triggered by the discussion so
far. Where that happens, I apologize that it isn't in the form of a
more direct response in the original thread.

The Racket2 Idea


Racket's design and implementation is on solid ground, and from this
point, it can continue to evolve and improve in many ways. 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. At the same time, the current language design may be close to
a local maximum, and it's not in the nature of the Racket community to
be satisfied with a local maximum.

By starting all programs with `#lang`, we have created a path to leap
from one peak of design to a different, higher peak without sacrificing
the old one and while staying Rackety. Roughly, that's what we mean by
"Racket2". The name "Racket2" stands for some language that builds on
the current Racket technology and implementation, but that may not
directly accommodate the same bindings and expression forms that appear
in the body of a `#lang racket` module.

Although we could literally write `#lang racket2` for modules in the
new language, "Racket2" is normally understood as a placeholder for a
more distinct name. As a matter of branding, perhaps the language would
be called "Racket X" for some good X --- shortened to "X" in some
contexts --- and Racket X program would be written with `#lang X` line
at the top. Maybe the name depends on how different Racket2 turns out
to be from Racket, so it makes sense to pick a name later.

Venturing out from Racket's current peak opens a large space of
possibilities, so the first step is to agree on a set of goals to be
met by the next peak. The goals can serve as a starting point for
developing roadmap for deciding on technical details in a follow-up
process.

Possible Language Changes
-

The Racket community has long discussed possibilities for Racket2. Here
are a few potential changes from the wish list:

* Rename functions to make the conventions more uniform, and make
  better use of keyword arguments to reduce names and increase
  consistency.

* Change structures types to have more or fewer features.

* Use generic datatypes (such as streams) pervasively, instead of
  writing code that expects a particular concrete representation (such
  as lists).

* Make strings immutable by default (e.g., result of `format` or
  `string-append`).

* Adjust the semantics of common syntax forms, such as raising an error
  on fall-through for `cond` or `match`, and change the meaning of some
  primitives, such as making `integer?` mean "exact integer".

* Make pattern matching more pervasive and available by default.

* Change module, evaluation, and loading callbacks (e.g., protocol for
  `current-module-name-resolver`) to improve errors and extensibility.

More changes have been suggested, and no doubt many other changes would
make sense. As a first cut, to synthesize some principles from these
ideas --- as a way of selecting which wishes should be tackled and how
--- the current wish list might be organized and summarized by two
overall goals:

* Make the language more consistent

  Consistency means making terminology and binding names more
  consistent, and it means unifying related syntactic constructs. For
  example, the `define` and `define-syntax` forms should perhaps be
  less syntactically distinct. Similarly, pattern matching and syntax
  matching seem closely related and could benefit from using the same
  pattern language. Also, pattern matching should be pervasively
  available among binding forms. Etc.

* Make the language constructs more generic

  In many ways, the current Racket language and libraries encourage
  the use of concrete data structures instead of abstract datatypes.
  The `map` function works on lists, for example, not arbitrary
  streams, and even `for` demands concrete declarations like `in-list`
  to provide the best performance. Refining the capabilities of
  structures and providing a smoother path among dictionaries,
  structures, and objects may also fit into this category.

There seems to be a widespread agreement/assumption among the community
that we could one day switch all the general documentation, such as the
Racket Guide, to use `#lang X`. That would preserve the ability to run
`#lang racket` modules and import them into `#lang X` modules, but it
would effectively relegate `#lang racket` to a kind of compatibility
mode. The Racket community has already done this a couple of times,
moving from `(module m mzscheme ...)` to `#lang scheme` to `#lang
racket`, and some of the Racket distribution is still implemented in
`#lang scheme`. After another switch, the constructs for `racket` would
remain documented and 

Re: [racket-users] Re: Gui editable grid/table

[Neil Van Dyke]

FWIW, I *might* very soon be making such an editable table/spreadsheet 
widget that scales to large data and supports various types, and in a 
cross-platform way.  (Without hitting various limits of some platform 
native widgets as used by Racket's GUI layer.  I recently looked at a 
few related packages for Racket, and some of the core glue code backing 
them, and unfortunately none could practically be modified to do what 
was needed in this case.) This work for large data might also turn out 
featureful for small data.  If this goes forward, I can at least post 
about what I learned, and perhaps those who'd be funding it will decide 
to open source it as a widget.


What I'm currently thinking builds on some earlier comments 
("https://lists.racket-lang.org/users/archive/2014-July/063303.html;), 
and I first have to feasibility check that some of the current GUI 
widgets behave like I suspect they do, on all current platforms. (If so, 
then we'll probably either also be good on hypothetical future 
iOS/Android/browser-based/etc. backends, and/or have the human resources 
at that time to make them work in core Racket.)


Of course, everyone should be encouraged to play with ideas like this on 
their own, for our own different 
requirements/priorities/curiosity/learning.  And always consider 
packaging up some of the artifacts of such work, as open source reusable 
components/libraries.

https://pkgs.racket-lang.org/
https://docs.racket-lang.org/pkg/index.html

--
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/415ab1b9-c915-7500-bbd4-34566edd530e%40neilvandyke.org.

Re: [racket-users] (ninth RacketCon) videos

[Neil Van Dyke]

Just to be clear, YouTube is clearly a very pragmatic way to make the 
RacketCon videos most accessible to people, and I'm very glad it's done.


Many people will stream the videos through YouTube, and (thanks to 
"youtube-dl.org") it's currently also an easy way to distribute the data 
to various offline copies people make.


Those offline copies might be for watching on trains and airplanes, for 
being accessible to people who don't normally have high-speed Internet 
access, for archiving in advance of the day that the dotcom alters the 
agreement, for finding on-principle ways to view without n different 
kinds of corporate spying and control and shoddiness going on[*], and... 
for indoctrinating captive houseguests in the teachings of Racketism, 
when they discover the TV can't screencast or play anything else 
(muahahaha).



[*] Seriously, CS people should learn about the current extent and 
impact of this (unless you are actively studying it, it's almost 
certainly much worse than you think), and take an on-principle stand 
against it, while we still can.  Understanding it should be part of 
basic education about technology, and there should be a more 
detailed technical treatment for preparing STEM students for industry.



wrote on 7/20/19 2:34 AM:

On Jul 20, 2019, at 01:37, Neil Van Dyke  wrote:

(My living room airgapped Blu-ray player delights houseguests, with a curated 
collection of fine videos on Racket and other CS topics.)

We get the message, Neil—we’ll steer clear of your lawn.



--
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/d54cb7da-2503-dd21-d32a-a1a1667ddba9%40neilvandyke.org.

Re: [racket-users] Re: Gui editable grid/table

[Stephen De Gabrielle]

There is also the spreadsheet-editor package, but I haven’t used it yet

https://pkgs.racket-lang.org/package/spreadsheet-editor

Let us know how you get on

Kind regards
Stephen


On Sat, 20 Jul 2019 at 05:13, Travis Hinkelman 
wrote:

> Hi Raoul,
>
> Matthias Felleisen is working on a Racket implementation of the 7GUIs
> project, which includes a simple spreadsheet as one of the tasks.
>
> https://github.com/mfelleisen/7GUI
>
> Perhaps that will suit your needs.
>
> Best,
>
> Travis
>
>
> On Friday, July 19, 2019 at 8:17:58 PM UTC-7, Raoul Schorer wrote:
>>
>> Hi,
>>
>> I am trying to make a gui editable table. Is that possible in racket/gui?
>>
>> It seems list-box% is not editable by default. Apparently, one can't
>> stick editors as list-box% choices either.
>>
>> Can you please help?
>>
>> Thanks!
>> Raoul
>>
>> --
> 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/0eff2c7c-e9c3-458a-a433-137656df7b6b%40googlegroups.com
> 
> .
>
-- 


-- 
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/CAGHj7-JzTmmayJbOXxUZqD3z4a1rD46FVCkOSC5OrjjzBbCtQQ%40mail.gmail.com.