Yes. I tried the link and the first thing I thought was ‘why are there ASN.1 tools here?’ - but the answer is that an ASN.1 parser generator is a parser - it’s just not the sort of parser I was looking for.(though I may need to write a MARC 22 (MAchine-Readable Cataloging) parser. Getting the wrong thing, or choosing the wrong term is the scaling problem that all folksonomys suffer from! Adding descriptions to terms may help(SO/Wikipedia), by distinguishing between general terms like ‘parsing’ that may include packages that support parsing, from more specific terms like ‘parser’ or ‘parser generator’. Another option is mandating the use of a controlled vocabulary with or replacing the folksonomy terms. Both would require effort on something that isn’t necessarily interesting to Developers/Programmers/Computer Scientists. A immediate action that everyone can take would be to add an issue or PR on the repository to fix tagging issues. I’d be interested to know how other languages address this? I would be interested in how NPM, Java, Haskell, Ruby, C++, Python, Common Lisp & Smalltalk address this issue?
@notjack Oh wow. Thanks. I didn’t know that. Not-knowing this, reminds me of not-knowing (once upon a time) how to produce a @ in at-expr syntax: @"@".
In both cases, there’s a prefix that means “treat the following as an ordinary thing”. A kind of unquasiquote, like ,. Here @ or .... But commonly it’s used only in certain ways. So people like me — who tend to learn by example more than I probably ought to (vs. RTFM) — tend to miss the other ways.
I suppose a difference is: With ... ..., that tends to be the only example people know. Whereas with @"@" it’s sort of the opposite, it’s the only example people don’t know. :smile:
Uh, that’s probably not quite right. ... is a kind of quoting not unquoting? I guess I still not-know a lot.
waves hands and mumbles something about quotescaping
wanders off in search of coffee….
@sepand.meenu has joined the channel
Has Racket seen much adoption in industry?
When I hear about it being used for a project, it’s almost always in academia
I think the answer to “has it seen much adoption” is definitely “no,” but that isn’t to say it has seen no adoption, or even no adoption for nontrivial things.
Right, I assume at least some folks must be using it :slightly_smiling_face:
I guess one of the bigger success stories people often talk about is its usage for internal tooling at Naughty Dog, but I know various people are using it for more run-of-the-mill web stuff, too. It’s definitely uncommon, though. :)
As Alexis said, it’s not a long list, but a list is here: https://github.com/racket/racket/wiki/Organizations-using-Racket
Grapevine I’ve heard of at least two FANG companies using Racket in various ways, but I doubt in a broad, deep, super “strategory” way.
Anyway, please use Racket commercially and add your company to that list! :smile:
I’d be interested to do so, though I don’t know Racket very well at all, and my colleague can’t stand looking at s-exprs, so it’s unlikely…
@mbutterick they’re two ends of the same place channel
ie, write to foo, read from bar and the reverse
yes
no it’s not like that
it’s like the big red cold war phone
it’s bidirectional, but one of them is in the white house and one is in the kremlin
yes
(although, to complicate things a bit, it’s not really into/out of the place, but that channel. you can send the place channel over a place channel, and then you could use it the other way around)
Huh. Now that I think about it…. why have two names at all?
What couldn’t you do if you didn’t name the ends separately and only bound one name?
place is like spawning an entirely new Racket process, and it dynamic-requires a generated submodule. The original name isn’t in scope in the child; it isn’t like fork.
That seems mostly unrelated to the surface syntax though. But now I remembered that (place id ...) is an expression, which is the real reason you need two names. Expressions don’t bind variables for use outside themselves.
Yes, (place id ...) is like (lambda (id) ...).
A (define-place id body ...) form would work fine
I suppose, but I think having the same name bound to two different things would be confusing. In the parent place, id is bound to the child place itself, which also happens to be a place channel. In the child place, id is bound to a place channel that communicates with the parent. Those two things seem to deserve separate names.
I’ve barely used places though so a module-level (place ...) expression might not make sense
Now I want to see how real racket projects tend to use places. Even more reason to get around to building a racket API usages database of some sort.