gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] cygwin support for tla, thoughts


From: michael Josenhans
Subject: Re: [Gnu-arch-users] cygwin support for tla, thoughts
Date: Tue, 04 Nov 2003 23:50:02 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

 >>>>>> "Tobias" == Tobias C Rittweiler <address@hidden> writes:

 >    >> Tom, your design sense is generally excellent; can you explain
 >    >> that design decision to us?

 >    Tobias> AFAIK one reason is, because it this way works better for
 >    Tobias> him and his emacs filemanager thingy. At least, he told me
 >    Tobias> so once, probably sarcastically.

 >It wasn't sarcasm.

 >This is good design given the infrastructure.  In Unix, it's easy to
 >do (split-string path "/").  With Tom's design, you do

 >(split-string (last (split-string path "/")) "--")

 >and now the program knows at what depth you are, simply by counting
 >the elements of the return value.  Similarly, for presentation to
 >humans, simply (last (split-string path "/")) tells a human exactly
 >where in the hierarchy you are.  The use of Lisp here is deliberate;
 >even if you never learned any Emacs Lisp, the algorithm is so
 >straightforward I bet you can tell what those expressions do.

 >With a .../$CAT/$BRN/$VER structure, on the other hand, the parsing
 >program needs to know a lot more about arch.  This means that
 >separately written tools will quickly start to constrain the
 >Arch-itect's options for redesign.  Helper programs get complex and
 >fault-prone; algorithms are abandoned in favor of heuristic

Then why not have the depth level at the end of every directory

E.g. why not have

        gar:0/mainline:1/1.0:2/patch-*:3

instead of

        gar/gar--mainline/gar--mainline--1.0/patch-*

This should cut down the length and would surely work with LISP too.


Michael






reply via email to

[Prev in Thread] Current Thread [Next in Thread]