The package server complains about undeclared dependencies on the Urlang package. I must be missing something in my “info.rkt” file - but what?

The last lines of the build log contains a list of packages missing:

https://pkg-build.racket-lang.org/server/built/deps/urlang.txt

However some of them are already listed in the info file.

https://github.com/soegaard/urlang/blob/master/urlang/info.rkt

An example is “html-writing”.

build-deps are not deps that can be zos, they’re deps that are only needed to compile urlang to zos but aren’t needed at runtime.

If you need the dep at runtime, it still needs to go in deps.

The package system dependency checker will tell you where it thinks you need to put the deps—if it says “mode: run”, it should go in deps, and if it says “mode: build” or “for build”, it should go in build-deps.

Thanks! I wonder where I got the misconception of build-deps = zo-files.

Is there a way to make a local macro for syntax-parse? That is, a macro that you could call within a template inside a syntax-parse. I thought I read somewhere how to do it, but right now I’m not finding a web page about it.

I tried enclosing the define-syntax within begin-for-syntax, with no luck. Also tried it inside as well as outside the define-syntax that encloses the syntax-parse.

I’m not entirely sure what you’re asking—do you mean a macro that you use in your expansion, or a macro that you use at phase 1 (that is, at compile-time) to produce the macro’s output?

A macro that I call in the expansion. Essentially, a “subroutine” macro.

If you just define the macro as usual, outside the define-syntax, it should just work.

I thought I tried that, but I’ll double-check right now…

Or if you really want a local macro, then perhaps use let-syntax.

Btw - I figured out where the misconception stemmed.

The manual has the following sentence on build-deps:

“build-deps — like deps, but for dependencies that can be dropped in a binary package, which does not include sources;”

I misinterpreted “dropped in a binary package”.

@lexi.lambda Ecch! That worked. Thanks! I must not have actually run that attempt. :wink:

I see now that it means “can be omitted from a binary package”.

Yes, I think updating the wording to that would be a good change!

I can’t find the scribble file corresponding to http://docs.racket-lang.org/pkg/index.html

@soegaard2 https://github.com/racket/racket/blob/master/pkgs/racket-doc/pkg/scribblings/pkg.scrbl

Thanks. Change committed.

Thanks!

How can you get the effect of #:auto-nested-attributes and still use #:attributes? Sample code here:

You cannot use them together; the point of #:attributes is to specify the attributes explicitly. You can, however, specify nested attributes explicitly in #:attributes by writing something like #:attributes [foo.bar].

OK, thanks. I didn’t see how #:attributes could address nesting.

Do you know the reason why nested attributes aren’t simply propagated as normal behavior?

I’m not totally sure (@ryanc would know), but I think it’s hard to compute them properly when syntax classes use other syntax classes defined later in the same module.

(Or if syntax classes are mutually recursive, for example.)

OK. Sometimes it clarifies a lot to know why some element of a language is defined the way it is. And sometimes not. :wink:

neat syntax-parse trivia that I didn’t realize until years of using it: if you match something using :class instead of foo:class, then all of the attributes of class will be bound directly - e.g. instead of foo.some-attr you can just use some-attr

I find this useful sometimes when making one base syntax class and multiple extra syntax classes that each have the same attributes as the base but also some extra stuff

@notjack Whoa! That might enable me to simplify this now-large macro quite a bit.

(because binding them directly means you don’t have to turn id.attr into attr with a bunch of #:with clauses to get the #:attributes parts to line up right)

@notjack I think you should almost never use that feature

but sometimes it is handy

the syntax class definitions and #:attributes thing is the only use case I’ve come up with so far

I use it semi-regularly. :)

gasp!

grep tells me 12 uses of that feature inside the Hackett codebase!

@robby Is there a reason Check Syntax doesn’t use sub-range-binders information when drawing the ? arrows to identifiers inside syntax templates?

is it possible to indent a racket file from a racket command-line?

It’s possible… but I don’t know of an easy way to do it. :)

I have a scenario where people who use Visual Studio Code are editing racket — the language plugin does syntax highlighting but basically nothing else. It’d be great to run Racket as a language server and get DrRacket features

Oh. I was going to suggest something like (system "emacs -eval '(progn _elisp_that_opens_the_.rkt_files_and_does_the_indent_command_)'" :stuck_out_tongue_winking_eye: Seriously, I think Jay has a Racket LSP project on GitHub.

yeah that would be a great stopgap….

Hmm there’s this https://github.com/jeapostrophe/racket-langserver

But also this: https://github.com/theia-ide/racket-language-server which specifically mentions indent

ah, perfect…

And I see at least 3 other Racket LSP projects, so idk?

for structs, is there an equivalent property to prop:procedure but that allows you to use it as syntax?

If I understand your question correctly, it’s also prop:procedure. If you have a struct defined at phase 1 with a value for prop:procedure, and a define-syntax binding that is bound to an instance of that struct, then it will call it as a procedure when used as a syntax transformer.

If you mean you want to be able to do (struct foo ()), then (define x (foo)) and have (x) behave like a macro invocation, the macro system just can’t do that—since macros are expanded at compile-time, it needs to know statically which identifiers are bound as macros.

You may know this already, but just building in a fresh directory with PLTCOMPILEDROOTS=compiled/@(version): didn’t trigger the problem for me.

Maybe a bug?

right, yeah I’d like to be able to do the 2nd one… (struct foo () #:property prop:syntax (lambda (stx) (syntax-case stx ...)))

https://docs.racket-lang.org/hackett@hackett-doc/ has an exception

@dan.ml.901 No, you can’t do that. Macros are not (and cannot be) first-class values, but structure instances are.

@macocio It should be fixed when pkg-build runs again tomorrow.

Alright @lexi.lambda, have you ceased working on hackett? Last commit 3 oct

I have not had the time.

@dan.ml.901 maybe (begin (struct foo () #:omit-define-syntaxes) (define-syntax foo (lambda (stx) (syntax-case stx ...))))

note that won’t let you use foo in match or other places that expect a struct name

but you can fix that by using prop:struct-info

@samth I understood @dan.ml.901’s request as asking for instances of the struct to serve as transformers, not the struct type name.

actually the type name could be enough… although I do currently use the structs in match cases as well :confused:

I have a workaround, tho

If just the name is okay, what @samth suggested is possible—you can use prop:struct-info to recover support with match.

ah I see… that’s pretty cool