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]

Re: Bad news from the module/environment front


On Mon, 5 Jul 1999, Telford Tendys wrote:
> Two points here, firstly is guile intended to support such full
> blown LISP apps? Look at emacs, it's fast but most of that speed
> comes from a big library of low level C code that does the guts of the
> work. The average emacs application is not real big in terms of
> lines of LISP code. You can do a lot with a few lines of emacs LISP
> because there is such a huge function library available to call.
> 
> Secondly, I guess that my intention is always to migrate chunks to C as
> I get each chunk into a sufficiently well-defined state. I'm not so
> big on object-oriented stuff. I don't mind the general philosophy but
> I find the syntax too tedious and call/cc is such a huge performance
> slug in guile that I keep away from that too. Surely if you use too
> many fancy features, you are going to be in trouble with the compiler
> anyhow.
> 

    Actually, I'm working on a server at the moment that will use guile to
provide a full blown programming language, not just a "scripting
language".  Mainly to write policies (as opposed to mechanism) that
incorporate GOFAI techniques for some things.  But hopefully, for stuff I
don't have any idea about yet.  Eventually, nearly everything (including
mechanism) should be specifiable in scheme as well as C.  So I for one
would like to have a good compiler - preferably one that can be used at
run-time.

> But perl is further down the track than guile. At version 5 it
> retargetted. Even so it's main users are sysadmins and CGI authors
> which are both essentially text scanning applications. How much
> numerical code gets written in perl? How much GUI code?

    If you consider interactive web pages to be GUIs, then untold amounts
;-)

> It should not be. Guile is supposed to target one particular use of
> scheme which is support for script extensions for applications.
> The idea is that every decent sized application will eventually want
> to support user scripts and they might as well support scheme as
> make up their own language. Once they support scheme they can
> hang front-end processors for alternative syntax if the users feel
> more comfortable with that.

    No - guile is for more powerful programming than simple scripting.  
At least, I thought that was the reason for picking scheme instead of
something like Tcl.  Sometimes you'll want an alternative scripting-only
language that scheme can interpret, but those languages are probably going
to be limited in expressive power compared to scheme.
    Or, at least, that's why I want to use it.  That, and the fact that my
brain is being insidiously reprogrammed by the PL people here at IU to
hate C and enjoy scheme. ;-)

Lynn



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]