Re: [racket-users] Location grabbing in typed/rackunit

[Ben Greenman]

On 4/28/20, shane c  wrote:
> I think require/typed/provide in typed/rackunit is affecting the location
> grabbing feature. Hoping someone can provide a suggested path forward. When
>
> I run this program,
>
> #lang typed/racket/base
>
> (require typed/rackunit)
> (check-true (string (check-true (string (check-true (string
> The last expression turns out to be (check-true #f) so an error is printed.
>
> However the error location points to rackunit source.
>
> 
> string FAILURE
> name:   check-true
> location:
>   /Applications/Racket
> v7.6/share/pkgs/rackunit-typed/rackunit/main.rkt:33:2
> params: '(#f)
> 
>
> I can switch to (require rackunit) in #lang racket/base and the location
> points to the source file as expected.
>
> P.S. thanks for all your hard work. -shane

Right, require/typed/provide is turning off the location tracking.

Possible fix: add a `check-true` macro to typed/rackunit that calls
the require/typed `check-true` inside of a `(with-check-info )`
The macro should also set the check expression.

Can you open an issue for this in the rackunit repo?

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

[racket-users] Location grabbing in typed/rackunit

[shane c]

I think require/typed/provide in typed/rackunit is affecting the location 
grabbing feature. Hoping someone can provide a suggested path forward. When 
I run this program,

#lang typed/racket/base

(require typed/rackunit)
(check-true (stringhttps://groups.google.com/d/msgid/racket-users/f3300e51-5629-45f4-9bb0-86fb0e6fa0c7%40googlegroups.com.

Re: [racket-users] FrTime magic updating seconds

['John Clements' via Racket Users]

Wait! I got it! I forgot. It’s not hash-lang. I have to choose the language via 
the “choose language…” menu.

Sorry for the noise, folks.

John

> On Apr 28, 2020, at 3:28 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> Okay, I have several things to say about Father Time.
> 
> Thing one: running through these demos (frtime/demos) is kind of astonishing. 
> There just doesn’t seem to be enough code for it to do what it’s doing. The 
> father time programs are *incredibly* concise distillations of behavior. The 
> ball-pushing demo is almost magical.
> 
> Thing two: I have a very very clear memory of being able to run a program like
> 
> #lang frtime
> 
> (current-seconds)
> 
> and seeing a changing number in the interactions window. I can’t make that 
> work now, and I’ve tried versions back to 7.3, which is the oldest one I have 
> handy that still runs on my mac. I’ve tried various combinations of (seconds) 
> and (current-seconds), running in the definitions and interactions window, 
> and none seem to work “correctly” (that is, with a changing number in the 
> interactions window). Is this something that went away a long time ago? Did I 
> ask this question already? Sigh.
> 
> John
> 
> 
> 
> -- 
> 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/f8b9118d-66c7-4735-89a0-9976a307ac56%40mtasv.net.



-- 
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/438b5489-9e00-4f9d-8977-5172bed853f4%40mtasv.net.

[racket-users] FrTime magic updating seconds

['John Clements' via Racket Users]

Okay, I have several things to say about Father Time.

Thing one: running through these demos (frtime/demos) is kind of astonishing. 
There just doesn’t seem to be enough code for it to do what it’s doing. The 
father time programs are *incredibly* concise distillations of behavior. The 
ball-pushing demo is almost magical.

Thing two: I have a very very clear memory of being able to run a program like

#lang frtime

(current-seconds)

and seeing a changing number in the interactions window. I can’t make that work 
now, and I’ve tried versions back to 7.3, which is the oldest one I have handy 
that still runs on my mac. I’ve tried various combinations of (seconds) and 
(current-seconds), running in the definitions and interactions window, and none 
seem to work “correctly” (that is, with a changing number in the interactions 
window). Is this something that went away a long time ago? Did I ask this 
question already? Sigh.

John



-- 
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/f8b9118d-66c7-4735-89a0-9976a307ac56%40mtasv.net.

[racket-users] Generators vs streams (incl. new library)

[Siddhartha Kasivajhula]

Hi folks,
Here is a by-no-means definitive, and yet hopefully useful library for
working with generators:

https://docs.racket-lang.org/generator-util/index.html

In writing this library, I thought about the cases in which one might use a
generator vs a stream in practice. Since Racket provides such great
interfaces for working with streams, why not just always use them, and
maybe convert generators into streams using utilities like in-producer
?
It somehow felt wrong to do that, so I did some digging to see what people
might have said on the subject. I found a paper
 about it, but it
didn't really get into this particular point.

In the end I seemed to converge on that while streams are great for lazy
semantics in general, generators are a more natural fit when, in addition
to requiring lazy semantics:
1. We are working with state and side effects (although of course there's
nothing except good sense preventing us from writing streams that deal in
side effects), or
2. In cases where function semantics are more natural, rather than sequence
semantics, and finally, and probably the most important
3. When we need constant memory guarantees, for instance, while processing
large datasets for some "big data" style task. For this last point, since
streams memoize return values
, their
memory requirements should grow linearly, is that right?

Anyway, whatever the reason one might use them, it just felt like working
with generators could be a little more convenient, hence this library.
There are 2 main caveats with using these utilities: (1) they don't support
coroutines, i.e. cases where you need to send data to an "online"
generator, vs just consuming from it (does anyone know if there is a way to
do generator delegation in Racket, like in python
?), and (2) the
provided "constructors" aren't lazy, so they are best used to manipulate
existing generators rather than truly construct generators from scratch for
production usecases (not sure this pattern of usage would ever really come
up, but just for symmetry with e.g. streams).

Finally, for reference, quickcheck
 and rackcheck
 also seem to provide
some useful generator-related utilities (not sure if they are limited to
testing usecases).

-Sid

-- 
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/CACQBWFmG9pfZwk7qr-gGXPgiJgpNekgK2MVGHRQqSUeZT1XDRA%40mail.gmail.com.

[racket-users] Re: Question about generating urls with dispatch-rules from imported modules

[Greg Hendershott]

Although I haven't tried to use it hands-on, the description of the 
imperative flavor makes me think it might be intended to help with this?

  
https://docs.racket-lang.org/web-server/dispatch.html#%28part._.Imperative_.Dispatch_.Containers%29


p.s. In general you *can* do mutual requires with lazy-require. However you 
defer some errors to runtime, and, you need to list explicitly each 
definition you want to import. IMHO it's better for when the motivation to 
be lazy is about deferring loading and initializing a module, than it is 
for mutual imports. For the latter I tend to just try to move the shared 
definitions to some new module that the others require.

-- 
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/091f3749-8a4f-457b-ac29-37c3f581f798%40googlegroups.com.

Re: [racket-users] Functions not being linked in scribble

[David Storrs]

On Tue, Apr 28, 2020 at 11:41 AM Sam Tobin-Hochstadt 
wrote:

> I believe you're missing a `defmodule` inside test.scrbl.
>

Aha.  Okay, I:

*) Added @defmodule[test] to the test.scrbl file
*) Created a main.rkt that did (require "test.rkt") and (provide
(all-from-out "test.rkt"))
*) Did a raco pkg install to ensure that test was a recognized collection.
*) scribble test.scrbl

At that point it works correctly.   Thank you!


> Sam
>
> On Tue, Apr 28, 2020 at 11:32 AM David Storrs 
> wrote:
> >
> > Here's my test code.  I get the test.html file out at the end and, as
> expected, the explanation of bar says "Calls foo" with foo in blue with a
> red line underneath.  What am I missing?
> >
> >
> > ; test.rkt
> > #lang racket
> > (provide (all-defined-out))
> > (define (foo) 7)
> > (define (bar) (foo))
> >
> > --
> >
> > ; test.scrbl
> > #lang scribble/manual
> > @(require (for-label racket "test.rkt"))
> > @title{My Library}
> > @defproc[(foo) any]{Returns 7}
> > @defproc[(bar) any]{Calls @racket[foo]}
> >
> > --
> >
> > ; command line
> >
> > $ racket
> > Welcome to Racket v7.6.
> > > (require "test.rkt")
> > > (bar)
> > 7
> >
> >
> > $ scribble test.scrbl
> >
> > Output:
> > test.scrbl:6:10: WARNING: no declared exporting libraries for definition
> >   in: foo
> > test.scrbl:8:10: WARNING: no declared exporting libraries for definition
> >   in: bar
> >  [Output to test.html]
> > Warning: some cross references may be broken due to undefined tags:
> >  (dep (# bar))
> >  (dep ((lib "racket/contract/base.rkt") any))
> >  (dep ((lib "racket/contract.rkt") any))
> >  (dep ((lib "racket/contract/private/misc.rkt") any))
> >  (dep (# foo))
> >  (dep ((lib "racket/main.rkt") any))
> >
> >
> > On Tue, Apr 28, 2020 at 11:00 AM Ben Greenman <
> benjaminlgreen...@gmail.com> wrote:
> >>
> >> On 4/28/20, David Storrs  wrote:
> >> > According to what I see in Scribble, both actual examples and in the
> >> > documentation, I had thought that if I did @defproc[func-name] then
> >> > func-name would become a link target and later uses of
> @racket[func-name]
> >> > would automatically link to that site.  I'm clearly missing
> something; my
> >> > functions are being rendered in link style but they have red links
> under
> >> > them and are not actually links.  Can someone point me in the right
> >> > direction?
> >>
> >> Did you (require (for-label  func-name)) ?
> >>
> >> --
> >> 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/CAFUu9R5%3Dk-WHJ87FHFbLFj-XWy9%2BhMrsVGXcGfeA834s25EfVg%40mail.gmail.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/CAE8gKodfM9TON5T7hwjQ6XPUCKGHdv98Rx-cX%2BFDo6ALXLg36A%40mail.gmail.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/CAE8gKoeyYV_dx6QgLfXeqkD1JojOQSpN9ejQYO%3DMtcYYUL7Z5g%40mail.gmail.com.

Re: [racket-users] Functions not being linked in scribble

[Sam Tobin-Hochstadt]

I believe you're missing a `defmodule` inside test.scrbl.

Sam

On Tue, Apr 28, 2020 at 11:32 AM David Storrs  wrote:
>
> Here's my test code.  I get the test.html file out at the end and, as 
> expected, the explanation of bar says "Calls foo" with foo in blue with a red 
> line underneath.  What am I missing?
>
>
> ; test.rkt
> #lang racket
> (provide (all-defined-out))
> (define (foo) 7)
> (define (bar) (foo))
>
> --
>
> ; test.scrbl
> #lang scribble/manual
> @(require (for-label racket "test.rkt"))
> @title{My Library}
> @defproc[(foo) any]{Returns 7}
> @defproc[(bar) any]{Calls @racket[foo]}
>
> --
>
> ; command line
>
> $ racket
> Welcome to Racket v7.6.
> > (require "test.rkt")
> > (bar)
> 7
>
>
> $ scribble test.scrbl
>
> Output:
> test.scrbl:6:10: WARNING: no declared exporting libraries for definition
>   in: foo
> test.scrbl:8:10: WARNING: no declared exporting libraries for definition
>   in: bar
>  [Output to test.html]
> Warning: some cross references may be broken due to undefined tags:
>  (dep (# bar))
>  (dep ((lib "racket/contract/base.rkt") any))
>  (dep ((lib "racket/contract.rkt") any))
>  (dep ((lib "racket/contract/private/misc.rkt") any))
>  (dep (# foo))
>  (dep ((lib "racket/main.rkt") any))
>
>
> On Tue, Apr 28, 2020 at 11:00 AM Ben Greenman  
> wrote:
>>
>> On 4/28/20, David Storrs  wrote:
>> > According to what I see in Scribble, both actual examples and in the
>> > documentation, I had thought that if I did @defproc[func-name] then
>> > func-name would become a link target and later uses of @racket[func-name]
>> > would automatically link to that site.  I'm clearly missing something; my
>> > functions are being rendered in link style but they have red links under
>> > them and are not actually links.  Can someone point me in the right
>> > direction?
>>
>> Did you (require (for-label  func-name)) ?
>>
>> --
>> 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/CAFUu9R5%3Dk-WHJ87FHFbLFj-XWy9%2BhMrsVGXcGfeA834s25EfVg%40mail.gmail.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/CAE8gKodfM9TON5T7hwjQ6XPUCKGHdv98Rx-cX%2BFDo6ALXLg36A%40mail.gmail.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/CAK%3DHD%2BaxqHQ7276t5m8RRh_kQT8pTse%2B9bZ2Moxcbvw4xxRD_A%40mail.gmail.com.

Re: [racket-users] Functions not being linked in scribble

[David Storrs]

Here's my test code.  I get the test.html file out at the end and, as
expected, the explanation of bar says "Calls foo" with foo in blue with a
red line underneath.  What am I missing?


; test.rkt
#lang racket
(provide (all-defined-out))
(define (foo) 7)
(define (bar) (foo))

--

; test.scrbl
#lang scribble/manual
@(require (for-label racket "test.rkt"))
@title{My Library}
@defproc[(foo) any]{Returns 7}
@defproc[(bar) any]{Calls @racket[foo]}

--

; command line

$ racket
Welcome to Racket v7.6.
> (require "test.rkt")
> (bar)
7


$ scribble test.scrbl

Output:
test.scrbl:6:10: WARNING: no declared exporting libraries for definition
  in: foo
test.scrbl:8:10: WARNING: no declared exporting libraries for definition
  in: bar
 [Output to test.html]
Warning: some cross references may be broken due to undefined tags:
 (dep (# bar))
 (dep ((lib "racket/contract/base.rkt") any))
 (dep ((lib "racket/contract.rkt") any))
 (dep ((lib "racket/contract/private/misc.rkt") any))
 (dep (# foo))
 (dep ((lib "racket/main.rkt") any))


On Tue, Apr 28, 2020 at 11:00 AM Ben Greenman 
wrote:

> On 4/28/20, David Storrs  wrote:
> > According to what I see in Scribble, both actual examples and in the
> > documentation, I had thought that if I did @defproc[func-name] then
> > func-name would become a link target and later uses of @racket[func-name]
> > would automatically link to that site.  I'm clearly missing something; my
> > functions are being rendered in link style but they have red links under
> > them and are not actually links.  Can someone point me in the right
> > direction?
>
> Did you (require (for-label  func-name)) ?
>
> --
> 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/CAFUu9R5%3Dk-WHJ87FHFbLFj-XWy9%2BhMrsVGXcGfeA834s25EfVg%40mail.gmail.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/CAE8gKodfM9TON5T7hwjQ6XPUCKGHdv98Rx-cX%2BFDo6ALXLg36A%40mail.gmail.com.

Re: [racket-users] Rhombus project plan

[David Storrs]

I'll throw this in simply so that it's part of this thread.  There's
nothing new here, so if you've seen my comments in earlier Racket2 threads
then you can skip this.

I've said before and continue to think that getting rid of the parenthesis
syntax is a major error.  It is inarguable that there are significant
advantages to parenthesis syntax -- to name a few: No need to memorize
precedence tables, ease of code serialization and composition, extreme
friendliness to parsers and generators.  So far as I've seen, no one has
yet presented an argument in support of eliminating parenthesis notation
aside from "My students will find it easier."  That may or may not be true
but I find myself unconvinced that it is the major barrier to widespread
adoption.  I believe that people are not avoiding Racket primarily because
it has parentheses, they are avoiding it because it's one more thing to
learn, it's a huge language with sometimes daunting documentation, and they
aren't sold that the advantages will outweigh the effort + lack of
applicability to getting a job.  That's a matter for evangelism and
documentation development, not a language rewrite.

The Racket documentation is very impressive -- it's aesthetically
beautiful, it's thorough, and once you get comfortable with BNF the
Reference becomes very useful.  The documentation also has some weak
points, such as the Reference needing more examples, and it would be
helpful to have a visual distinction between the Guide and the Reference so
that when links point back and forth it's easy to tell which one you're in.
More importantly, it's very difficult to contribute to the documentation
without a lot of effort due to the literate programming style of needlessly
templatized chunks, link targets that don't match page URLs, and excessive
numbers of repositories with filetree layouts that are not intuitive.  (Or,
at least, aren't intuitive for *me*.  I don't think I'm smarter than the
average bear but I'm an experienced developer who has contributed to
multiple open source projects and I don't think it should be this difficult
to figure out.)  I'm good at documentation and would be delighted to
contribute a ton of it if those barriers to entry were lower.


On Wed, Oct 2, 2019 at 3:27 PM Matthew Flatt  wrote:

> [[NOTE: "Rhombus" is the new name for a design project formerly known
>   as "Racket2", but "Rhombus" IS NOT THE FINAL NAME OF THE NEW LANGUAGE.
>
>   "Rhombus" is the name of the project that will develop a language,
>   and "Rhombus" is a temporary stand-in for a language name to be
>   determined later. Phase 3 of the plan includes the mandatory step of
>   picking a new language name.]]
>
> Rhombus is about building on the good parts of Racket and advancing the
> frontier of Racket-style language-oriented programming. A significant
> part of the experiment is trying a surface syntax other than
> parenthesized prefix notation. Another part is simplifying and
> generalizing elements of `#lang racket`, such as its data structures
> for streams and binding with integrated and extensible
> pattern-matching. While some of these goals could be pursued
> independently, taking them together offers opportunities to make the
> whole language fit together better.
>
> Whether Rhombus will become a suitable alternative for current `#lang
> racket` can be determined only as the experiment progresses. It starts
> with that ambition, but the project may fail. It may fail for technical
> reasons, process reasons, or social reasons:
>
>  - On the technical side, we're trying to do something new.
>
>  - On the process side, we are trying a more visible and open approach
>than we have used for past major changes, even to the point of
>opening up the early exploratory phase.
>
>  - On the social side, we hope that skeptical Racketeers will make room
>for the experiment and understand that putting the experiment in the
>open (and being up-front about development costs) is part of the
>more open process.
>
> Matthew Flatt will lead the project with the guidance and consent of
> Racket project leadership. In early phases of the experiment, Matthew
> is responsible for delegating and deciding when the next phase starts.
> Toward the end of the process, Racket leadership is responsible for
> deciding whether to continue. Community participation is built into the
> process by keeping the design discussion open and by using an RFC
> process for the eventual design elements.
>
>
> What Will Happen to Racket During Rhombus
> -
>
> The Racket team will continue to maintain the language and its
> implementations:
>
>  - The existing ecosystem will continue to function as always.
>
>  - Existing `#lang racket` programs will continue to run, just as in
>the 6.x and 7.x series of releases.
>
>  - The team will release updated versions, occasionally making modest
>incompatibilities with explicit transition paths as needed ---

Re: [racket-users] Functions not being linked in scribble

[Ben Greenman]

On 4/28/20, David Storrs  wrote:
> According to what I see in Scribble, both actual examples and in the
> documentation, I had thought that if I did @defproc[func-name] then
> func-name would become a link target and later uses of @racket[func-name]
> would automatically link to that site.  I'm clearly missing something; my
> functions are being rendered in link style but they have red links under
> them and are not actually links.  Can someone point me in the right
> direction?

Did you (require (for-label  func-name)) ?

-- 
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/CAFUu9R5%3Dk-WHJ87FHFbLFj-XWy9%2BhMrsVGXcGfeA834s25EfVg%40mail.gmail.com.

[racket-users] Functions not being linked in scribble

[David Storrs]

According to what I see in Scribble, both actual examples and in the
documentation, I had thought that if I did @defproc[func-name] then
func-name would become a link target and later uses of @racket[func-name]
would automatically link to that site.  I'm clearly missing something; my
functions are being rendered in link style but they have red links under
them and are not actually links.  Can someone point me in the right
direction?

-- 
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/CAE8gKodzFS9AEK%3Dj%3D3NvcckT9mZY3XO_5gxv%3DAe8G7Z0KoJ%2BPQ%40mail.gmail.com.

[racket-users] Re: Rhombus project plan

[unlimitedscolobb]

Hello everyone and thank you for this very interesting discussion!

I'd like to share my opinion on parenthesized prefix syntax: I actually 
switched to Racket/Lisp because of it!  This highly uniform structure best 
fits the shape of mind as of today.

Now, I explicitly don't pretend to be representative.  Consider me to be 
the voice of those folks out there who are actually fond of parenthesis.

-
Sergiu


On Monday, April 27, 2020 at 7:25:09 PM UTC+2, Anurag Mendhekar wrote:
>
>  First of all, Thank you to the team for making such a fantastic system 
> available for the rest of us. I don't know what I'd have done without it.  
> As a very long time Schemer/Racketeer/Lisper and a consistent industry 
> practitioner (I have used Chez Scheme and Racket as critical parts of every 
> one of my companies in the past 20 years).
>
> It is somewhat unclear to me from reading this proposal what the expected 
> outcomes of this project are, or ought to be (in terms of making a real 
> change in the language ecosystem). But, if one of the outcomes is to gain 
> widespread adoption, my first thoughts upon reading this proposal are as 
> follows. 
>
> 1. The obsession with parentheses/syntax is misplaced. My analysis of the 
> psychology of parentheses that it is a redirection of frustration with 
> functional-style programming. Let's acknowledge the fact that functional 
> programming is a difficult paradigm for the average CS graduate and they 
> generally skew imperative (it's probably rooted in human psychology, since 
> that is how our systems are organized: around change of state). In any 
> case, the frustration in dealing with it is directed towards syntax in the 
> case of Racket. Other functional languages with conventional syntax suffer 
> the same outcome: lack of widespread adoption because of perceived 
> "annoyances". While I would welcome the ability to more easily add new 
> (possibly infix) notation into my own syntactic extensions, spending too 
> much time designing a new "better" syntax for racket is not going to reduce 
> the adoption barrier. So, I would rather own it than defend it. 
>
> 2. Adoption will be widespread once the language and its accompanying 
> platform can stake out a claim for itself in terms of what can be built 
> with it. 
>
> I can't speak to the other aspects of internal design that this post talks 
> about but here is what I believe we need in the industry to convince my new 
> crop of engineers to start adopting Racket at a larger scale. In some ways, 
> I'm looking at it as a "sell" job, and here are the things I know I can 
> sell. This is not so much about language design as much as it is about the 
> Platform itself, although I'm sure Racketeers can do a far better job of 
> bringing in elements of language design into this. Of course, the community 
> needs to work towards doing this along with the Racket team, but as a 
> community, we should set an agenda and work towards it. The Rhombus 
> discussion provides an opportunity for this. So here are my two cents. 
>
> A) Performance. As a point of comparison, the JVM has gotten amazingly 
> good over the past couple of decades, but Java continues to be derided as a 
> terrible language with much lower productivity. Given how productive one 
> can be in Racket, combining that with comparable performance will make it 
> an easy sell. This has largely been Go's and Rust's strategy. C++ level 
> performance with high productivity. For this day and age, this would have 
> to include GPU support (kind of like openCL). 
> B) Web First. The current the built-in web framework is not enough. The 
> language must support end-to-end development of asynchronous 
> web-applications, and it must be trivial to tack on web front-ends to 
> anything. This is the Node/JS and Ruby/Rails strategy. Racket has some 
> elements of this, but building a web-app in racket is still a lot of work. 
> With web-assembly on the horizon, Racket can very easily be a front-end 
> language as well as a back-end language. 
> C) Mobile First (ok, Second :-). The language must provide inherent 
> support for building mobile front-ends (both android and IoS). This is the 
> Swift/XCode strategy. 
> D) AI Support. AI is clearly the next wave of software and people are 
> going to be building AI into their systems for decades to come. In this 
> instance, Lisp's AI legacy might actually be of help, if we can make it 
> very easy to develop AI applications. While Python seems to be the 
> preferred language right now, I don't believe it will last too long. AI 
> programming in Python is at best a puke-worthy experience. 
> E) Cloud Ready out of the box - Simple deployment using docker, AWS Lambda 
> and the like; built-in support for directly working with cloud resources 
> (buckets, ACL's, Logs, etc.)
> F) Broad IDE support. Rather than focus on Emacs/Dr. Racket, I believe 
> Racket should take the approach of integrating with all the different 
> IDE's. (