Thanks for the reply Phillip - re rat: just humour me on this, it's a temporary name anyway, until the full deployment of the project, which incidentally, is the Racket port of scmutils
- following from the above, so yes, it will *certainly* have to be a *#lang*, no questions there. - re whether the 'provide's work. They do. In trying to keep the irrelevant stuff out of my question, I neglected to mention that I also provide racket. It works. I have been using it like that for weeks and testing all sorts of stuff. I sort of mention that I had no problem up to that point. - re whether I realist that #lang rat is already a module. Yes, of course I do. The thing is, I need modules within that module to be modules too. > 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)`. I would like to be free of the constraint of the directory location, if possible. If not, never mind, but it seems a bit limiting and outside the spirit of Racket. It's just that the current directory structure is not laid out that way. > You almost certainly do not want to use `eval`. Actually, I bloody certainly do not want to use eval, especially inside a macro. Unfortunately the author of the original software has, so I have to find a way to work around it! ;) > 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. Now you're talking. I'm not tied to any particular way of doing things, and I would like the end result to be as idiomatic Racket as can be. However, I am also keen to have the thing up and running as quivckly as possible, and from then on anyone that wants to, can help at leisure. Ho hum, I see there is probably no other way, I'll have to upload. I'll let you know soon as I do. That way, more issues can be raised on github too, amongst those interested and contribute to less noise on this list. Cheers! On Saturday, August 4, 2018 at 4:28:15 PM UTC+1, Philip McGrath wrote: > > 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 <[email protected] <javascript:> > > 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))You almost certainly do not want to use `eval`. > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
