Matthew Flatt wrote on 05/07/2015 02:44 PM:
I have no problem with these names --- the `scribble` exports are
unlikely to ever collide, since we rarely resort to capital letters ---
but I can't help thinking that the language of the metadata should
specified explicitly.


Regarding `#lang mcfly racket/base`, an additional reason I want to do three-semicolon comments is to *not* have each package depend on the documentation package. It's practically simpler sometimes. (I'm not the only one who doesn't fully like the dependency I had on the `mcfly` package; I've seen multiple other people copy my package code and strip out the McFly `doc` forms, so that they didn't have that dependency.)

If someone else wants to put something other than embedded Scribble in three-semicolon comments, the fact that I'm using three-semicolon in a particular way won't break them, and they won't break me. Or, if someone in the future wants to scrape my three-semicolon stuff in the future, nothing's stopping them, and I'll even give them a small package to do that. I think I understand what you're saying about languages, but in this case, I'm pretty sure how I want to do this, and I'm comfortable with the longevity of the pragmatic simplifications right now.

(Aside: I think the main advantage to the dependency on the `mcfly` PLaneT package was actually sneaky advertising or self-propagation. McFly is not a good example, but let's say there's a non-core package X that is used by various other packages. When a person uses a package that uses X, directly or indirectly, then documentation for X was added to the person's Racket documentation page, for them to stumble upon through documentation search and browsing. Then, the theory goes, that person is then more likely to add a new use of that package in packages that they write. So, if we get an ecology of lots of small packages using lots of small packages, and package X depends directly and indirectly on packages A, B, C, D, E, and F... the package X author doesn't even have to mention in documentation all those supporting packages (they often wouldn't even know all of the indirect ones), but the supporting packages still get a small bit of fame and propagation advantage each time. This is decentralized, with no authority declaring X to be a good package to do the things that X does, but just the little documentation-adding mechanism gives the memetics a boost.)

Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to