There are several different issues here, but I'll try to touch on a few of them.
On Sat, Aug 4, 2018 at 9:33 AM, Alex Gian <alex9...@gmail.com> wrote: > Say I have written a little library, perhaps of various maths utilities. > … I have also made this an installable #lang, lets's call it '#lang rat' > (for rational, of course) by adding the line > > > (module reader syntax/module-reader rat) > > > to the top of the main.rkt file, and also > > (provide (all-defined-out) #%module-begin #%app #%datum #%top-interaction) > > This already brings up several different problems, ranging from trivial to significant: - On a very minor point, I think `rational` would be a better name than `rat`, both in keeping with the Scheme tradition of using real words and because of practical namespace issues: if your package uses the `rat` collection for rational numbers, it could conflict with another package that might want to use `rat` for small rodents. - It is a matter of judgement to determine when a library should be usable as a #lang, but my advice would be to avoid it unless there is something you want to do that is possible for a #lang but not for a module imported using `require`—and I don't see any signs of that. If you don't provide a #lang, you can ignore the next bullet point. - Writing `(provide (all-defined-out) #%module-begin #%app #%datum #%top-interaction)` probably doesn't do what you want. Using `(all-defined-out)` exports only those things which have been `define`d in that specific module, not things imported with `require` or from the module's own language. In your example, a module in `#lang rat` would not be able to use `define` or `lambda`, and, if the client module uses an unbound identifier, a syntax error will be raised blaming the `rat` implementation for failing to provide a `#%top` binding. Most language will want something like `(all-from-out racket/base)` in their `provide` statements, perhaps using `except-out` to replace some specific bindings with your own versions. I want the user to have to (require rat/polynomial) [but to be free of > having to specify the file-path, which may be intricate]. Only the name > should be necessary. If I've understood correctly, my polynomials.rkt file > will have to be made a module (or a submodule). > When you say "my polynomials.rkt file will have to be made a module", I wonder if you realize that any file that begins with #lang is already a module. For example, a file that consists of: #lang racket/base (provide x) (define x 1) is equivalent to a file containing the single s-expression: (module inferred-from-filename racket/base (provide x) (define x 1)) If you actually do mean that some of your code is currently in files that are not modules, you will almost certainly want to put them into modules straight away. As long as files start with #lang and your package is installed, `(require rat/polynomial)` will import the module that lives in a "polynomial.rkt" file in the same directory as the "main.rkt" file imported by `(require rat)`. Furthermore, this is going to become even more important to me soon, as I > have cases where I have to 'eval' expressions expressions inside syntax, > and that syntax is not in the same file as my evaluation environment. I > know that if I have the handle of the module I can do (module->namespace > 'polynomial) and then use that namespace as the second parameter to eval, > but how do I get the module handle in the first place? > You almost certainly do not want to use `eval`. There's a post on the Racket blog that goes into much detail on why `eval` "should be avoided": https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html The takeaway is that there is almost always a better mechanism (unless you are, say, implementing DrRacket, where dynamically evaluating arbitrary programs really is exactly what you want to do). I say this from some personal experience: when I was new to Racket and trying to figure out how to serialize structs, I hacked up a monstrosity of a serialization implementation based on `eval` and `print`, which I used for months before I discovered that `racket/serialize` had already solved this problem reliably. Because of that, I know a little bit about functions like `namespace-anchor->namespace` that start to address the problems you're finding, but my advice is that you should describe the problem you're trying to solve by using `eval` so that the community can point you towards a better solution. Overall, I would suggest that you try to find some small Racket package and look at the way its implementation is organized. I think that will help to clarify some of the confusion. -Philip -- 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.
