Re: Goo Nitpicks

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

Christopher Armstrong <carmstro@twistedmatrix.com> writes:

> From: Christopher Armstrong <carmstro@twistedmatrix.com>
> To: Jonathan Bachrach <jrb@ai.mit.edu>
> Subject: Re: Goo Nitpicks
> Date: 01 Aug 2002 19:16:54 -0400
> 
> I have some more nitpicks. See below.
> 
> On Thu, 2002-08-01 at 17:27, Jonathan Bachrach wrote:
> > Jonathan Hseu <vomjom@vomjom.org> writes:
> > > Most important is #1:
> > > 1. Many programmers prefer mod:name over (use)ing everything into the
> > > namespace.  
> > > The problem with mod:name as it is is that directories can pile up:
> > > (foo/bar/baz/math:sin foo/bar/baz/math:$pi)
> > > 
> > > Even a simple goo/math:$pi is a pain to type.
> > > 
> > > My proposal is this:
> > > If the programmer types: (use goo/math)  , it imports everything as it
> > >   does now.
> > > If the programmer types: (use goo/math math)  , the second argument
> > >   becomes the shortened version and then the programmer can type
> > >   math:$pi
> 
> I'm not sure `use' is the best thing to add it to. It seems that there
> should be a new, separate `import' (or similar) form for this, because
> `use' (so far) implies that you're importing names directly into the
> namespace. I'm not sure if vomjom wanted his new (use goo/math math) to
> also bring in the 'export's of the module, but I don't want that to
> happen when I'm importing modules. Anyway, I think Python's `import'
> statement is really perfect. 'from module import name', 'from package
> import module', 'from package.package import module', etc. Python's
> 'from foo import *' is basically equivalent to (use foo). Of course I'm
> not suggesting that the syntax be stolen, but the semantics.

actually, what i had in mind which is very much like dylan and eulisp
is the ability to do selective imports:  

  (use (each goo/math $pi))

with prefixing

  (use (prefix goo/math math/))

and combined

  (use (prefix (each goo/math $pi) math/))

and in general provide filters constructed using a composition of set
operations and renaming.  this way you could control your namespace
more precisely.  i'll put a proposal up on the goo wiki.

i should say that i don't like python's from statement because it
snapshots the current binding values.  what if the binding values in
the imported from module change through reloading or redefinition.
you're out of luck?  the only way to ensure up to date values is to
use a module object and dereference it for every binding access.  this
seems cumbersome to me.

furthermore, the only way to know what you use of a module is to look
for all these module dereferences and even then you won't know because
the module is a first class object and could be passed around and
accessed dynamically.  this is the one place where goo is trying to be
a bit static, forcing you to list your exports and imports.

> > that seems reasonable.  there are other deficiencies of the current
> > minimal module system such as no renaming, no set operations (i.e.,
> > selective importation), absolutely no circularities.
> 
> Otherwise, let me say that I strongly agree with vomjom here; I really
> hate (use)ing stuff, because it clutters up my namespace (Although I do
> use it for very basic ubiquitous stuff, like macros that I use a lot).
>
> One of my _big_ annoyances, that's tangentially related, is that I have
> to currently (use) a module to add a method to a generic function
> defined in it. Two solutions: 1) keep a global registry of all generic
> functions everywhere and have `dm' look up and add methods to a gf in
> the registry, or 2) be able to explicitly tell `dm' which gf to add the
> method to. I've not thought a lot about #1, and it seems like it will
> probably have problems. But I'm fine with either solution.

the problem is that then you have another namespace (i.e., the generic
function registry) that you need to control.  

in java, don't you need to use an interface to implement it?  generics
provide an api like an interface.  from what i know about python, a
class implements an interface when it implements all required methods.
this is definitely more dynamic as are python's class-based
namespaces.

> > > This would replace the current mod:name system (because of possible
> > > name clashing).
> > 
> > how would this replace it and what name clashes are you referring to?
> 
> I didn't understand this either. I _want_ to keep the mod:name system
> ;-) I just think that the `mod' part should be a first-class object, so
> I can bind it to different names.

it doesn't have to be a first-class object.  my proposal is just to
allow bindings to be renamed.  again goo has a much more static
namespace system than in python.  having modules be first-class
objects is problematic from the standpoint of optimizations and
macros.

> Oh, and speaking of `mod:name' -- It seems that this syntax doesn't work
> in regular modules. wutsupwitdat? I hope that's just an oversight: I
> won't be able to continue coding long without it (as I said, I can't
> stand using `use' everywhere.)

the original idea was that mod:name would only be used for module
protection violations (i.e., getting binding values from unexported
bindings in other modules) in the listener.  i should at least allow
one to use that syntax to access bindings that are exported.  i didn't
want to have people write code that accesses bindings willy nilly from
other modules.

> > > 3. Chris Armstrong's nitpick: Why is string formatting tied to ports?
> > 
> > for efficiency.
> 
> Sorry, but I can't fathom why string-representation needs to be
> super-fast.

i use msg for code emission in g2c.

> > > It'd be nice if there was a function ('format' maybe?) that returned
> > > a formatted string the way (msg) prints them.
> > 
> >   (df format (str|<str> args|... => <str>)
> >     (port2str port (app msg port str args)))
> > 
> > > (msg) could still exist as a shortened version of (write port (format))
> > 
> > but then you're going cons a string unless you have a much smarter
> > compiler.
> > 
> > there definitely needs more work on printing.  i'll think more about
> > this.
> 
> Yah, I have some suggestions for this. So it doesn't really bother
> me that it requires a port to do formatting, but one thing that I
> love about Python is the ubiquitousness of the `str' function (and
> it's __str__ counterpart, but that's irrelevant when you have
> generic functions ;-)). I propose that `to-str' be used for `write'
> -- but, of course, the default implementation(s) of `to-str' can use
> ports, if you really think the efficiency is required. But I want to
> be able to define a to-str for my classes, and have `write' use it,
> if it uses a port or not. I don't want to have to mess with ports
> just to define a simple string representation of my objects (unless
> you can figure out a way to abstract the ports stuff away...).

that's fair enough.  i'll think about this more and come up with a
proposal. 

> > > 4. We need a slicing function for sequences (I couldn't find one...).
> > > 'slice' is a good name IMHO... we could possibly use _ to indicate
> > > either the end or beginning of the array.  For instance:
> > > (slice array 1 _) to slice from 1 -> end.  (Or use Python's -1?)
> > 
> > it's called 'sub'.  i do like the python's -1 but that does
> > potentially mask real indexing errors.  it's probably worth the
> > convenience though.
> 
> vomjom is mistaken here: -1 is _not_ used to represent the end of the
> sequence (well, it does represent the last _item_ in the sequence, but
> Python's slicing is non-inclusive for the "end" index):
> 
> >>> [1,2,3][0:-1]
> [1, 2]
> 
> To say "to the end" in Python slicing, you use `l[i:]'. Obviously that's
> not an option here, as we have no special (unambiguous) syntax.

i would propose 

  (take x n) == (sub x 0 n) == x[0:n]

and 

  (drop x n) == (sub x n (len x)) == x[n:]

as is done in NESL (by guy e. blelloch).  what this doesn't cover are
the cases where negative numbers are used as the second index.  i
could have another sub, say sub* handles this case and keeps sub pure.

> > > Also, an optional third argument for step size would be nice.
> > 
> > sure.
> > 
> > > 5. Two things are incorrect on the web:
> 
> object-class is not documented; I really needed that, and it took me a
> while to find it.

thanks.

> > > 10. Will we be able to import from the directory in which goo is run in
> > > the future?
> 
> I say steal Python's system for this: 1) have a GOOPATH *path list*
> (i.e., GOOPATH="/home/chris/goomods:/home/chris/.goo/mods"), as well as
> a vector accessable within the runtime that you can munge. Of course, a
> set of default module paths is also desirable: /usr/lib/goo/mods,
> /usr/local/lib/goo/mods, etc, would all be in that vector by default.

that's basically the plan.

> ...
> One other things that weren't directly (or indirectly) mentioned in the
> last couple messages: 
> 
> 1) When I unsuccessfully try to load a module (it has a syntax or
> runtime error), I cannot attempt loading it again:
> 
> goo/user 1<= test:foo
> ERROR: test: error: Circular use of test not allowed

ok.  

> 2) There's no `reload' functionality (that I've found) that will let me
> reload a module that's changed on disk, even if the initial load _was_
> successful.

ok.

> 3) REPL. I'm writing a tutorial for goo based on the Python tutorial,
> and since I'm including snippets of REPL usage, it's become painfully
> obvious how annoying the REPL prompts are. (a) Output and Input prefixes
> should not be so similar. How about leaving out the current-module name,
> and just have "=>" or somesuch?  

that seems reasonable.

> (b) there should be continuation prompts.

what do you mean here?

> 4) Can I have an option to turn off the annoying ("1. Return to
> interpreter level N."*stacklevel) messages?

ok.

> I know I have more issues, but I can't remember them atm. I'll be
> sending more email. :-)
> 
> In conclusion, let me say (if it wasn't already blindingly obvious)
> that I'm a big Python fan: So far it's my favorite language, and I
> think it got a lot of things correct, but lisp is my favorite
> language *idea*.  Goo is the lisp with the most potential, so far as
> I can see, so I want to make sure it gets the same things right that
> Python did. If you dislike the fact that I'm trying to turn Goo into
> Python (;-)), at least weigh the suggestions I give with the same
> scale as a hord-core old-lisper (not to say that you wouldn't of
> course! ;-)) Anyway, I'll do my best to help implement and
> contribute any of the ideas that you agree with, and as for the ones
> you don't agree with, I'll probably implement them anyway ;-D

thanks for your suggestions!  i like python as well.

jonathan

>                                 Chris Armstrong
>                          << radix@twistedmatrix.com >>
>                 http://twistedmatrix.com/users/carmstro.twistd/