[e-lang] Down with assumed namespaces!, or Re: File API taming

[Kevin Reid]

On Mar 19, 2009, at 19:44, ihab.awad at gmail.com wrote:

> Hi folks,

Hi. Your message has inspired me to a brain dump. The first part is  
relevant to your question; the second part is relevant to E designers.

> In our discussions about a possible file taming for JavaScript, MarcS
> directed us to the E taming. The E taming, about which I was reading
> here:
>
> http://www.erights.org/javadoc/java/io/File.html
>
> seems to treat the absolute String path of a file as public
> information available to anyone. What it *does* restrict is the
> ability to start from this data and turn it into *authority* -- in
> other words, the ability to create a File from a fully qualified path
> is tamed away.

One of the problems with this is that it is difficult to provide a  
*test suite* for the file interface of an E implementation.

One thought I have had about this is for there to be an option to,  
shall we say, "chroot" the filesystem: produce another FileGetter (aka  
<file>) object, rooted at a particular "real" directory, whose members  
provide paths relative to it. This scheme is designed to be backwards  
compatibile.


More like your scheme, one could have a system where a given file  
object never knows its own path -- but given a directory object, you  
can ask it "what is the path to this file, if it is one of your  
children?" This would essentially be putting the functionality of the  
FileGetter (specifically, optUnget/1) on *every directory*.

This operation has the property that it is "just" an optimization of  
exhaustive search of the directory tree.


I've already thought that schemes like this ought to be applied to  
more of the E standard library, in places where we have managed  
namespaces instead. In particular, printing of objects at the REPL:

We have objects, such as "true", "int", and "nullOk[int]", which are  
written to print itself as the E source which will yield it when  
evaluated in the standard safeScope.

I argue this is not good, for several fuzzy reasons:

- It is spreading knowledge of the namespace all over the system.

- It encourages thinking that these names are global, memorable, and  
secure, which we all know is impossible.

- The alternative has other benefits.

The alternative is that these objects should *not* print specially,  
but rather the REPL's TextWriter should recognize them and print their  
names from the scope instead. This technique is already used in  
serialization, and in fact there is a provision to use this at the  
REPL. From deSubgraphKit:


         /**
          * A printFunc can be used as an argument in
          * <pre>    interp.setPrintFunc(..)</pre>
          * to be used as the 'print' part of that read-eval-print loop.
          * When using an unevaler's printFunc for this purpose, we  
have instead
          * a read-eval-uneval loop.
          */
         to getPrintFunc() :near {
             def printFunc(value, out :TextWriter) :void {
                 def builder := deASTKit.wrap(deSrcKit.makeBuilder())
                 out.print(unevaler.recognize(value, builder))
             }
             return printFunc
         }

This replacement, however, makes *everything* shown print in Data-E  
syntax, and is therefore somewhat impractical. My suggestion is to  
only borrow the notion of "exits" and keep everything else the same.

Furthermore, if we consider all or some user-created bindings to be  
exits, then we can do useful things like this:

   ? def lists := [
   >   def l1 := [].diverge()
   >   def l2 := [].diverge()
   > ]

   ? lists[entropy.nextInt(lists.size())]
   # value: l1

That is, the repl recognizes for the user distinct but similar-looking  
objects he has previously created.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>