search

pnkfelix / larceny-test

test import of trac db
Other
2 stars 0 forks source link

current-directory semantics are scary #38

Open larceny-trac-import opened 11 years ago

larceny-trac-import commented 11 years ago

_Reported by: tov on Wed Apr 5 16:58:24 2006 _ In particular:

larceny-trac-import commented 11 years ago

Author: pnkfelix Just wanted to record that Jesse and Felix met with Will on April 5th and talked about this, and I believe that we agreed:

  1. For now, we can have (current-directory ARG) just chdir to ARG immediately. (That is, we can keep the current semantics.)
  2. In the future, current-directory should be a parameter (as in, a maintained on a per-thread basis and implemented with continuation marks), with the following "gotcha's":
    • When you call current-directory, it should chdir to the ARG
    • All low level functions that rely on some notion of a current directory (e.g. the system procedure) should chdir to (current-directory). The idea here is that another thread might have chdir'd in the meantime, so we should (lazily) chdir back when we need to.
    • Thread switches should NOT chdir

The only questionable or ambiguous thing about the above description is whether leaving a parameterize form that affected current-directory should actually chdir back to the prior directory, rather than just leaving that job for later. This becomes an issue when such a chdir would signal an error (e.g. because the directory you want to chdir to no longer exists).

Jesse has argued that it could be very non-intuitive to have exiting a parameterize to raise an exception, which implies that we should not chdir on exit from a parameterize. This would mean that errors would not be signalled until something else does the chdir (or perhaps no error would ever be signalled).

Felix believes that if we made exiting the parameterize behave differently from entering it, then we can't get away with the simple implementation of parameterize that Jesse has suggested to Felix (where parameterize has no magic, it just treats parameters as procedures and all the continuation mark magic is handled by the parameter object itself). At the very least, it would mean that the interface between parameterize and the parameter objects would have to be extended to differentiate between the on-entry and on-exit cases.

(But Jesse and Felix have been talking about doing that anyway, to allow safe-for-space implementation of a current-larceny-root parameter coupled to a LARCENY_ROOT environment variable.)