Re: Goo Nitpicks

[Christopher Armstrong <carmstro@xxxxxxxxxxxxxxxxx>]

Sorry, I forgot to Cc: the list.

-----Forwarded Message-----

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.

> 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.


> > 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.

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.)

> > 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.

> > 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...).

> 
> > 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.

> > 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.

> > 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.

> > 11. According to wiki, default values will look like:
> > (dm function (a:0|<int> b:1|<int>))
> > 
> > It may be just me, but I think default values should be consistent with
> > rep's and let's variable assignments.
> > 
> > So, maybe make default values look like:
> > (dm function ((a 0)|<int> (b 0)|<int>))
> > 
> > Or change let/rep to look like:
> > (let (x:0 y:3))
> 
> nice.

Yah, that is really nifty :-) Although I probably won't use it much; I'm
*addicted* to `def' :-D

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

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.

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?  (b) there should be continuation
prompts. 

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

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

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