On Tue, Jun 28, 2011 at 8:19 AM, John Clements <cleme...@brinckerhoff.org> wrote: > > On Jun 27, 2011, at 5:10 PM, Robby Findler wrote: > >> On Tue, Jun 28, 2011 at 7:52 AM, John Clements >> <cleme...@brinckerhoff.org> wrote: >>> >>> On Jun 27, 2011, at 4:45 PM, Robby Findler wrote: >>> >>>> We're talking about relative requires only, right? >>>> >>>> How are you proposing to signal the error? >>> >>> My guess about how this works--correct me if I'm wrong--is that for unsaved >>> buffers, DrR sets a parameter such that the expanded code has the current >>> directory as (uh, part of?) the syntax-source of the expanded source. I'm >>> guessing that I'm not right, or it would be as simple as disabling this for >>> programs written in BSL et al. >> >> DrRacket does indeed set current-directory and could instead signal an >> error instead of setting it. That would mean no unsaved file would >> run, however. Is that really desired? > > Would it not be possible to set the syntax-source in such a way that relative > requires would fail? We may be out of DrR and into just plain R here.
Yes, we have to be, I'm pretty sure. > Indeed, I would be happy if buffers without a recorded save location couldn't > make relative requires in *any* language level, though I realize that such a > change would be more likely to have repercussions elsewhere. I think that would probably require a new parameter that controls where relative requires are relative to being exported and allowing it to have a value that says "no relative requires allowed". (current-load-relative-directory is maybe already this, without the extra functionality, maybe?) > I suppose there could be situations where users dynamically create syntax > objects and set the current directory rather than setting the syntax-source > of the objects, though that doesn't sound like the most robust way to write > the code. I don't understand this comment. (I believe that the source field of a syntax objects is not involved in resolving relative requires.) Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
