Re: design goals

[Morten Welinder]

One more important goal, IMHO, regarding Guile: it needs to
embed nicely.

"Nicely" is such a precise, technical term, right?  :-)

FYI, my context for this is the Gnumeric spreadsheet, which
has great plans for allowing various extension languages.
The current state is that some basics are there and that's it.

Things are aren't nice include...


* Doing things that no other extension language is allowed to.
  (I call this "pretending to own the world.")  Thus it cannot
  wrap main.

  If it wasn't for the claim that the future will bring relief,
  this would have gotten Guile evicted from Gnumeric long ago.

  Basically, I want to see Guile as a library of functions that
  I can call without considering that the functions happen to
  be written in Scheme.  Not the other way around.


* Using excessive resources.  I don't think Guile has a problem
  here, but most gc'ed langauge implementation I have seen
  assume that using tons of memory is fine.

  Start-up speed could be a serious issue also.


* Interference with development tools.  That would mean debuggers,
  profilers, and memory tools like Purify.

  (This does not necessarily mean Guile has to play along with
  them, just not be in the way.)

  The gc stack walk gives me the willies here.  It will certainly
  interfere with debuggers and Purify.  (Just think of having a
  "read" breakpoint on a stack variable.)  I realise that this
  violation of the C standards is central to the design of Guile
  and won't go away.


Morten
(Not on the list)