[m-dev.] Re: for review: term browser (version one)

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Oct 16 17:02:09 AEST 1998


On 16-Oct-1998, Bert THOMPSON <aet at cs.mu.OZ.AU> wrote:
> Fergus Henderson <fjh at cs.mu.OZ.AU> writes:
> 
> |I think we really need two different interfaces to the browser:
> |an interactive one, and a non-interactive one which just displays
> |terms with some kind of fixed depth limit.
> 
> Absolutely. I just forgot to include that one.
> 
> |"XXX" is supposed to indicate something that should be done,
> |rather than merely something that could be done.
> 
> What then should be used to indicate possible improvements?

Just ordinary comments without any special indicator?

> How compatible do you want the syntax to be with SICStus?

I don't think that we should assign much importance to SICStus compatibility
in the term browser.

> Unix syntax is unnecessary since `directory' names can only have digits
> in them, so pretty much anything else other than initial slash, dotdot,
> and number can act as a directory separator.
> 
> Initially I agreed with you, but it is actually easier to type
> "cd 2 3 2 2" than to type "cd 2/3/2/2".

That I agree with.  How about you just allow whitespace as an
alternative to slash?

> If you spend a lot of time in
> a debugger, it makes a difference. Nonetheless, I probably should
> disallow things like "cd orange 2 3 papaya 2 quandong rhambutan"

Yep.

> | > New file: frame.m
> | > 	% XXX: Make frame type abstract instead?
> | > 	% XXX: I'd rather not fully module-qualify the frame type.
> | > % :- type frame.
> | > :- type frame == list(string).
> 
> |I don't understand the second XXX comment.  Could you elaborate, please?
> 
> I simply meant that I'd rather type "frame" everywhere instead
> of "frame__frame".

Sure, and you can, can't you?

> I'll just nuke that comment.

Fine.

> | > 	% Clip a frame to the rectangle ((0,0),(X,Y)) where
> | > 	% origin is on the top-left. Coordinate axes go down and right.
> | > 	% XXX: Any reasons to implement a general clip?
> | > frame__clip(X-Y, Frame, ClippedFrame) :-
> | > 	list__take_upto(Y, Frame, YClippedFrame),
> | > 	list__map(left(X), YClippedFrame, ClippedFrame).
> 
> |The "XXX" comment here isn't clear to me.  Could you please elaborate?
> 
> I was musing whether it's worthwhile implementing a clip pred that
> allows an arbitrary cliprect rather than one constrained to start at
> the origin. This might be useful if you wanted to pan around on the
> entire term frame, for example. On reflection, I think this'd be overkill,
> so I'll just remove the comment.

Fine.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.



More information about the developers mailing list