Re: Yow!

[haahr@mv.us.adobe.com (Paul Haahr)]

> This has got to be the best unix shell I've ever seen!

thank you, thank you.  :-)

> 1) $cdpath is a really egregious creeping feature to make a builtin part of
> the shell, considering how nongeneral it is.  If people really want a
> cdpath-like feature (admittedly, I use such a thing too), one could do:

i'm not sure what you mean by non-general, but i do agree that the
primitive $&cd probably shouldn't do path-searching.  i still think
it should be in the ``default'' shell configuration, but the call
to %cdpathsearch should probably be from a function defined in
initial.es rather than the primitive.  comments, anyone?

> Alternately, instead of calling `access' in `cd' directly, one could call
> %cdpathsearch, but I think this doesn't really belong as a builtin hook
> either.

i've become convinced after listening to what people on this list want
to do, the more hooks, the better.  (this could be taken to ludicrous
extremes, of course.)

> 2) The man page says for `forever', 
>	...
> It seems like it would be more general to indeed have a looping construct
> that didn't catch any exceptions, but that also allowed a test of some
> sort.  Perhaps `while' could even be implemented in terms of this new
> construct, setting exception handlers first.

when we were first doing things, the reason that we didn't do it
that way was that if we made while a function, then it would also
catch the return exception, which seemed like a mistake.  i believe
that the new $&noreturn primitive eliminated that problem and while
could be written as

	fn-while = $&noreturn @ cond body {
		catch @ e value {
			if {!~ $e break} {
				throw $e $value
			}
			result $value
		} {
			let (result = <=true)
				forever {
					if {!$cond} {
						throw break $result
					} {
						result = <=$body
					}
				}
		}
	}

> Admittedly, right now you can create your own magic exception and use that
> to get of out of `forever',

which is exactly what we did with the eof exception.

> so it might seem like adding a condition is
> just syntactic sugar.  But I can imagine wanting to avoid the risk of
> shadowing an identically-named tag for another exception handler further
> up.

we have no formal mechanism for reserving exception names, other than
those that are in the man page.  on the other hand, the same problem
is more pronounced w.r.t. function names.

> 3) `local' doesn't seem like a very well-chosen name.  In fact, because
> "local" variables still cause settors to be invoked, get exported, and have
> other dynamic-scope properties, they are far less "local" than lexically
> scoped variables created with `let'.  Perhaps a better name would be
> `fluid-let' or even `dynamic-let'?  (The former would at least be
> consistent with Scheme.)

``let'' and ``local'' switched meanings between 0.79 and 0.8, mainly
to follow scheme's use of ``let.''  (at the time i was hesitant
because we had a user base of ~10 people;  in retrospect i think
that this is a very good change.)  i was informed that at least
perl used ``local'' for ``fluid-let.''

when we swapped ``let'' and ``local'', we had considered using
``fluid-let'' for dynamic binding.  as i remember, our reasoning
at the time was:

	+ for those who aren't scheme-aware it's probably
	  more confusing than ``local.''
	+ local is consistent with the traditional name for that
	  type of binding in other shells, ``local assignment.''
	+ i like short, unhyphenated keywords

now that the paper's been published, we're very reluctant to change
something so central to the language.

thanks for your comments.  if i find the time, both (1) and (2)
will be incorporated in the 0.84 release;  otherwise, expect them
in 0.85.  any more feedback would be appreciated.

paul