
@quangluongtm has joined the channel

@joshua has joined the channel

Hey Everyone! I was wondering if there was a way to run full swindle on the cli. I can configure drracket to run full swindle and on the cli I can put #lang swindle
at the top of my file, but there’s still some things I can’t run on the cli. Is thee something I need to add in addition to this?

Does racket -I swindle
do what you want?

I appreciate the response mflatt! No, this doesn’t seem to fix it :confused:. I’m not familiar with racket (just started using it) and I can run most swindle files correctly as long as they’re identified by #lang swindle
, but I just recently tried to run a file and it will only run if I select full swindle in drracket, it won’t run on the cli

Can you show in more detail what you’re trying and what you hoped would happen?

Yea sure, this is for a cs class and all the files are public on the internet so I’m sure it’s fine to upload them here. I am trying to run this file from the command line:

Did you add that #lang swindle
line yourself?

Yes, I did

Using #lang
means “this file is a module”, but the original program was meant to be a sequence of top-level forms. So, don’t add #lang swindle
.

If you start Racket with racket -I swindle
, then you can use (load "cs230.ps2.scm")

Or you can use racket -I swindle -f cs230.ps2.scm

Thank you so much!! I’ve been struggling with this for a solid hour. Now I can do my assignment haha. If I get a good score I’ll make to lyk haha.

@jfqueralt has joined the channel

I am not familiar with one. I found this repository intriguing, but the only Racket in it is the scribble files: https://github.com/namin/propagators
The closest thing I can think of would be solver-aided programming which is very strongly supported in #lang rosette
.
Do you have a use case in mind? I am working through Sussman’s book and am tempted to attempt creation of a propagator library in Racket, but I am not sure what it would support or how long that would take.

The use of syntax parameters makes it easy to write abstractions over anaphoric binding/usage macros that implicitly inherit those anaphoric interactions. Personally, when I write a macro that has anaphoric interactions, I want to be explicit about it, as seen in the examples the paper is correcting for. I think of syntax parameters as a source of abstraction leaks.