I just misread your message, and looked at your code again. I see what you were getting at, Yes this looks pretty great, avoiding Fixnums =)

Just discovered that racket-mode supports “check syntax”. Thanks @greg!

Is there a place to see the status of: http://pkgs.racket-lang.org\|pkgs.racket-lang.org ?

If you click to the left of “Package” (in the blank space) you can sort the packages, so the new ones are on top: https://pkgs.racket-lang.org/

It seems all newly updated packages fail.

The note on the bottom: Questions? Comments? Bugs? Email or .

@jeapostrophe u on slack?

is it possible to know how many places refer to a variable? I’m curious if it’s possible to have such optimization — have standard functional update (like map / struct-copy) if the data structure is refered to from multiple places; but use in-place mutation (like vector-set!) if the data structure is refered to from single place only.

so in effect from user side it’s still functionally transparent, but with possibility of performance boost

I was using Atom, but switched to vscode a couple months ago, because I was looking for better langserver support. It does feel a bit snappier than Atom and I feel like it handles “projects” better

I don’t want to use VScode - I just want DrRacket to look as good without sacrificing usability for new users

I agree. If DrRacket was more general and could deal with Java, Python, etc. I would use it more. But I don’t think that is necessarily where DrRacket should go.

For polyglots it makes more sense to use a racket-mode in the editor of choice.

The popularity of VS Code suggests it would be a good move to make a proper racket-mode for it.

I’m confused - does racket have a language server like rust that emacs (and other) editors can call?

There are two on the package server. I haven’t tried them. But Racket is not listed as a supported language on the VS Code page. https://pkgd.racket-lang.org/pkgn/package/racket-language-server https://pkgd.racket-lang.org/pkgn/package/racket-langserver

I tried it with Atom a while back. I haven’t tried it in VScode yet.

@jeapostrophe is the maintainer iirc

er is a maintainer

the racket-langserver package cleverly reuses the existing DrRacket apis to do it’s work

https://pkgs.racket-lang.org/package/racket-language-server seems to be the one associated with theia-ide

The Microsoft ‘language server protocol’ is never going to provide the functionality that DrRacket offers

No it is just a baseline. But I believe it is extensible in the in the same manner as Emacs.

I like the arrows. They really help when spelunking through other people’s code..

I like the arrows too. But check-syntax in racket-mode in Emacs does the same job. It changes the background color of the identifiers instead of drawing arrows.

Maybe a DrRacket extension to support LSP? I’m mostly interested in a path to DrRacket looking as good as sonicPi or VScode - DrRacket is the ‘face’ of Racket.

That was probably me. Let me know if you’ll be around campus.

What sort of class are you looking to take?

I chose that picture on Shutterstock.

I have not measured that recently. I’ll try it out.

Most of that is packages that have bad metadata being treated as permanently “new”

Which should probably be changed

Yes, it’s still that bad.

Okay. Thanks for checking.

Is it bad only for the general array case - or also for matrices?

Probably both

https://news.ycombinator.com/item?id=20623303

those mailing list threads likely claimed more than a few members of the community :confused:

I’m a little surprised at the general level of angst… and I consider myself a moderately sensitive person.

I mean, it was sort of like ripping the roof off the house for someone who finally felt at home having found the nice, regular, reasonable world of s-exps

or at least the imagined threat of such a thing

which is inevitably far worse than any reality

Well I am one of those people. But I also have wandered away and spent time focussing on Haskell, OCaml, Coq, and Agda, among others. And I’ve watched Racket evolve, not always in ways that I would necessarily have chosen, but that’s the nature of things done by people other than me!

it seemed like a lot of people were asking “is everything I’m used to going to go away?”

the way I look at it at this point is that any technology that will satisfy LOP will probably have to be good enough that I can convert everything into s-exp syntax anyway, which is probably ultimately a win, if you can figure out how to create ‘virtual’ source lines

@tgbugs out of curiosity, what do you imagine you’d be converting? source code of libraries you use? code written by people working on a project with you? example code in docs? all of the above, plus more?

I’m not optimistic about Honu-style macros for non-s-expression syntax, or any system where “converting into s-exp syntax” would require running the macros to reveal the tree structure, including arbitrary code

barring Alex’s concerns, literally everything, of course you could write a horrible infix expression that expanded to a massive sexp

but I don’t think we know the frequency with which those kinds of macros are actually used/written

I am optimistic however that some niceties such as infix without a precedence system, such as what Pyret does, can be added in a way that wouldn’t require running the macros to convert to s-exp syntax

Other languages have metaprogramming - albeit not as convenient as Racket’s. I don’t see the harm in trying to push the boundaries of what is currently possible.

> explicit is better than implicit > has operator precedence rules > just python things

@tgbugs if there was a racket package you wanted to use, and the source was implemented in #lang rhombus (or whatever racket2 ends up being called), would you clone the repo and convert the source code of the package to #lang racket before using it?

@sanchom yes, the reason why I’m not so worried at the moment is because the core team seems to have set very high expectations for what acceptable would be

@notjack my hope would be that there would be something like the stepper or the expander that could create a virtual view which I could edit and then run backwards back into the original rhombus with my changes

if it ends up being honu style, then that would seem to imply inverse enforstation or something like that

so, perhaps a pipedream

but if the threat of converting all the documentation to some future trapezoidal language is going to be made real, then I interpret that as the ability to do full roundtrips in both directions

the implication being that if I can figure out how to write #lang python using trapezoidal technology, then I never have to look at python again and can port my whole codebase in one shot

again, pipedream

@tgbugs If third party library docs were easily toggle-able, but third party source code took more work to convert between syntaxes, how would you feel about third party packages implemented in non-s-expression syntaxes? Like say we had a way for the racket package system to act as a mirror of package systems from other language ecosystems, so you could use raco pkg to install haskell libraries from Hackage and use them with a #lang haskell (and do similar things for other languages / package systems like python + PyPI or javascript + npm). Would you feel uncomfortable with transitive dependencies on libraries implemented in these languages?

I tend to be conservative when it comes to dependencies, especially when it comes to depending on another language that I am not proficient at, I will do it, but if I can’t easily fix it myself, then it is quite a bit less useful

now, having everything operating under the same runtime reduces the cost of that by 50%

(or something like that)

however I worry that in the core it can lead to a schism in who is willing to contribute to what

I have spent a lot of unhappy time working with rdf, and the serialization format and tooling matters a whole lot, and leads to major barries to entry and contribution

that is a kind of massive exaggeration of the potential situation

silly things like “I can’t use paredit in this file” or “in order to use paredit in this file I or someone needs to write a bunch of code” and be major stumbling blocks for existing users

the threat of having to change a habit can often force people to search for a more stable place where they won’t have to change them in the future

there’s definitely a big tooling gulf between “you can write code in any language” and “writing code in any language isn’t torturous”

Do you have any suggestions for a list of minimum tooling requirements for a surface syntax? Such as “must be able to use paredit or something paredit-like”.

I do, I think I mentioned them in passing in one of the github issues

but they essentially amount to being able to locally apply a rule to select the equivalent of an s-expression

meaning that I don’t have to resolve identifiers or expand macros

to figure out where boundaries are

‘local’ meaning “if I plop down a cursor anywhere in the file I only need to invoke read to know where forms begin an end”

the reason being that if you had to resolve identifiers then a source file that doesn’t compile would not be structurally editable, you mean?

exactly

robustness to bad/incorrect/invalid state of the surface syntax is critical

so, “must be able to use paredit-like editing on files with compilation errors” vs just being able to use paredit-like editing

its like, imagine trying to spread peanutbutter if the coefficient of friction were to change depending on the exact angle of the knife and the temperature and the speed

ya, paredit like is a fair charachterization

though if you include slurp and barf, I have this thought that you basically wind up back at s-expressions

I’ve wondered for a while though if there’s ways for macros to communicate that syntax errors have a “blast radius” and only affect some subtree of syntax or some small part of the file, so compilation can make more progress after encountering one error. That way things like type checkers could raise multiple independent syntax errors and you wouldn’t have to fix them one at a time, recompiling between each one. I think if we focus on the constraint of “structural editing with broken files” but don’t assume that means a Honu-like approach to parsing and binding is impossible, we might develop some really interesting approaches to dealing with macros and broken files. Which could even improve plain old’ typed racket, rather than just racket2.

definitely possible, I have been playing with something using syntax/warnings for things it was probably never intended for to produce something similar for my own work

also effect locality can also be defined interms of the call graph

I do something similar for validating dataset structures using an awful hybrid of json schema and python exceptions

you can store all the errors or forms that have been marked as in an errored state and then raise at the end of the module

looking for the code where I do that ..

Thinking about more constraints: I use binding-aware navigation features of my IDE at work all the time, so I’d really like to support those too. Stuff like “jump to definition”, “jump to next/previous usage”, “jump to next/previous definition of same kind (method/class/variable/etc.)“.

There are a lot of things I would like to see in DrRacket besides aesthetics of the GUI. Having to install a paredit mode separately kind of bugs me. As does not having the same level of formatting tools that Emacs does. I almost always use racket-mode in emacs for these reasons.

So let’s call this dichotomy “binding-aware navigation” vs “structural navigation”. The latter I would absolutely require to be possible with broken files. The former… I’m not sure? I’d like it to work still, so things like type errors don’t make it impossible for me to move around via bindings. But I’d probably be less bothered by that not working.

“dichotomy”? You want both done well and they complement each other

I have 2 parts of the system being used to do different things

Right but they’re definitely very different categories with different requirements, and I don’t know of any editing features that simultaneously fall into both camps

but basically it amounts to trapping errors and feeding them to syntax-warn, which you would instead feed to a module level structure during syntax phase, and the other is to use syntax-local-lift-module-end-declaration

to move those to the end and trigger them

I think

I may not have gotten that full part working, I was trying to make the require/provide system do evil things

but in principle it should be able to be used to provide errors

with regard to binding vs structure, I wonder whether Guido’s assertion that “code is read more often than it is written” actually means

“most languages are such a pain to edit/refactor that we usually just read them instead of trying to improve anything”

which would imply that perhaps the purely syntactical is an interface for editing, and the easier it is to change a language in the way you want, or to transition from state a to state b, the better the interface

re: syntax-warn: oh cool! I didn’t realize anyone was actually using that. I haven’t touched it in a while.

I was trying to implement highlighting in DrRacket for it because it would make for a very simple demo of error detection and reporting back to the user over a whole file, but I couldn’t figure out where to hook in

gotta say this thread really kills my confidence in things more than initial announcement

makes me want to give chicken a proper try this time

@nma.arvydas.silanskas Why?

the confidence part, not the trying chicken part