Re: Scheme is too complicated

[Ian Bicking <ian@bickiia.earlhall.earlham.edu>]

Jay Glascoe writes:
...
> but what I really want is a high-level (very or not ;) language for gluing
> my C extensions together, i.e. "Guile".

I guess I'm coming at it from the opposite direction.  I have no
desire to touch the C side of things.  I'm happy when others do it for
me, attaching Guile to applications or what-not, but I appreciate it
from afar :)

> >   * Readable programs: both a matter of making all function calls as
> >     meaningfully named as possible -- where namespace-declarations
> >     *aren't* meaningful, but short descriptive names are; making the
> >     library functions fit well into the structure of the code the
> >     programmer is writing -- avoiding wrapping everything in lambdas
> >     and allowing the code to be structured as best fits the problem.
> 
> I'm not sure I follow.  In python I can do
> 
> import math
> def area(r):
>     return math.pi pow(r, 2)
> 
> In Guile I would *like* to do, i.e
> 
> (uses-modules (core math))
> (define area (r)
>   (* math:pi (expt r 2)))
> 
> (and maybe I can?  I have no idea how Guile's module system works.)
> 
> what can be more meaningful than "pi"?  However, the math library also has
> an "e" for Euler's number.  Obviously, I don't want math to throw "e" at
> my current namespace, but math.e <-> math:e, are great. 

Maybe I should retract the namespace comment.  However, the line is
fuzzy.  Should it be "math:sin" or just "sin"?  Well, R5RS says "sin", 
but the line is always somewhere.  You can allow the direct importing
of some names, but that's allowed now as well:

(define sin math:sin)

And maybe being wordy is for the best anyhow.  It's explicit, if
nothing else.

> > There's two issues: what could a good library system in Guile fix, and
> > what could language extensions in Guile fix.  I wouldn't stand behind
> > language extensions -- when does it stop being Scheme and become some
> > little brother of Common Lisp?  But maybe there's a way to do these
> > things in Scheme and I just don't see it.
> 
> hey!  you're talkin' to the guy who's been obssessed with auto-resizing
> hash tables for the last month or so.  My hash tables are oozing with
> doo-dads, quirks and gizmos that the user can fiddle with.  It was
> designed by committee ;) 

Oh, I didn't really mean that sort of extension.  I'm thinking about
syntactic extensions.  Scheme's simplicity is often touted as a great
advantage.  Sometimes with a little too much enthusiasm, but it is an
advantage.

...
> > A rich set of datatypes could also be a powerful addition.  Make
> > dictionaries, not hash tables -- mostly that's just a matter of
> > terminology, but I think it's important.  As a programmer, I don't
> > care about the fact that hash tables use hashing, I care about the
> > fact that hash tables are a collection of values indexed by keys.
> 
> hmm?  (define make-dictionary make-hashtab) ...
> a rose by any other name...
> Could you further clarify your statements on hash tables/dictionaries?
> I'm absolutely starved for feed-back.

Now that I think about it, there's a lot of dictionary-like
structures.  I don't even understand the difference.  A-lists at the
simplest (with annoying syntax where you have to do a set! for every
mutating operation).  And there seems to be a bunch of flavors of
these -- assv, assq, some others I've forgotten.  I don't know what
these are about.  Then there's hash-tables.  Also, if there's
hash-table-like databases support, it's another system.

I'd like to see *one* dictionary-like structure that is good enough to
replace all of these.  It should be fast and robust.  So it should
print all pretty and be printed in a non-ambiguous manner so that it
can be reread from that printing, for instance.  It should support
accessing it anyway you choose (by key, by value, by key-value pair,
by mapping, by for-each, etc).  Dictionaries are important enough to
be done completely.

It would also be neat if the system represented the global namespace
as a dictionary (ala Smalltalk).  It could definately help programming 
tools (plus just being slick).  But it's not essential.

(define define 
  (lambda (name value)
    (dictionary-add *guile* name value)))


> > Transparent Code: Well, write as much of it in Scheme as possible.
> > If, for performance reasons, it isn't written in Scheme consider
> > providing a reference implentation which does the same thing as the C
> > (just slower).  
> 
> I've found that Guile C extensions are pretty readable (relative to
> Perl/Python extensions, Tcl? I have no idea)

The C extensions aren't going to be as readable as Scheme (usually).
Relatively, they might be readable, but I know I can't get excited
about the idea of figuring out C code and how it relates to the Scheme 
environment.  I'd rather just stay in Scheme.

In some ways this is a pedagogical tool, since you can learn the
language and the implementation all at once while you explore the
system (if the system is written in Scheme).  A lot of people who (we
would hope) would use Guile are learning, both because Scheme isn't
widely known and because scripting is often done by novice
programmers.  Helping them learn is half of what the environment is
about.


<------------------------------------------------------------------->
< Ian Bicking                 |  bickiia@earlham.edu                >
< drawer #419 Earlham College |  http://www.cs.earlham.edu/~bickiia >
< Richmond, IN 47374          |  (765) 973-2824                     >
<------------------------------------------------------------------->