Is the grammar for https://docs.racket-lang.org/reference/lambda.html?q=lambda#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._lambda%29%29\|lambda loose on purpose? (simplicity?) It allows for mandatory positional arguments even after optional arguments
I feel like this must have been asked several times already…
that sounds pretty bad — perhaps it’s just an oversight?
I suppose the grammar for lambda could be divided into two cases: one for at least one optional arg, another with no optional args
Idle thought about the earlier conversation surrounding make-list: is there a function for making a sequence of N copies of a value? Then you wouldn’t need to make this constructor for each collection type (since it’s a pretty uncommon use case) and you could just do (sequence->mycollection (in-copies-of 'foo 5)) instead.
I wonder where the use case comes from. It’s like that in Common Lisp, too. The only use case that comes to mind is doing some kind of zero-filling to prepare for some destructive changes later on.
Can I define a C-macro using de FFI in Racket? I need to define a C-macro before a header is included. How can be this achieved?
That reminds me, I need to fix the grammar for my lang’s lambda, as it allows optionals anywhere, too.
The C ‘macro’ system is kind of terrible (so easy to introduce hard-to-debug bugs). If you have control over the C source file, I would play around replacing C macros with C code generated from scribble. Not sure how much of an enhancement that would be, but at least it would be fun :)
Or maybe you mean that the C file contains a macro and you want to tell the ffi about the macro? My guess is that you don’t need to, as I think C macros are expanded before the ffi binds things(?)
I’ve definitely had to do it occasionally, with both immutable lists and mutable vectors. Not sure I remember what the use cases were though.
Im using GLFW and Vulkan, and the glfw reference says that i need to define a macro before include de glfw headers to use vulkan
I’m not sure but then maybe you need to write a new C file
The bindings of glfw and vulkan are available via the package-manager of DrRacket. Maybe, if I find the c files of glfw I can insert the macro.
Cancel that, i can’t. XD
Seems that i dont need that macro after all. hehe. Thanks anyway!
Non-problems always have the best solutions!
I’m trying to define a syntax-class that uses some fixed value but I appear to be lost between phases. Racket keeps saying that unsaved editor:15:28: some-value: unbound identifier; also, no #%top syntax transformer is bound in: some-value #(364 10) Any clue?
@laurent.orseau you need some-value to be for-template
Also, I think you need a quote around fml.name
Thanks a ton! So basically, some-value can’t be inside the same module as macro because there’s no begin-for-template?
IIUC, yes
You could lift everything, except some-value, using begin-for-syntax. But, that could get messy.
it might be possible to create begin-for-template, but I don’t know how. The easiest way might be to expand to another module + require, but then things might get weird.
@kellysmith12.21 Yes, but I’m working with an existing module that doesn’t do that.
Ah, I see.
(define a 43)
(define b x)
...
(define a b 43) ;; did you intend (define b a) above?
Yes. I’ll fix it.
Is it clear from the documentation of datum->syntax that (datum->syntax ctx stx) is simply stx if stx is a syntax? already?
> Converted objects in v are given the lexical context information of ctxt and the source-location information of srcloc. If v is not already a syntax object, then the resulting immediate syntax object is given the properties Because the second sentence specifically calls out what will happen to syntax properties when “v is not already a syntax object”, it gives an impression that the first sentence is a general statement which includes the case when v is a syntax object. But that doesn’t seem to be the case…
> For any kind of value other than a pair, vector, box, immutable <https://docs.racket-lang.org/reference/hashtables.html?q=datum-%3Esyntax#%28tech.hash.table%29|hash table>, immutable https://docs.racket-lang.org/reference/structures.html?q=datum-%3Esyntax#%28tech._prefab%29\|prefab structure, or <https://docs.racket-lang.org/reference/syntax-model.html?q=datum-%3Esyntax#%28tech.syntax.object%29|syntax object>, conversion means wrapping the value with lexical information, source-location information, and properties after the value is https://docs.racket-lang.org/reference/reader.html?q=datum-%3Esyntax#%28tech._interned%29\|interned via https://docs.racket-lang.org/reference/stxops.html?q=datum-%3Esyntax#%28def._%28%28quote._~23~25kernel%29._datum-intern-literal%29%29\|datum-intern-literal. I suppose the prose could tell that a syntax object converts to itself. > Converted objects in _v are given the lexical context information of _ctxt and the source-location information of _srcloc. If _v is not already a <https://docs.racket-lang.org/reference/syntax-model.html?q=datum-%3Esyntax#%28tech._syntax._object%29|syntax object>, then the … This hints that nothing happens to a syntax object.
I think the text could be a little more explicit - or maybe just an example below to clear things up?
It would be help if the very first sentence/paragraph were something like: “If v is already a syntax object, v is returned unchanged.” End sentence. End paragraph. Insert existing docs after.
Maybe even an itemlist to emphasize that everything to follow only applies to the “else” case where non-syntax is converted. i.e. Two item bullet points, just like the two branches of the implementation’s topmost if expression (assuming that’s what you’re saying is the impl, literally or conceptually.)
I mean, I think the existing docs are clear in the sense that they’re correct and complete. But I can also imagine glancing at them too quickly and thinking datum->syntax could be used as a swiss-army knife to update lexical context, syntax properties, and/or srcloc for some syntax … but it can’t.
Is there such a swiss-army knife for syntax updates?
Maybe replace-context ?
(datum->syntax something (syntax-e stx) something something)
Hmm, swiss-army knife probably should work when stx is not a syntax object.
I’ve noticed that syntax-parse will parse a literal as an expression, sometimes. This has been the cause of a few buggy macros, which was resolved by reordering alternatives in a macro. Since, if I declare an id as a #:literal, I never want it to be parsed as an expression, is there a way to convince syntax-parse never to parse it as an expression?
@laurent.orseau I found the cause of the two broken lines. I wanted the grey box around the code to have a width, that matched the code, so I used width: fit-contents . This causes Chrome to break the lines for smaller screens/pages. If I instead have no rule, it doesn’t break the line. But … now extra long comments doesn’t extend the width of the grey box, so the “stick out” to the right…
Oooh - shiny. It seems adding a white-space: nowrap in combination with width: fit-content works.
@kellysmith12.21 example?
Given this definition of foo, if the user writes (foo 1 my-lit), then foo will parse my-lit as an expression, and my-lit will throw its syntax error. However, if the two syntax-parse clauses are swapped, then foo will correctly parse my-lit as a literal.
It would be difficult, I think. Ordering is important because you can have side conditions and other stateful stuff. If the grammar is more limited, then that might be possible, but would also limit expressiveness.
I think you might also need to dance on foot under a full moon with a pineapple on your head to make it work
I can imagine getting surprised by that; I bet I’ve had similar bugs, if not that exact bug, many times. On the other hand it fits my intuition for pattern-matching, generally? With syntax-parse, or match, or X, I would expect I might need to order the more-specific match pattern first, before a clause that matches more generally. IIUC my-lit is more specific than e2:expr — that specific literal is more specific than “any expression (anything that’s not a #:keyword)”. So I think this makes sense, in hindsight. But, yeah, for me anyway, “debugging” is just an antonym for “hindsight”. :slightly_smiling_face:
@kellysmith12.21 Does it work correctly regardless of clause ordering if you add a cut? (_ e:expr my-lit ~!)
syntax-parse isn’t like match: it does try to use the pattern that makes the most “progress”, in some vague sense that I don’t fully understand. My guess is that it does actually try both patterns, see that they both match, then go with the first one because there’s no cuts to indicate priority and the progress ranking is mostly used for deciding which failing pattern to mention in an error message.
This is not true for syntax-parse, see https://docs.racket-lang.org/syntax/Parsing_Syntax.html
Even with a cut, the clause ordering matters.