Re: [racket-users] Re: Racket2 possibilities
> I experimented with various scheme in browser intrepred via JavaScript and compiled to wasm both are not good enough. Insufficient implementations I suppose, or wasm misses features important for a Scheme ... Em segunda-feira, 22 de julho de 2019 15:33:59 UTC+1, amz3 escreveu: > > > > On Monday, July 22, 2019 at 4:26:04 PM UTC+2, Mário Guimarães wrote: >> >> >> > And the JVM in browsers has been thoroughly supplanted by Javascript. >> >> I missed another VM: Racket2 should also target WebAssembly. >> > > I experimented with various scheme in browser intrepred via JavaScript and > compiled to wasm both are not good enough. > -- 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/9b5cdf22-8d78-42d8-86a0-bf5893a26f74%40googlegroups.com.
[racket-users] Re: Racket2 possibilities
I have read through all the posts before mine, and saw no reference to what could be the solution to the adoption problem. I only remember comments regarding how students feel unconfortable about s-expressions and all those parenthesis Making a language popular in my view is to make it attractive to professional developers and the industry overal, not to students. In fact, too much reference to students makes people from industry think that the language is for use only in academic settings, and this is very unfortunate they think so. I have mentioned this one, and will repeat again: *Make Racket become Language-Oriented Programming on the JVM, the ErlangVM, and perhaps other mainstream VMs.* Do this first, then watch, then consider other changes, like the syntax one. I really don't believe that how beautiful and operational a new syntax becomes, will it attract people in the industry who are too much committed to these VMs. Failing to target these VMs and you will be in the next 5 years asking again why Racket 2 is still hardly adopted. I can't say more regarding Racket's adoption strategy. Thanks Mário Guimarães Em sábado, 20 de julho de 2019 19:49:13 UTC+1, Matthew Flatt escreveu: > > 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
[racket-users] Re: The case, and a proposal, for elegant syntax in #lang racket2
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,
