morning

i’m evaluating Racket along with Julia for writing desktop gui app…i like that Racket does provide GUI out-of-the-box and although i’m on Linux, just wonder what libs is used by Racket’s gui package under Mac OS, iow. native or something else?

Unix (non-macOS): GTK macOS: Cocoa Windows: win32 or GTK if the env var PLT_WIN_GTK is set during compilation (but the default is win32)

(<https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/platform.rkt#L9-L18>)

thanks. it looks good (for Mac) :slightly_smiling_face:

how i can get names of struture’s field?

f.e. i have (define-struct files-path (include exclude) #:transparent) how extract list of names (include exclude) from struct files-path?

Names aren’t stored in struct values. They are available at compile time though. If you need access to both names and values, I’ll recommend using a hash table instead.

thanks

You could use a struct property to store the field names and use a macro to abstract the pattern. Like:

#lang racket (require (for-syntax syntax/parse)) (define-values (p:fnames pred p-ref) (make-struct-type-property 'p:fnames)) (define-syntax (def-struct-plus stx) (syntax-parse stx [(_ struct-name (f ...) option ...) #`(struct struct-name (f ...) #:property p:fnames (list (quote f) ...) option ...)] )) (def-struct-plus foo (x y)) (p-ref (foo 10 20)) ;; => '(x y)

You can use extract-struct-info https://docs.racket-lang.org/reference/structinfo.html#(def._((lib._racket%2Fstruct-info..rkt)._extract-struct-info)) to get the field accessors and then get the names.

And @lexi.lambda made a syntax class struct-id which can do this https://docs.racket-lang.org/syntax-classes/index.html#(mod-path._syntax%2Fparse%2Fclass%2Fstruct-id)

I think struct-define package is worth to giving a look. It uses struct-info, and it is nice to use the library.

Discussion of Honu on HN: https://news.ycombinator.com/item?id=21721163

use extract-struct-info alone won’t work. You got to make your structs struct-info? by like attaching prop:struct-info with a proper value in your struct definitions.

The point I wanted to make here is fields in Racket’s structs are nameless at run-time. A little extra work need to be done at compile time in order to retrieve those names at run-time.

I think most HN Lisp/Scheme commenters are perfectly happy with defmacro style systems.

What’s with the :woman-facepalming:?

In my case (and I suspect others) it’s the fetishization of sexp syntax.

Oh for mine it’s that people are somehow still using defmacro. I sympathize with fetishization of sexp syntax. :slightly_smiling_face:

Has anyone written a reader for prolog syntax by any chance?

@laurent.orseau presumably both racklog and datalog have one

Thanks Sam. I did took a look in both but didn’t find anything relevant unfortunately. Maybe i looked at the wrong place.

Maybe i should look again

I think it’s https://github.com/racket/datalog/blob/master/parse.rkt

Ah cool ! How did i miss that, it’s even called parse! Thanks again!

I don’t know if you care to hear this, and maybe you can point to part of it and say I’m fetishizing something, but I think prefix syntax has tangible benefits:

• Accessibility of understanding the design, in the sense of a small, readable, and comprehensive language spec.

• Accessibility of having a voice in the design, in the sense of the ability of multiple people to concurrently extend the language spec without incurring a synchronization cost.

Extensions to an infix syntax often fail to be modular because they incur ambiguities, forcing coordinated choices about things like precedence. Putting the operator in a known place (e.g. prefix) reduces the coordination problem to a matter of name collision. For left-to-right, top-to-bottom text flow, prefix does a good job of keeping the context-establishing information (the operator name) visible near the margin.

Some Lisp syntax fans have reasons that I think slot into this utilitarian narrative of mine. Some have reasons that don’t fit this narrative because this narrative isn’t the whole story. Some have reasons that are accidents of history, like wanting a syntax that lets them run old code or read old documentation (which is also, as far as I’ve seen, the best justification of Algol-style syntax). Perhaps some have reasons that don’t hold up at all, and one trek out of their comfort zone will make them fans of some other kind of syntax instead.

Fetishization of s-expressions? I see the cult-of-personality sort of appeal showing in some little pieces of that thread, but the rest looks like people expressing their practical needs as well as they can to whoever will listen.

The Honu paper is all about making non-s-expression surface syntax extensible and modular. My facepalm was because 99% of the comments didn’t seem to understand that.

That’s the same topic, just expressed in such a way that you can take non-s-expression syntax as a foundational premise instead of spending any effort to justify it. Sometimes it’s fine to collectively agree to a premise to bring the discourse to a deeper level, and sometimes the premise isn’t something that deserves that kind of free pass.

Anyway, in this case the original title of the submission (before dang renamed it) was “Honu: Lisp with Algol Syntax.” So I think a lot of the comments are in response to the interests of the person who submitted the paper to HN, not a response to the paper in a vacuum.

I understand why the responses are what they are. I’m just disappointed.

what’s the easiest way to read a racket file in as a simple s-expression?

@dan.ml.901 just call read — it might be easier to use file->value though from racket/file. Note that you have to set a couple parameters if you use #lang in the file — read-accept-reader and read-accept-lang.

Thanks! (read-accept-reader #t) worked