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 <alex...@gmail.com <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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
