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

[David Storrs]

Two things that I would like to see in Racket2 would be return values being
standard practice and the ability to return nothing.

Racket has a lot of functions that return #; that's not helpful.  In
almost every case, there is a sensible thing to return and it would be
better to return it -- for example, when you set something, return it.  It
doesn't need to change any existing code, since the existing code ignores
the return value.  Likewise, no one has to worry about remembering exactly
what it is that gets returned; just ignore the return value like you're
already doing.

The other thing I'd like to see would be the option to return nothing.  Not
#, '(), or #f.  Nothing.  It's useful e.g. when you want to
simultaneously transform and filter a list.

On Wed, Jul 17, 2019 at 11:50 PM Daniel Prager 
wrote:

> I'm confused on one point.
>
> Why would a new canonical notation be preferable to, say, also fully
> supporting an alternative general notation (like Shriram's p4p, or a
> derivative thereof) or even multiple notations in addition to retaining
> good old s-expressions?
>
> The idea would be that you could transform freely and readably between
> alternative notations, enabling round-tripping without degradation.
>
> I imagine that effectively providing tooling, syntax-extension, good error
> messages, and documentation across multiple notations would be (ahem)
> challenging, but so long as we're dreaming big ...
>
>
> Dan
>
> --
> 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/CAFKxZVV-njHNCCLDP-RsDq%2BjbXrOGpOnaEp9Ob4ugTbdtmckAw%40mail.gmail.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/CAE8gKodKrWNeL3tJQ5uO4X64jKzBVmYY2P9BgLsd%3Dqh8bhSQyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Prager]

I'm confused on one point.

Why would a new canonical notation be preferable to, say, also fully
supporting an alternative general notation (like Shriram's p4p, or a
derivative thereof) or even multiple notations in addition to retaining
good old s-expressions?

The idea would be that you could transform freely and readably between
alternative notations, enabling round-tripping without degradation.

I imagine that effectively providing tooling, syntax-extension, good error
messages, and documentation across multiple notations would be (ahem)
challenging, but so long as we're dreaming big ...


Dan

-- 
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/CAFKxZVV-njHNCCLDP-RsDq%2BjbXrOGpOnaEp9Ob4ugTbdtmckAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christopher Lemmer Webber]

Hendrik Boom writes:

> On Wed, Jul 17, 2019 at 04:52:37PM -0700, Maria Gabriela Guimarães wrote:
>>
>> Does Racket wants to be popular in the industry? Then Racket must focus on
>> being a language-oriented programming ecosystem on a popular VM, like the
>> ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the
>> RacketVM, if there's such a thing, and to start moving Racket's
>> language-oriented programming features into these popular VMs.
>
> There may be performance advantages to the Racket VM, so I wouldn't
> stop developing it.  But adding those other popular VMs may well be a
> win.
>
> -- hendrik

The work that Matthew Flatt is doing on Racket-on-Chez should be opening
up the possibility of running Racket on multiple other foundations, is
my understanding from conversations in the past.  So I don't think we
need to pivot, since opening up the possibility for this is already on
track.

-- 
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/87d0i814yk.fsf%40dustycloud.org.
For more options, visit https://groups.google.com/d/optout.

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

[Hendrik Boom]

On Wed, Jul 17, 2019 at 04:52:37PM -0700, Maria Gabriela Guimarães wrote:
> 
> Does Racket wants to be popular in the industry? Then Racket must focus on 
> being a language-oriented programming ecosystem on a popular VM, like the 
> ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the 
> RacketVM, if there's such a thing, and to start moving Racket's 
> language-oriented programming features into these popular VMs.

There may be performance advantages to the Racket VM, so I wouldn't 
stop developing it.  But adding those other popular VMs may well be a 
win. 

-- hendrik

-- 
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/20190718015018.6zanhroooyzwxffq%40topoi.pooq.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mário Guimarães]

Hello, community!

Let me tell a few words about the idea of transitioning Racket to a 
traditional syntax to gain popularity: I think this idea is a fallacy. 
Racket is not popular due to its s-expression syntax, because Clojure has 
such a syntax, and still, it seems popular. So I don't think such step will 
raise the adoption of Racket.

There is nothing new in having a traditional syntax language with Lisp-like 
macros. There is one, it's Elixir. Note that I have lots of experience 
writing complex macros in Elixir, and I expect writing macros in an 
s-expression language to be much easier, simply because in such a language, 
its notation and its AST are isomorphic, i.e., they share the same syntax. 
Let me explain this: in Elixir, sometimes, the way to verify if a macro 
generates the code we want, is to see what this code's AST looks like, 
which in Elixir is a kind of s-expression (yes!), and from this, infer how 
to build the AST inside the macro using the Elixir notation; this effort is 
totally unnecessary in languages in which the notation and the AST are the 
same thing.

In short: Clojure is a popular s-expression language on the JVM, and Elixir 
is a popular Lisp-2 language on the ErlangVM, consequently, the `Racket 2` 
language will contribute nothing to Racket's wide adoption. In fact, I 
think it will be a strategic mistake, if popularity is all about. 

Does Racket wants to be popular in the industry? Then Racket must focus on 
being a language-oriented programming ecosystem on a popular VM, like the 
ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the 
RacketVM, if there's such a thing, and to start moving Racket's 
language-oriented programming features into these popular VMs. I don't 
think that having a kind of Elixir++ on an unpopular VM, will make the 
industry adopt such a language.

For example, I would love to see Racket become a statically typed Lisp-like 
language-oriented programming ecosystem on the Erlang VM. I am sure if this 
ever happens, there will be hordes of programmers jumping immediately into 
such ecosystem. (Ehh, I think the Shen language is the closest thing there 
is, but oh my, nothing can have a more terrible marketing strategy than 
that of Shen).

To conclude, I wish a great future to Racket, and will continue following 
its future development. Ah, I like the Hackett idea also, very very 
interesting, and promising direction, but again it needs to target a 
popular VM.

Cheers,
Mário Guimarães

domingo, 14 de Julho de 2019 às 18:44:30 UTC+1, cwebber escreveu:
>
> The context of this email is the proposal by Matthew Flatt that we move 
> to an easier-to-accept surface syntax for #lang racket2. 
>
> Matthew Flatt has heard more than enough from me of concern about this 
> proposal.  But I should indicate that I'm highly sympathetic to the 
> goal.  I would like to lay out the following observations: 
>
>  - The challenge with s-expressions is largely in anxiety with something 
>that looks extremely alien.  I suspect there's more fear from 
>instructors than students in encountering a lisp syntax; my 
>experience is that introducing someone who doesn't know differently 
>to a parenthetical syntax isn't scary for them, and they tend to like 
>it.  But people who have *started out* with experience in a non-lispy 
>language tend to find it scary. 
>
>  - Nonetheless, assumptions that various math operators should be infix 
>is understandable because that's what people see today. 
>
>  - I am indeed very for growth in the community, though my main interest 
>in growth is in seeing a wider diversity of participants than just 
>raw numbers.  Obviously other peoples' mileage may vary. 
>
>  - We are at serious risk in this pivot of losing some key things: 
>
>- Many communities I have been in that have undertaken such a large 
>  pivot to increase popularity expend enormous energy in the move to 
>  the new thing, and in that process, the project actually collapses. 
>  What I'm trying to say is that a pivot is a gamble; we should 
>  calculate our odds carefully.  (Indeed, the first thing I thought 
>  when I heard that this might happen was, did I make a mistake in 
>  shifting my work to Racket?  It is unlikely I would have come to 
>  Racket if there wasn't an equivalent amount of elegance.) 
>
>- I'm not sure if I could have understood Racket Week with a syntax 
>  that didn't have the elegance of s-expressions.  This is not to say 
>  that *no* syntax can have that level of elegance where things can 
>  be so clear, however. 
>
> IIRC Matthew's proposal for "#lang racket2" was something like the 
> following: 
>
>  a) function(args ...) should work. 
>  b) infix is necessary for math, such as 3 + 4 
>  c) parentheses should be possible for grouping 
>
> The weird thing about the last one being that this is already kind of 
> true in s-expressions, but by 

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

[Maria Gabriela Guimarães]

Hello, community!

Let me tell a few words about the idea of transitioning Racket to a 
traditional syntax to gain popularity: I think this idea is a fallacy. 
Racket is not popular due to its s-expression syntax, because Clojure has 
such a syntax, and still, it seems popular. So I don't think such step will 
raise the adoption of Racket.

There is nothing new in having a traditional syntax language with Lisp-like 
macros. There is one, it's Elixir. Note that I have lots of experience 
writing complex macros in Elixir, and I expect writing macros in an 
s-expression language to be much easier, simply because in such a language, 
its notation and its AST are isomorphic, i.e., they share the same syntax. 
Let me explain this: in Elixir, sometimes, the way to verify if a macro 
generates the code we want, is to see what this code's AST looks like, 
which in Elixir is a kind of s-expression (yes!), and from this, infer how 
to build the AST inside the macro using the Elixir notation; this effort is 
totally unnecessary in languages in which the notation and the AST are the 
same thing.

In short: Clojure is a popular s-expression language on the JVM, and Elixir 
is a popular Lisp-2 language on the ErlangVM, consequently, the `Racket 2` 
language will contribute nothing to Racket's wide adoption. In fact, I 
think it will be a strategic mistake, if popularity is all about. 

Does Racket wants to be popular in the industry? Then Racket must focus on 
being a language-oriented programming ecosystem on a popular VM, like the 
ErlangVM, the JVM, and the WebAssemblyVM. This means to stop working on the 
RacketVM, if there's such a thing, and to start moving Racket's 
language-oriented programming features into these popular VMs. I don't 
think that having a kind of Elixir++ on an unpopular VM, will make the 
industry adopt such a language.

For example, I would love to see Racket become a statically typed Lisp-like 
language-oriented programming ecosystem on the Erlang VM. I am sure if this 
ever happens, there will be hordes of programmers jumping immediately into 
such ecosystem. (Ehh, I think the Shen language is the closest thing there 
is, but oh my, nothing can have a more terrible marketing strategy than 
that of Shen).

To conclude, I wish a great future to Racket, and will continue following 
its future development. Ah, I like the Hackett idea also, very very 
interesting, and promising direction, but again it needs to target a 
popular VM.

Best Regards,
Mário Guimarães

Em domingo, 14 de julho de 2019 18:44:30 UTC+1, cwebber escreveu:
>
> The context of this email is the proposal by Matthew Flatt that we move 
> to an easier-to-accept surface syntax for #lang racket2. 
>
> Matthew Flatt has heard more than enough from me of concern about this 
> proposal.  But I should indicate that I'm highly sympathetic to the 
> goal.  I would like to lay out the following observations: 
>
>  - The challenge with s-expressions is largely in anxiety with something 
>that looks extremely alien.  I suspect there's more fear from 
>instructors than students in encountering a lisp syntax; my 
>experience is that introducing someone who doesn't know differently 
>to a parenthetical syntax isn't scary for them, and they tend to like 
>it.  But people who have *started out* with experience in a non-lispy 
>language tend to find it scary. 
>
>  - Nonetheless, assumptions that various math operators should be infix 
>is understandable because that's what people see today. 
>
>  - I am indeed very for growth in the community, though my main interest 
>in growth is in seeing a wider diversity of participants than just 
>raw numbers.  Obviously other peoples' mileage may vary. 
>
>  - We are at serious risk in this pivot of losing some key things: 
>
>- Many communities I have been in that have undertaken such a large 
>  pivot to increase popularity expend enormous energy in the move to 
>  the new thing, and in that process, the project actually collapses. 
>  What I'm trying to say is that a pivot is a gamble; we should 
>  calculate our odds carefully.  (Indeed, the first thing I thought 
>  when I heard that this might happen was, did I make a mistake in 
>  shifting my work to Racket?  It is unlikely I would have come to 
>  Racket if there wasn't an equivalent amount of elegance.) 
>
>- I'm not sure if I could have understood Racket Week with a syntax 
>  that didn't have the elegance of s-expressions.  This is not to say 
>  that *no* syntax can have that level of elegance where things can 
>  be so clear, however. 
>
> IIRC Matthew's proposal for "#lang racket2" was something like the 
> following: 
>
>  a) function(args ...) should work. 
>  b) infix is necessary for math, such as 3 + 4 
>  c) parentheses should be possible for grouping 
>
> The weird thing about the last one being that this is already kind of 
> true in s-expressions, 

Re: [racket-users] Re: Reflecting on the lexical environment at macro expansion time

[William J. Bowman]

Excellent! Thanks.

On Wed, Jul 17, 2019 at 01:46:10PM -0700, gfb wrote:
> On Wednesday, July 17, 2019 at 4:35:21 PM UTC-4, William J. Bowman wrote:
> >
> > I'm trying to write a macro that reflects on which identifiers are in 
> > scope in 
> > the environment when it runs, and on the identifiers in scope for its 
> > generated 
> > code. 
> > It should act something like this: 
> >
> >   (define-syntax (display-env stx) 
> > (syntax-case stx () 
> >   [(_) 
> >(printf "Env: ~a" (local-environment))])) 
> >
> >   > (lambda (x) (display-env) x) 
> >   Env: '(x) 
> >   # 
> >   > (lambda (x) (let-syntax ([y (make-rename-transformer #'x)]) 
> > (display-env) y)) 
> >   Env: '(y x) 
> >   # 
> >
> > Presumably, the expander knows which identifiers are in scope, so I 
> > *ought* to 
> > be able to get my hands on that set. 
> >
> > namespaces aren't the thing; they only give me access to the top-level 
> > definitions, as far as I can tell. 
> > I also want access to any lexical identifiers introduced by `λ` or `let` 
> > or 
> > `let-syntaxes` or `let-values` etc. 
> > But I want to be able to use them pretty much like namespaces: get the 
> > list of 
> > symbols in scope, and get their values and identifiers. 
> >
> > Any one know how to do this? 
> >
> > -- 
> > William J. Bowman 
> >
> 
> Take a look at  syntax-debug-info 
> 
>  
> , which you can see used in  
> https://github.com/AlexKnauth/debug/blob/master/debug/repl.rkt 
> .
> 
> 
> -- 
> 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/7b0eb8f1-b9cb-4065-9a90-1708237d5040%40googlegroups.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/20190717210210.GE86511%40williamjbowman.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Reflecting on the lexical environment at macro expansion time

[gfb]

On Wednesday, July 17, 2019 at 4:35:21 PM UTC-4, William J. Bowman wrote:
>
> I'm trying to write a macro that reflects on which identifiers are in 
> scope in 
> the environment when it runs, and on the identifiers in scope for its 
> generated 
> code. 
> It should act something like this: 
>
>   (define-syntax (display-env stx) 
> (syntax-case stx () 
>   [(_) 
>(printf "Env: ~a" (local-environment))])) 
>
>   > (lambda (x) (display-env) x) 
>   Env: '(x) 
>   # 
>   > (lambda (x) (let-syntax ([y (make-rename-transformer #'x)]) 
> (display-env) y)) 
>   Env: '(y x) 
>   # 
>
> Presumably, the expander knows which identifiers are in scope, so I 
> *ought* to 
> be able to get my hands on that set. 
>
> namespaces aren't the thing; they only give me access to the top-level 
> definitions, as far as I can tell. 
> I also want access to any lexical identifiers introduced by `λ` or `let` 
> or 
> `let-syntaxes` or `let-values` etc. 
> But I want to be able to use them pretty much like namespaces: get the 
> list of 
> symbols in scope, and get their values and identifiers. 
>
> Any one know how to do this? 
>
> -- 
> William J. Bowman 
>

Take a look at  syntax-debug-info 

 
, which you can see used in  
https://github.com/AlexKnauth/debug/blob/master/debug/repl.rkt 
.


-- 
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/7b0eb8f1-b9cb-4065-9a90-1708237d5040%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Reflecting on the lexical environment at macro expansion time

[William J. Bowman]

I'm trying to write a macro that reflects on which identifiers are in scope in
the environment when it runs, and on the identifiers in scope for its generated
code.
It should act something like this:

  (define-syntax (display-env stx)
(syntax-case stx ()
  [(_)
   (printf "Env: ~a" (local-environment))]))

  > (lambda (x) (display-env) x)
  Env: '(x)
  #
  > (lambda (x) (let-syntax ([y (make-rename-transformer #'x)]) (display-env) 
y))
  Env: '(y x)
  #

Presumably, the expander knows which identifiers are in scope, so I *ought* to
be able to get my hands on that set.

namespaces aren't the thing; they only give me access to the top-level
definitions, as far as I can tell.
I also want access to any lexical identifiers introduced by `λ` or `let` or
`let-syntaxes` or `let-values` etc.
But I want to be able to use them pretty much like namespaces: get the list of
symbols in scope, and get their values and identifiers.

Any one know how to do this?

-- 
William J. Bowman

-- 
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/20190717203517.GD86511%40williamjbowman.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Second Call for Participation: ICFP 2019

['Sam Tobin-Hochstadt' via users-redirect]

** The Early Registration deadline is tomorrow! **

=

Call for Participation

ICFP 2019
24th ACM SIGPLAN International Conference on Functional Programming
and affiliated events

August 18 - August 23, 2019
Berlin, Germany
http://icfp19.sigplan.org/

Early Registration until July 18!

=

ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.

This year, ICFP is co-located with BOBKonf!

  * Overview and affiliated events:
http://icfp19.sigplan.org/home

  * Program:
http://icfp19.sigplan.org/program/program-icfp-2019

  * Accepted papers:
http://icfp19.sigplan.org/track/icfp-2019-papers

  * Registration is available via:
https://regmaster4.com/2019conf/ICFP19/register.php
Early registration ends 18 July, 2019.

  * Programming contest:
https://icfpcontest2019.github.io/

  * Student Research Competition:
https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition

  * Follow us on Twitter for the latest news:
http://twitter.com/icfp_conference

In addition to BOBKonf (8/21), there are several events co-located with ICFP:

  * Erlang Workshop (8/18)
  * Functional Art, Music, Modeling and Design (8/23)
  * Functional High-Performance and Numerical Computing (8/18)
  * Haskell Implementors' Workshop (8/23)
  * Haskell Symposium (8/22-8/23)
  * miniKanren Workshop (8/22)
  * ML Family Workshop (8/22)
  * OCaml Workshop (8/23)
  * Programming Languages Mentoring Workshop (8/18)
  * Scheme Workshop (8/18)
  * Type-Driven Development (8/18)

### ICFP Organizers

General Chair: Derek Dreyer (MPI-SWS, Germany)

Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK)
Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA)
Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore)
Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA)
Student Research Competition Chair: William J. Bowman (University of British 
Columbia, Canada)
Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium)
Jennifer Hackett (University of Nottingham, UK)
Conference Manager: Annabel Satin (P.C.K.)


### PACMPL Volume 3, Issue ICFP 2019

Principal Editor: François Pottier (Inria, France)

Review Committee:

Lennart Beringer (Princeton University, United States)
Joachim Breitner (DFINITY Foundation, Germany)
Laura M. Castro (University of A Coruña, Spain)
Ezgi Çiçek (Facebook London, United Kingdom)
Pierre-Evariste Dagand (LIP6/CNRS, France)
Christos Dimoulas (Northwestern University, United States)
Jacques-Henri Jourdan (CNRS, LRI, Université Paris-Sud, France)
Andrew Kennedy (Facebook London, United Kingdom)
Daan Leijen (Microsoft Research, United States)
Kazutaka Matsuda (Tohoku University, Japan)
Bruno C. d. S. Oliveira (University of Hong Kong, China)
Klaus Ostermann (University of Tübingen, Germany)
Jennifer Paykin (Galois, United States)
Frank Pfenning (Carnegie Mellon University, USA)
Mike Rainey (Indiana University, USA)
Chung-chieh Shan (Indiana University, USA)
Sam Staton (University of Oxford, UK)
Pierre-Yves Strub (Ecole Polytechnique, France)
German Vidal (Universitat Politecnica de Valencia, Spain)

External Review Committee:

Michael D. Adams  (University of Utah, USA)
Robert Atkey  (University of Strathclyde, IK)
Sheng Chen  (University of Louisiana at Lafayette, USA)
James Cheney  (University of Edinburgh, UK)
Adam Chlipala  (Massachusetts Institute of Technology, USA)
Evelyne Contejean (LRI, Université Paris-Sud, France) 
Germán Andrés Delbianco  (IRIF, Université Paris Diderot, France)
Dominique Devriese  (Vrije Universiteit Brussel, Belgium)
Richard A. Eisenberg  (Bryn Mawr College, USA)
Conal Elliott  (Target, USA)
Sebastian Erdweg  (Delft University of Technology, Netherlands)
Michael Greenberg  (Pomona College, USA)
Adrien Guatto  (IRIF, Université Paris Diderot, France)
Jennifer Hackett  (University of Nottingham, UK)
Troels Henriksen  (University of Copenhagen, Denmark)
Chung-Kil Hur  (Seoul National University, Republic of Korea)
Roberto Ierusalimschy  (PUC-Rio, Brazil)
Ranjit Jhala  (University of California, San Diego, USA)
Ralf Jung  (MPI-SWS, Germany)
Ohad Kammar  (University of Oxford, UK)
Oleg Kiselyov (Tohoku University, Japan)
Hsiang-Shang ‘Josh’ Ko  (National Institute of Informatics, Japan)
Ondřej Lhoták  (University of Waterloo, Canada)
Dan Licata  (Wesleyan University, USA)
Geoffrey Mainland  (Drexel University, USA)
Simon Marlow  (Facebook, UK)
Akimasa Morihata  (University of Tokyo, Japan)
Shin-Cheng Mu  (Academia Sinica, Taiwan)
Guillaume Munch-Maccagnoni  (Inria, France)
Kim Nguyễn  (University of Paris-Sud, France)

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

[Brian Adkins]

On Tuesday, July 16, 2019 at 8:18:24 PM UTC-4, Alexis King wrote:
>
> On Jul 16, 2019, at 15:32, rocketnia > 
> wrote:
>
> I find it worrying that racket2 would be kicked off with infix syntax 
> (something which I think of as an unnecessary sticking point in the way of 
> prospective macro writers and language designers, and hence a move *toward* 
> elitism *as opposed to* welcoming everyone)
>
>
> I think this fear is natural and understandable, but I want to take a 
> moment and urge everyone to think bigger than that, even if we as 
> programmers are often trained not to. Do not think “because we are moving 
> to a syntax for which macros are harder to express, the language we create 
> will have an inferior or more difficult to use macro system.” If we were 
> setting out to responsibly engineer a new language on a deadline, that 
> thought would be right on the money… but we’re not doing that. Racket is a 
> research language, from an ever-growing community full of very smart people 
> who have produced lots of quite significant research results. They have 
> taken problems that used to seem untenable and made them perfectly 
> achievable (and indeed, often *achieved!*).
>
> So instead of thinking about all the ways Matthew’s proposed syntax is a 
> compromise that necessarily comes with certain downsides, think of it as a 
> challenge: how do we take all the lovely things we’ve come to enjoy and 
> take for granted in #lang racket and do them in a language with a less 
> regular syntactic structure? How do we make writing great macros as easy in 
> #lang racket2 as it already is in #lang racket? That means figuring out 
> both what the primitives are *and* what the DSLs look like—syntax/parse 
> did not naturally follow from hygiene and syntax objects, as much as it 
> sometimes feels that way. I am not saying it is easy, and I’m not saying 
> it’s even guaranteed to eventually succeed: perhaps we will fail. But I 
> don’t think we have any reason to suspect we will just yet.
>
> It can’t start by being everything we want it to be, of course; things 
> take time. I just think that thinking about things as such a stark 
> dichotomy is disingenuous and self-defeating. Obviously, we should not aim 
> to become more elitist, on any axes, so let’s aim not to be. This is time 
> for pie-in-the-sky brainstorming, not risk management. Having existing 
> research to build on helps, but even that isn’t required. So although I 
> know firsthand how hard it can be as an software engineer to think about 
> what we want without worrying about how we can build it, let’s be 
> aspirational and exploratory for a bit.
>
> Alexis
>
> P.S. If your qualm with moving from s-expressions is one of aesthetics, 
> not ease or ability, I admit I can’t argue with you there. But I don’t 
> imagine those kinds of discussions are likely to go anywhere productive, 
> anyway—see Wadler’s law.
>

Some great points Alexis.

I should've learned by now to be wary of my knee-jerk reactions :) My 
initial reaction to the idea that Racket2 *might* have an infix syntax was 
to feel quite unsettled! To be clear, I like the idea of Racket2 being able 
to break backward compatibility if it makes it easier to move forward, but 
adding syntax seems to create an identity crisis for a lisp. Sweeping 
syntax changes for a language that already has syntax is one thing, but 
introducing syntax to a lisp is on another level IMO.

After a ten year search for a new programming language (ending Nov 2018), 
in which I heavily weighted both effectiveness/productivity & joy in 
programming, I chose Racket. In my 8 months of full time Racket 
development, I don't think a week has gone by where I haven't been 
pleasantly surprised by something in Racket. Racket School just piled on 
many more reasons why I was thrilled to be able to program in Racket full 
time. So the timing of the proposal, from a purely *personal* perspective, 
was poor - from the peak of (possibly) inflated expectations, to the trough 
of disillusionment!

I suppose it's possible that my love for parens came primarily from seeing 
that s-expressions made code transformations easier for me (although, I 
also like other aspects of essentially working with an abstract syntax 
tree). And I admit a weakness in being able to imagine a combination of 
infix syntax w/ a new macro system that's as nice to use as the current 
Racket way. I do remember liking Haskell's syntax when I spent time with it 
during my search, and I *think* I recall feeling that I missed some 
things (e.g. list comprehensions) about that syntax when I chose Racket, 
but that what the parens allowed for was worth it, so *maybe* if we come up 
with an elegant syntax that was no more difficult for language extension 
than what we have now, I might like it.

At this point, I'm a little less unsettled about a possible new syntax. I 
(naively?) think the Racket core team & wider community probably have a 
fairly large 

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

[rocketnia]

On Tuesday, July 16, 2019 at 5:18:24 PM UTC-7, Alexis King wrote:
>
> So instead of thinking about all the ways Matthew’s proposed syntax is a 
> compromise that necessarily comes with certain downsides, think of it as a 
> challenge: how do we take all the lovely things we’ve come to enjoy and 
> take for granted in #lang racket and do them in a language with a less 
> regular syntactic structure? How do we make writing great macros as easy in 
> #lang racket2 as it already is in #lang racket?
>

I know parts of this are sort of a response to the group, but I appreciate 
you reminding me of the pie-in-the-sky aspect. I've long wanted to see some 
more comprehensive reforms of the core language, and I'm excited about some 
of the other topics being surfaced in the RFCs repo issues. It would be so 
good if more Racket #langs could intermix, and how better to do that than 
to have a single language where even infix syntaxes are convenient to 
access?

It's just that the usual kind of wish list I have for Racket is for it to 
get a more regular syntactic structure. So many things in Racket are ad hoc 
groupings of parentheses, keywords, and DSL-specific mixfix syntaxes, when 
I believe having prefix syntax in their place would be slightly more 
conducive to people who need to recreate big chunks of the language. The 
harder it is to recreate the language, the more it's like a building with 
no fire exits. Eventually some leadership (if not today's leadership, then 
someday's) will make some mistake or some harmful decision, and the users 
will have to scramble out of a two-story window with whatever codebases 
they can gather.

Will there be a particular catastrophic inflection point like that someday? 
Maybe, I dunno. I think it's more of a long-running catastrophe that isn't 
evenly distributed, and we're the survivors. Will prefix really help that 
much? ... I don't know. It was my "Hey, I can build that!" entrypoint into 
writing my first several languages, I've seen it serve the same role for 
many people, and it's now my refuge from all the mountains of parentheses 
in my CPS JS code. Among those other experiences, the Sofware Freedom 
Conservancy talk has led me to think that it's not just me who finds it 
seriously important that Racket has inspired and equipped people to make 
their first several languages. But I don't really know beyond a rule of 
thumb.

Regardless, this one change to Racket isn't really inviting catastrophe all 
by itself. I use Racket precisely because it's the most exitable language I 
know. It has oodles of extension points, it's open source, there are 
established ways to compile Racket to alternative languages when the need 
arises, there are even paths to port code to other languages without even 
leaving behind Racket compatibility... It's good stuff. Racket isn't a 
building with no exit doors, just a building where one of the most 
prominent doors is being converted to a fancy automatic door and I'm 
fretting about whether it's the kind of door that can be pushed open in 
case the mechanism isn't working. :-p

Again, yes, thank you for reminding me that there are a lot more exciting 
improvements on the table than just this, and that this is quite an 
opportunity. Something I'm looking forward to is that if this opportunity 
is played well -- yes even this infix syntax opportunity -- it's a chance 
to bring together a lot of the community's fantastic developments into a 
single well-polished combination. :)

-Nia

-- 
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/1cbd30e5-ec4d-49e6-a149-7838d713913f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] datatypes

[Ryan Kramer]

>
>  Still, variant reports ‘(a . b) as a ‘pair. and that’s amazing. How is it 
> obtaining that information?
>

I just looked it up and yeah, it is pretty cool: (struct->vector '(a . b)) 
is doing most of the work. See the comments and implementation here: 
https://github.com/mbutterick/describe/blob/b468661a0e76fbe5ef46fe0e89e030f43f7b3acc/describe/main.rkt#L78

-- 
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/6cffaef7-eba2-487d-9bfc-eebb9881e647%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] datatypes

[Kevin Forchione]

> On Jul 16, 2019, at 10:36 PM, Alex Knauth  wrote:
> 
> 
> 
>> On Jul 17, 2019, at 12:16 AM, Kevin Forchione > > wrote:
>> 
>> Hi guys,
>> Is there any function in Racket that will return a symbol representation of 
>> a value’s datatype? We can interrogate them with predicates, but it occurs 
>> to me that this information must be carried in the object’s syntax 
>> somewhere… otherwise the syntax->datum wouldn’t work. Of course I may be 
>> overlooking something :) 
> 
> I'm not sure what you mean by "carried in the object's syntax" or why 
> syntax->datum is relevant. Could you clarify with a concrete example?
> 
> Anyway putting aside the syntax part and only looking at values, the 
> `describe` [1] package, in particular the `variant` [2] function might be 
> helpful to you or not depending on what you mean by "datatype”.

Thanks, Alex! That’s exactly what I’m looking for. My remark on syntax->datum. 
was simply speculation. A better way to put it is: how does variant able to 
convert a racket value into a symbol representing its datatype? I was thinking 
that information must be part of the object’s syntax-object, but it doesn’t 
look like it. Still, variant reports ‘(a . b) as a ‘pair. and that’s amazing. 
How is it obtaining that information?

Kevin

-- 
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/87B4031D-DD8A-439F-B954-B94C03002C5F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Greg Hendershott]

Thank you for replying.

I didn't mean to suggest I thought these things were already happening.
I don't.

And I'm sorry my attempt to express gratitude by saying you had every
right to decree it, sounded like I thought you actually would do it that
way. I don't.

I (mis?)understood that working groups would be to hash out technical
details -- not to set the basic direction and goals for the whole
project. I've seen that latter kind of discussion can be difficult even
in a small group. So I would understand *if* you decided to do that part
in private. OTOH if you decided to try it in public, that's great, too.

Whatever way the discussion would take place, I was suggesting some
questions to discuss. That's what I was trying to say even if I didn't
write as clearly as I hoped.

-- 
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/8736j5chez.fsf%40greghendershott.com.
For more options, visit https://groups.google.com/d/optout.