@alexknauth no, ~delay sounds like it would involve 3D syntax, which I don’t want to depend on either. Instead, maybe we should extend quasisyntax and unsyntax so they cooperate with ellipses. Or build a similar escape directly into syntax and make quasisyntax obsolete.

@notjack If it splits to #f and #f, then it’s a self module path that represents the module currently being expanded—or rather, the module that was being expanded when the module-path index was created. When the expander is done with a module, it shifts all of the self module indexes (for the current expansion) to something else, but IIRC it only shifts those it sees directly in the module’s expanded syntax, so self MPIs in identifiers in syntax properties (for example) don’t get replaced. So there can actually be multiple “self” MPIs floating around at the same time. My guess is that the extra printed stuff is to help disambiguate them when debugging.

hmm

any chance the module-path / module-path-index / resolved-module-path systems can get simplified somehow for racket2? I find them very difficult to use

@notjack I’m not sure there’s much room for simplification from the Racket compiler/linker/loader point of view, given the goal of being able to move compiled code from one path to another (or one machine to another!). I think module-path indexes (or something like them) are a necessary indirection for making that work. But it may be that your particular application doesn’t care about potential rearrangements of the filesystem; you might only care about modules in terms of where they live right now. In that case, you might be able to get away with always immediately translating a MPI down to a resolved module path (or possibly back up to a module path), and you could build wrappers around the MPI-returning functions. I think I did something like that in the implementation of raco check-requires or raco show-dependencies or both, but I don’t remember the details right now.

Can anyone help me with racket/class? What I’m trying to do is roughly:

(new
 (class* object% [printable<%>]
   (super-new)

   (define (my-printer out . _)
     (fprintf out "hello"))

   (public [my-printer custom-print])
   (public [my-printer custom-write])
   (public [my-printer custom-display])))

I feel this should be easy. Somehow it’s not.

I understand that I probably have a lot of misconceptions right now, but what’s the way to do what I’m trying to do? Surely I don’t need to duplicate the definition thrice.

Okay, so the problem is that method != lambda, which totally makes sense. Is there a way to convert a lambda to method? Ideally I shouldn’t need to define three methods, with two redirecting to the other one.

My delayed reaction, waking up this morning, is feeling sad. In my experience, proposals like this are usually foregone conclusions — the only question is “when” and “how, just around the edges”. So my gut is telling me it’s probably that, ergo sad. But. Maybe this isn’t the typical situation, and my gut is misleading me.

(I’m not talking about RFC-like technical details here, as opposed to the desired place to discuss them. Instead, talking about feelings.)

@greg On one hand, I’m happy to see the spirit of “discovering the future of programming by breaking the rules” as Racket always had is still the main motivation here, on the other hand, I oh so love s-expressions, the clarity and expressivity they bring that I have a hard time thinking about using something else for the main Racket experience. I don’t mind about #lang having any syntax they want, as long as it expands to the wonderful common ground that s-expression give. The thing is, the name of the project “Racket2”, feels like the ambition is to have an alternative to s-expression as the main syntax for Racket. The “2” in there feels like s-expressions are not good enough, and should be replaced by something better. I know it’s not the intention, and I know #lang racket is still going to work as always, but that “2” in the name makes me feel insecure, as @gregsaid, that it’s already to some extent fixed in stone.

I think we shouldn’t think about it in terms of whether or not s-expressions are “better”. Instead, we should acknowledge that the rest of the world has some standard notation and that asking them to abandon it is a barrier to entry. So if we can make this language-oriented programming thing work with non-s-expression syntax, then I think we have a responsibility to do so.

In my own experience, with trying to make software products more popular, adopting features of the competition does not necessarily help. Sometimes it even hurts.

It might be useful to look at efforts like New Coke, or Python 3, and so on.

Might be some lessons.

The lessons might be N/A here, but, still useful to know.

To be fair, Python 3 is now more widely used than python 2 and a significant number of packages formally don’t support python 2 anymore

I actually don’t know very much about that, except it seemed to be a pretty prolonged and difficult process for the community.

not saying it wasn’t a mountain of effort to get to that point, but that did happen

yeah I don’t think there’s going to be anything easy about racket2

I’d prefer long, difficult efforts to get the expected benefit, after all the work.

I think there won’t be much direct benefit for the people who already know racket, but there will be benefit for everyone else

I’m also feeling ambivalent, but I have to keep in mind that I’m about 0.5 for 4 in predicting how well I’ll like major changed in Racket based on very early descriptions. So to argue the other side (to myself especially), consider this: Long ago, Lisp decided that syntactic structure was made up of pairs. That’s it. Everything else—like symbols and numbers and so on—only gets to hang out at the leaves of the syntax trees (with rare exceptions). Same with Scheme. Same with Racket. Clojure, as I understand it, decided that syntactic structure would be made up of lists and vectors. And apparently that was palatable, and Clojure is still a Lisp in good standing. So maybe there’s room to explore richer concrete-syntactic structures.

My understanding of the Python 2 vs. 3 problem is that you have to pick one VM or the other. Whatever Racket2 turns out to be, we will certainly insist that Racket and Racket2 modules coexist and interoperate in one VM.

That’s a great point. Even so, it reminds me of two other things. 1. Clojure is AFAICT significantly more popular than Racket, currently. Multiple companies use it, there are jobs, etc. (Admittedly, Clojure folks probably feel it is not popular compared to Java. Maybe they have a case for “sexprs are holding us back”, valid or not.) If Racket had Clojure’s popularity, would this proposal be on the table? It sounded like, probably not.

1. I understood the proposal to be not just “there should be a different default language”. The phrase “change the culture” came up. Meaning, change this syntax for documentation, books, tutorial, blog posts. That sounds exhausting. In my remaining years, do I want to spend time on that for my subset of it? Not really.

(Oh, you say it can be automated? I don’t know, but if that’s really true, then why not have a “show-as” toggle on for the syntax on web pages and maybe tools.)

So, emotionally, I think 2 is the source of a lot of my sadness. I don’t want to rearrange deck chairs but the ship isn’t really changing course.

OK I’ve shared enough feelings and I will shut up for awhile. :slightly_smiling_face:

Thanks! I thought that there will be a better a solution, but that doesn’t seem to be the case.

Thanks for telling me about define/private btw. This is really helpful.

Well, you could write a little macro …

That’s true, but public (or private) is the thing that tells the class to treat a name as a method instead of a field. define/public and define/private just expand into define and public or private.

I think the problem is that class expects each definition marked as a method to have exactly one “external name”.

@greg That’s a great point, and I think 2 will definitely be the most work and the most reward.

I really hope we come up with a way for all my existing scribble defprocs and (examples ...) to render in the new syntax without me having to change the source code.

And now Mattias is being a twit on the mailing list for someone using the phrase “diversity” instead of his preferred phrase “welcoming everyone”. I’d better log off for today. ¯_(ツ)_/¯

Cheers.

I’m seeing fallout from this on Twitter, in case anyone cares.

oh boy

Clojure is thriving. It would be kinda exciting to have a full-on #lang Clojure (no, way beyond Rackjure) on top of Racket instead of going to an infix notation. The parens are a little less and each kind mean something, easy to know the data structures involved by the syntax. In this way, developers who have years of experience in Clojure would find new use cases on top of Racket vs the JVM without disrupting Racket’s 24 and beyond legacy.

I’d love to see some standard, well-supported implementations of other programming languages like #lang clojure, #lang java, #lang python. That would help people learn Racket and either interop with or migrate from existing code.

ever the typographist, eh @mbutterick? (in response to that edit history)

wearing my neuroscientist hat for a moment, I would love to know if there is some bimodal distribution in the programming population between those who prefer highly regular syntax (e.g. Racket) to those who prefer more irregular syntax, and whether it correlates with anything else

slightly in that context, a successful execution of rhombus for me would mean that there would be a button in the docs that I could click to toggle between s-exp syntax and whatever comes next

if we really do it right we shouldn’t have to choose one or the other

though I’m sure there is some impedance mismatch out there not to mention the practical issue of referencing source lines and having to enforce deterministic conversion and formatting to achieve it

You know, if I were Matt, after having over 20 years of working on an s-exp language project and then waking up one day with an epiphany to go infix to gain greater use/popularity, I would reach out to Guy Steele. I think his opinion would be very sobering.

I seem to recall one of the arguments for the Chez Scheme switch was that the language would be implemented in itself with all the accompanying benifits (which have turned out to be true), a syntax change to the core language for … popularity reasons seems to run counter to that, especially since I find it hard to imagine that those 1.2 million lines for s-exp racket code would ever be converted to whatever comes next (barring the mega success scenario)

existing code doesn’t have to be converted, though it would be good to have an automated way of doing so

yes, but then we are back where we started, with an impedance mismatch between surface syntax an core implementation, not as bad as the staggering semantic mismatch between C and Racket, but a mismatch nonetheless

it might be worth it to get people into the mindset

at which point they start making languages, and realize that parens are beautiful

^_^

I don’t think there is a mismatch, and I don’t think the major benefit of using chezscheme as a backend is that the implementation code is in a language similar to racket. The new macro expander implementation is an improvement mostly from a design perspective, not from a surface language perspective.

“Hopefully, this internal restructuring will allow more people to contribute to Racket’s implementation, leading to a range of improvements for end users in the long run.”

https://groups.google.com/d/msg/racket-users/MKJ4Kdy30YY/elZwCG6BAQAJ

evokes the general sentiment I recall

I think the reason it was hard to contribute was because the old C expander and runtime are very complicated with lots of legacy warts and leftover design mistakes, not just because it’s C code

after all, porting to chez involved writing the new rktio C library which is much more maintainable and easier to understand than the old C code implementing the IO system

agreed

Fun fact I discovered with some code analysis tools I’ve been working on: there are 354,707 exported bindings across all successfully compiling modules in the user scope packages currently installed on my laptop

I fixed some issues with standard-cat. Ear tips are now calculated along the vector from ellipse origin to the ellipse point given the width, height, and angle. https://twitter.com/DrDeeGlaze/status/1150993827127107584