This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Sat, 31 Oct 1998, Ian Bicking wrote: > However, programming in a functional style can lead to great > optimizations, because the behavior can be predicted before runtime > much better. I imagine Stalin uses this to its advantage(?) > Distributed programming also benefits from this -- I'm sure there are > other benefits as well. yeah, for instance, the Scandinavians (?) are absolutely mad about Erlang. comp.lang.functional FAQ: "Erlang is a dynamically typed concurrent functional programming language for large industrial real-time systems." but what I really want is a high-level (very or not ;) language for gluing my C extensions together, i.e. "Guile". I admit to being willfuly dense (just a tad) in my last couple posts about functional style. But the thing is, even if I said functional programming was absolute bollucks, I wouldn't be putting down Scheme. That's one of the great things about Scheme: it provides a 100% support for both imperative and functional coding styles (and even this weird, slippery CPS thing). > As to the size of C/Perl/Guile programs, I think a lot of it has to do > with the libraries. I find the various C libraries to not be able to > integrate themselves into the language very nicely at all. Perl does > this much better, not to mention having so much functionality built > right into the language. I also find that shell scripting (who's > library is the programs on my machine) works very nicely for me. And > what could be shorter than an Awk script for a job which Awk is good > at? awk rules! > * 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. > * Transparent code: all aspects of the code can be inspected and > understood, including the library functions. > > * Mnemonic: a rich environment means having a lot of functions. > Remembering each one and the forms it takes will get difficult > without some means of managing it. Keyword arguments are (IMHO) a > great way of doing this. let's just hope all those functions are kept in appropriate modules ;) > * Documentation: both reference -- a listing of functions and > what they do; and concept-based -- what you want to do and the > functions (and data structures) provided to help you do those > things. Optimally, closely integrated with the process of writing > code, e.g., a good Emacs environment. > ... > Documentation, of course, we all know about and know how to fix. The > other's aren't so obvious. > yep > 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 ;) > Readability: Scheme has a way of leading to long expressions. When > you get down to it, any functional procedure will be made up of one > (long) expression. That's hard for humans to parse. I like the > highlighting that DrScheme does -- when you are at a open or close > parenthesis, it highlights (without being obnoxious) the expression > that is enclosed by that parenthesis. The passive nature of the > highlighting is what makes it nice. (The static code analysis that > DrScheme does is also nice, but I'm not sure it's helpful enough to > warrant the complexity of implementing the interface) > > There might be other ways of representing the Scheme to make it more > readable. I'm sure some whiz-bang elisp hacker can whip up some special Guile mode for emacs. > Along the library side, it would be nice to think about the naming > system for all the library procedures and coming up with a consistent, > concise, and meaningful system for naming (this also helps mnemonics). > I wish I could give a concrete example, but I haven't really worked > with any complex libraries in Scheme. However, what I haven't seen > that I think is important is that Guile should be viewed as including > not only the core language, but a set of modules which provide > commonly-used functionality. These are too essential to the language > and it's practical use too simply be add-ons. If these modules were shareable objects ('*.so' on my machine) then you'd never notice whether it was in Guile's core or not. > 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. > 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) > ... <more stuff snipped, time to go home> > <-------------------------------------------------------------------> > < Ian Bicking | bickiia@earlham.edu > > < drawer #419 Earlham College | http://www.cs.earlham.edu/~bickiia > > < Richmond, IN 47374 | (765) 973-2824 > > <-------------------------------------------------------------------> Jay jglascoe@jay.giss.nasa.gov