Re: the future of Guile

[Marco Maggi]

Pre-answer to all: the most important thing is to make clear
what are  the priorities.  With a  "language for extensions"
(LFE)   there  are  certain   priorities,  with   a  "Scheme
implementation"  (SI) there are  others. I  fear that  if no
choice is made Guile will be wiped out by other Schemes.

Call me stupid if you want, but I picked Guile because the G
stands for GNU  and the E stands for  Extensions.  I look at
the E as a promise: There will always be special interest in
making it easy to interface with C.  Now I am not sure if it
was a good choice.

I  tried to  attract users  interested in  math  software by
coding extensions to special numbers  and the GSL.  I did it
for my own  interest, not "for Guile". But  I failed. I will
never know why (maybe it was  just a bad idea), but maybe it
is because Guile  is too slow and the fact  that Scheme is a
beautiful and  featureful language (compared  to Octave, for
example) is not enough.

It is all FUD, yes, but in  the last 7 years a lot of people
said that "TCL is dead".  Lately on comp.lang.tcl they had a
discussion on  a unified interface for  database access; and
they are going  to do it. This is not  being dead. For Guile
we cannot even  talk about such a thing; correct  me if I am
wrong, but on the Net there are mostly orphaned projects for
Guile...

Ludovic,  you are doing  an incredible  amount of  work. But
everybody's life moves on.  How many active Guile developers
are there? Or at least developers that are "still here"? How
many active ones understand the evaluator?

So, how much work is needed to make Guile a good choice "for
something"? As  a LFE I think  that the work  needed is less
than what is required for a SI.

As a SI my opinion is  that some sort of compiler is a must,
but  it is  a lot  of work  (I took  a look  at Lightning...
there are  s many  opcodes...).  You can  try to  do any
algorithmic stunt  to make Guile faster  without a compiler,
but will it be enough for someone?

@Stephen Compall:
>> 3. For Guile 2.0 backwards  compatibility at the C level can
>>be broken. Freely. No shame. No blame.
>
>This message references another message that I can't find:
>
>http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html
[stuff about inclusion of deprecated code]

@Neil Jerram:
>Disagree, in general.  Why should we be arbitrarily awkward?
>If there are specific  motivations, we should consider those
>case by case.

How much does it cost never  to discard a thing?  With a LFE
a huge shared library is not "lightweight". Can something be
discarded at least in the 1.x -> 2.x transition?

With "everything is a SMOB" and "death to structs" something
in the  interface changes.  I am not  talking about changing
"scm_to_int" and  the like, but, for example,  if a function
to bind  a  symbol  to the class  of a SMOB  in a
selected module  is added:  the SMOB definition  protocol is
changed  a  bit.  The  same  with  a  function that  selects
superclasses.

More on this later about the limit on SMOB number.

@Ludovic Courts
>> 2. GOOPS always there.
>
>GOOPS is  nice at times,  but it's also very  "unschemey" in
>spirit, [...]

I am not  sure what you mean here. The ugly  thing for me is
that the  DEFINE-* must be at  top level; I  dunno why. This
prevented me  from trying  some automation (I  cannot recall
which ones now).

Generic functions  must be mutable  and they must  be "entry
points"  in a big  graph-like data  structure.  That  is the
only way to  do it.  I think that there  is consensus on the
idea  that  generic  functions  are  one of  the  points  of
strength of Lisps.

The thing  I know  is that coding  a math  extension without
them would be  a nightmare (there is a reason  if I have not
written my stuff for TCL).


@Ludovic Courts
>> 2a.   It  is  fine  to  have  both  procedures  and  generic
>> functions,   but  the  default   for  Guile's   C  coded
>> procedures  must  be  primitive generic.
>
>What would  it buy you  if `read' were a  primitive generic?
>`write' is  certainly useful as  a generic, but I  don't see
>the benefit of `read' as a generic.

READ is a nice short  symbol and everybody knows its meaning
in real life. It should  be available for everyone to use as
function name.  I do not  care if MAKE-PROCEDURE-WITH-SETTER
is not a generic function because it is unlikely that I need
such a name for a method, but READ...


@Ludovic Courts
>> 3a. The limit on SMOB type number must be destroyed.
>
>It's  gonna be  hard since  we  have only  8 bits  available
>currently[...]

A possible solution is to use the first level SMOBs only for
Guile-defined  ones, and  change the  implementation  of the
public API  for SMOB  definition to use  an evolution  of my
subordinate SMOB thing.


@Neil Jerram
> 3b. Death to  structs!  IMO they were "an  attempt", but the
> resulting code is awful (sorry, but can you disagree?).
>
>Err..  but aren't  structs the  main  part of  how GOOPS  is
>implement

On the topic of asyncs and utility as an extension language

[dskr]

Hi,

In an earlier message today, I mentioned my use of guile as an  
extension language. There is one new barrier to use of guile as an  
extension language that exists in guile 1.8 that did not exist in  
guile 1.6.


The new async mechanism works via a pipe. The natural thing,  
remanufacturing the pipe, does not happen on
a call to primitive-fork. I'm of the view that an angel gets its wings  
each time I call fork and so my codes do this with reckless abandon.


Why fork? Lots of reasons... I use it so that I can mmap enormous  
files read-write with MAP_PRIVATE and fork new processes that mark up  
their now private copy. It is tremendously efficient for many  
applications.


I understand that the work to patch up the pipes may not be worthwhile  
in applications that are about to call exec, but this could be  
remedied easily by providing the expected primitive-vfork for this  
purpose.


Cheers,
Dan Ridge


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi,

Mike Gran <[EMAIL PROTECTED]> writes:

> Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), 
> but, each has its own packaging scheme, documentation
> scheme.  None of them are released in a coordinated manner 
> with the Guile releases themselves. 

They don't have to be coordinated.  We may want, from time to time, to
move commonly used code e.g., from Guile-Lib, into Guile core, but we're
not going to have all possible Guile bindings into Guile core.

> Second, most non-trivial scripts require the whole of the configure, 
> make, make install, LD_LIBRARY_PATH, %load-path overhead.

For pure Scheme applications or modules, there's little overhead.  You
can use Autoconf + Automake (I use it because I find it helpful and
consistent with other free software packages), but you don't have to.
You can as well just distribute and bunch of suitably laid out Scheme
files along with a `README' explaining how to use them.  :-)

Thanks,
Ludovic.



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hello,

"Marco Maggi" <[EMAIL PROTECTED]> writes:

> Pre-answer to all: the most important thing is to make clear
> what are  the priorities.  With a  "language for extensions"
> (LFE)   there  are  certain   priorities,  with   a  "Scheme
> implementation"  (SI) there are  others. I  fear that  if no
> choice is made Guile will be wiped out by other Schemes.

It took me some time, but I now think there's no such sharp distinction
between "LFE" and "SI".  With the LFE paradigm in mind, one thinks about
a C application occasionally calling Scheme code.  But as you want more
extensibility, you rather end up having a Scheme application
occasionally calling C code.

This is what SIs are about: being able to do the best with Scheme code,
while still allowing interfaces with C code.

> For Guile we cannot even talk about such a thing; correct me if I am
> wrong, but on the Net there are mostly orphaned projects for Guile...

I'm not sure about the "mostly", but there's surely a huge amount of
orphaned projects, including VMs, compilers and the likes.

> How many active Guile developers are there? Or at least developers
> that are "still here"? How many active ones understand the evaluator?

Neil and Kevin (at least) have been here for a long time, and I'm sure
they understands large parts of the project.  Now, it's true that few of
us are spending a lot of time to actually create new stuff and set a
direction.  I encourage others to contribute too, but we need this kind
of discussion to get an idea of what we're heading to.

> As a SI my opinion is  that some sort of compiler is a must,
> but  it is  a lot  of work  (I took  a look  at Lightning...
> there are  s many  opcodes...).  You can  try to  do any
> algorithmic stunt  to make Guile faster  without a compiler,
> but will it be enough for someone?

An interpreter *can* be much faster than what we have now, and SICP
(among others) is here to guide us.

> @Ludovic Courts
>>> 2. GOOPS always there. 
>>
>>GOOPS is  nice at times,  but it's also very  "unschemey" in
>>spirit, [...]
>
> I am not  sure what you mean here.

Then I failed to convey my feeling.  ;-)

It's really a matter of taste: I've become more and more interested in
the functional aspect of Scheme (and other languages), and have come to
dislike the imperative programming style.

> READ is a nice short  symbol and everybody knows its meaning
> in real life. It should  be available for everyone to use as
> function name.  I do not  care if MAKE-PROCEDURE-WITH-SETTER
> is not a generic function because it is unlikely that I need
> such a name for a method, but READ...

Then generic functions are not the right tool.  What you want is
"(define core-read read)" or something like that.  Then you can use the
name `read' in your modules for whatever pleases you---and in practice,
you may not always need core `read' anyway.

> A possible solution is to use the first level SMOBs only for
> Guile-defined  ones, and  change the  implementation  of the
> public API  for SMOB  definition to use  an evolution  of my
> subordinate SMOB thing.

Maybe, I don't have a clear picture of the possible solutions.

> @Ludovic Courts
>>> 3c. Every  SMOB must  have a class  and an optional  list of
>>> superclasses, to allow  for methods dispatching.
>>
>>As  you  noted  in  a  recent  post,  SMOBs  types  have  an
>>associated class when GOOPS is  loaded.  So what else do you
>>want?
>
> An optional  list of superclasses  and an interface  to bind
> the class to a symbol in a module.

OK, got it.  The latter is easily addressed, by defining said class in
your module to `(@ (oop goops) )', though it's admittedly not
very elegant.

As for the former, well, I dunno.  It may have unforeseen implications.

> @Ludovic Courts
>>Well, `scm_remember_upto_here ()' is rarely need anyway.
>
> This  is Guideline #2  for a  LFE.  I  wrote this  because I
> recall  to have read  a discussion  about an  alternative GC
> that does not require it.

Right, Boehm's GC is looks for object pointers in registers.

> Anyway,   remembering  "scm_remember_upto_here"   is  really
> annoying.  And it  is needed almost every time  I access the
> client data of a custom SMOB. 

This is strange.  I rarely had to use it, and I can't think of a common
programming pattern where it's useful.

>>(however, we  definitely don't  want one shared  library per
>>module, because of the overhead).
>
> Ugh! The only reason I see to split up is to reduce the size
> of the core shared library.

Shared libraries add memory overhead as they need to be aligned on page
boundaries, symbol lookup overhead, among others.  Ulrich Drepper wrote
a nice article about the pitfalls of writing DSOs (shared libs) but I
can't find it.

> The  same very  bad things  that happen  with all  the other
> languages  that do  not support  bignums.

... which is the raison d'être of Scheme's numeric tower.  :-)

> I am  talking about  the SIN, COS,  TAN, ...  functions, the
> ones 

more spam on extension language fu

[dskr]

Hi,

One of the things I value most about Guile as an extension language is  
the terrific set of facilities for introspection available. I've  
always thought the included readline support was vile (mostly due to  
readline itself) and so

I've been using my own pure-guile completion library for about 7 years.

=> (tab-complete-string "(socke" (current-module))
"(socket"
=> (tab-complete-string "(socket " (current-module))
"(socket family"
=> (tab-complete-string "(socket AF_IN" (current-module))
"(socket AF_INET"
=> (tab-complete-string "(socket AF_INET SOCK_ST" (current-module))
"(socket AF_INET SOCK_STREAM"

The big plus for me is that it has let me build GTK and AJAX  
interfaces that get the benefit of completions
without the C-fu and fport orientation of the readline stuff. The fact  
that this facility can be built in Scheme is a testament to Guile.


What's the point? The point is that Guile is my extension language and  
also my interface for navigating my own sprawling code. I'm concerned  
that many of the changes that would push Guile down the performance  
path also impact the terrific and underused introspection features  
that Guile already has.


Tab completion is a parlor trick. The fact that environments are  
inspectable and that procedure source is recoverable mean that many  
powerful lexical analysis tricks are easier in Guile than in many  
other Scheme environments.


Cheers,
Dan Ridge



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Marco Maggi]

"Roland Orre" wrote:
>How about setting up a voting/wishing site to collect
wishes for
>our visions and desires about guile, and in what way we can
>contribute to this?

If there is interest in having such a thing, it is a matter of
5 minutes with Jottit , they have a
screencast
with a tutorial from the about page.

I am not sure that voting on topics can work though. This is
the Net not a polite society...

One thing that would be useful is to have a page with a roadmap
like this one  for Tcl.

--
Marco Maggi

"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"




___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Marco Maggi]

@Julian Graham
>I've  been  frustrated with  the  situation,  too.  Might  I
>directyourattentiontotheSnowproject?
>(http://snow.iro.umontreal.ca/)

Rules, rules  and rules!  I don't know...  It is not  for me
because I am using C and GOOPS everywhere.


@Mike Gran
>As far  as being  an LFE, 1.8.x  has been a  big improvement
>over 1.6.   The API is  much cleaner when wrapping  stuff by
>hand.

>From what I have seen of 1.6, I agree.

>One  problem here is  that there  does need  to be  a richer
>library  that  is   official  and  downloadable  right  from
>www.gnu.org/software/guile.

This is  impossible.  Too  much coordination work.   TCL has
something like this, but only because ActiveState is backing
it (and they make money with consultancy).

It  would be  an  enormous success  if  every Guile  related
package maintainer  opens a project  at the same  site, like
GNA!, so that all the source code can be found with a search
for the string Guile at that site.

>Much has been done  (GEE, Guile-lib, guile-gtk, all of TTN),
>but,  each  has  its  own  packaging  scheme,  documentation
>scheme.

I feel guilty here because I do not digest GNU Automake, and
I  have built my  own (shock!  horror!) GNU  Make automation
using  its  functions.  And  I  am the  only  one  that  can
understand it... :-/

>None of them  are released in a coordinated  manner with the
>Guile releases themselves.

This is true for different reasons. I, for example, am still
moving  stuff  around  in  GEE.  If  a  roadmap  comes  with
milestones for Guile  1.9, I can try to  make alpha releases
that build with them.

>First, dependencies  on the many libraries  are difficult to
>coordinate.

Ugh! And I am making it worse with GEE 0.4 ...

This is linked with the application deployment problem. With
a  self  executing  archive  we could  distribute  a  single
executable with everything  in it. It is not  a tool that we
can build in an afternoon, though.


@Ludovic Courts
>It took me some time, but  I now think there's no such sharp
>distinction between "LFE" and "SI".

Yep. Probably I am giving too much importance on the size of
the core library.

>> As a SI my opinion is  that some sort of compiler is a must,
>
>An interpreter *can* be much faster than what we have now

Really? Fine!

>>an interface  to bind the class to a symbol in a module.
>
>[...] is  easily addressed, by  defining said class  in your
>module to `(@ (oop goops) )'

Woah! I had not noticed  that the binding is created in (oop
goops).

>> Anyway,   remembering  "scm_remember_upto_here"   is  really
>> annoying.  And it  is needed almost every time  I access the
>> client data of a custom SMOB.
>
>This is strange.  I rarely had  to use it, and I can't think
>of a common programming pattern where it's useful.

SCM
my_func (SCM arg)
{
   client_data_t data = (client_data_t)SCM_SMOB_DATA(arg);

   /* Do something with "data" but do not access "arg"
  anymore. With compiler optimisations the reference
  to the SMOB can disappear.

  If here I call scm_* functions, GC collects the
  SMOB removing the carpet from under my feet and
  if I access "data": crash.

  So:
   */
   scm_remember_upto_here_1(arg);
}

>> If  structs  are  moved  into an  external  shared  library,
>> records can go there, too.
>
>Records are too  common to be removed from  the core: almost
>everyone would end up loading that module.

This surprises  me. I thought  that they were a  rarely used
feature because  they are unschemey  :-) and because  of the
existence of GOOPS.

--
Marco Maggi

"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"




___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: how do you time the execution of a form?

[Andy Wingo]

Hi,

On Fri 30 Nov 2007 09:57, [EMAIL PROTECTED] (Ludovic Courtès) writes:

> "Marco Maggi" <[EMAIL PROTECTED]> writes:
>
>> is there a procedure that prints the execution time of a form?
>> Something like:
>>
>> (time-this (the-form) 1000)
>> ;; run (the-form) 1000 times and prints the result
>
> In Guile-Library, there's `(debugging time)', which exports `time', a
> macro that does exactly what you want.

Docs for that form: http://home.gna.org/guile-lib/doc/ref/debugging.time/

Also, as it turns out (of course I only knew this after I added time to
guile-lib), there is (ice-9 time):

;;; Commentary:

;; This module exports a single macro: `time'.
;; Usage: (time exp)
;;
;; Example:
;; guile> (time (sleep 3))
;; clock utime stime cutime cstime gctime
;; 3.01  0.00  0.00   0.00   0.00   0.00
;; 0

Regards,

Andy
-- 
http://wingolog.org/


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi Marco,

"Marco Maggi" <[EMAIL PROTECTED]> writes:

> Woah! I had not noticed  that the binding is created in (oop
> goops).

He he.  ;-)

> SCM
> my_func (SCM arg)
> {
>client_data_t data = (client_data_t)SCM_SMOB_DATA(arg);
>
>/* Do something with "data" but do not access "arg"
>   anymore. With compiler optimisations the reference
>   to the SMOB can disappear.
>
>   If here I call scm_* functions, GC collects the
>   SMOB removing the carpet from under my feet and
>   if I access "data": crash. 
>
>   So:
>*/
>scm_remember_upto_here_1(arg);
> }

Hmm, right (except if ARG was passed on the stack, which must not be the
case with most ABIs).

OTOH, when `my_func ()' is a subr called by the evaluator, there
definitely are live references to ARG in the heap (argument list) and
probably on the stack too (local variables in `CEVAL ()'), which is why
it rarely hurts in practice...

>>Records are too  common to be removed from  the core: almost
>>everyone would end up loading that module.
>
> This surprises  me. I thought  that they were a  rarely used
> feature because  they are unschemey  :-) and because  of the
> existence of GOOPS.

Well, maybe my statement was too strong.  At least I do use records a
lot.  Any programming language needs vector-like data structures, and
records provide a convenient interface to them in many scenarios.

Thanks,
Ludovic.



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Mike Gran]

> On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:

> > Pre-answer to all: the most important thing is to make clear
> > what are  the priorities.  With a  "language for extensions"
> > (LFE)   there  are  certain   priorities,  with   a  "Scheme
> > implementation"  (SI) there are  others. I  fear that  if no
> > choice is made Guile will be wiped out by other Schemes.

As far as being an LFE, 1.8.x has been a big improvement over 1.6.
The API is much cleaner when wrapping stuff by hand. 

> From: Roland Orre <[EMAIL PROTECTED]>

> Today, however, I find that there are nearly no extension
> libraries available for guile. As a shell scripting language
> I prefer python because it has a very simple and clean
> shell interface. To extend my applications beyond real number
> crunching with e.g. graphical interphases (currently working
> with xlib...) I feel a limitation and have more and more often
> looked upon python where a lot of libraries are available for
> GUI, database and you name it.

One problem here is that there does need to be a richer library
that is official and downloadable right from
www.gnu.org/software/guile.  Unit test, documentation, 
cgi, http, sql, md5, utf8, xml, and perhaps pickle.

Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), 
but, each has its own packaging scheme, documentation
scheme.  None of them are released in a coordinated manner 
with the Guile releases themselves. 

This goes back to the packaging problem.  After I've written a program, 
I'd like to give it away for others to use.  Giving code away in a scripting 
language should be easy.  It isn't easy here. 

First, dependencies on the many libraries are
difficult to coordinate.

Second, most non-trivial scripts require the whole of the configure, 
make, make install, LD_LIBRARY_PATH, %load-path overhead.

Where is the analog of a Java jar file?

Apologies if my rant has drifted off topic.

Thanks,

Mike Gran






___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Daniel Ridge]

On mike's question about the natural analog of the jar file, I find  
that one of the big binary distribution hurdles for guile code has  
been static paths baked everywhere. Static, absolute paths get baked  
into libtool .la files when the underlying platform does not  
necessarily require it.


Guile itself contributes to this relocatability problem with the way  
guile-config uses %guile-build-info,%library-dir,%package-data-dir,% 
site-dir.


I use guile as an extension language in all of my codes. In almost  
every case I need to build guile alongside my application. Guile's  
relocatability problems become my own. I hack boot-9.scm to prefer a  
prefix from the environment to the one baked into % guile-build-info.  
My programs are typically wrapped with a shell script that figures out  
where they live and updates LD_LIBRARY_PATH and the prefix for guile  
and execs the prog.


When I use guile to load shared objects, I'm not demonstrating a  
preference for Scheme hacking vs extension hacking, as some would  
claim. Instead, I'm using it as as as 'extension linker' that grabs  
code needed by my underlying application. Guile often just marshalls  
args from C through Scheme back to C. Along the way, many calls become  
transparent RPCs. Guile is absolutely excellent at this. In many  
cases, I use guile to marshall args to RPCs evaluated in other Scheme  
runtimes that play less well with C.


With the elimination of just a couple of  these problems, guile and  
guile extended apps run quite nicely from live CDs, loopback mounted  
disk images, and even Apple's relocatable application bundles.


On Dec 5, 2007, at 10:40, Mike Gran <[EMAIL PROTECTED]> wrote:





On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:



Pre-answer to all: the most important thing is to make clear
what are  the priorities.  With a  "language for extensions"
(LFE)   there  are  certain   priorities,  with   a  "Scheme
implementation"  (SI) there are  others. I  fear that  if no
choice is made Guile will be wiped out by other Schemes.


As far as being an LFE, 1.8.x has been a big improvement over 1.6.
The API is much cleaner when wrapping stuff by hand.


From: Roland Orre <[EMAIL PROTECTED]>



Today, however, I find that there are nearly no extension
libraries available for guile. As a shell scripting language
I prefer python because it has a very simple and clean
shell interface. To extend my applications beyond real number
crunching with e.g. graphical interphases (currently working
with xlib...) I feel a limitation and have more and more often
looked upon python where a lot of libraries are available for
GUI, database and you name it.


One problem here is that there does need to be a richer library
that is official and downloadable right from
www.gnu.org/software/guile.  Unit test, documentation,
cgi, http, sql, md5, utf8, xml, and perhaps pickle.

Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
but, each has its own packaging scheme, documentation
scheme.  None of them are released in a coordinated manner
with the Guile releases themselves.

This goes back to the packaging problem.  After I've written a  
program,
I'd like to give it away for others to use.  Giving code away in a  
scripting

language should be easy.  It isn't easy here.

First, dependencies on the many libraries are
difficult to coordinate.

Second, most non-trivial scripts require the whole of the configure,
make, make install, LD_LIBRARY_PATH, %load-path overhead.

Where is the analog of a Java jar file?

Apologies if my rant has drifted off topic.

Thanks,

Mike Gran






___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: [announce] GEE/Streams 0.1

[Andy Wingo]

Hi,

On Tue 04 Dec 2007 20:34, "Marco Maggi" <[EMAIL PROTECTED]> writes:

> Guile already  comes with the (ice-9  streams) module, which
> allows Scheme level code to iterate over non--list sequences
> of values.  GEE/Streams is a C language re-implementation of
> the same  interface that  allows both Scheme  and C  code to
> define streams.

Haven't looked closely at what you have, but have you seen the paper:

  http://cm.bell-labs.com/cm/cs/who/wadler/papers/lazyinstrict/lazyinstrict.ps

?

Andy
-- 
http://wingolog.org/


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Julian Graham]

I've been frustrated with the situation, too.  Might I direct your
attention to the Snow project?  (http://snow.iro.umontreal.ca/)

One of the difficulties with these things is that they kind of require
a certain critical mass to establish themselves, and, so far,
nothing's really done that.  (SLIB, maybe?)  One thing that seems
apparent to me, though, is that any good packaging / library solution
is going to be cross-interpreter, so we should pay attention to what's
going on with PLT, Chicken, etc.


On Dec 5, 2007 10:40 AM, Mike Gran <[EMAIL PROTECTED]> wrote:
>
>
> > On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
>
> > > Pre-answer to all: the most important thing is to make clear
> > > what are  the priorities.  With a  "language for extensions"
> > > (LFE)   there  are  certain   priorities,  with   a  "Scheme
> > > implementation"  (SI) there are  others. I  fear that  if no
> > > choice is made Guile will be wiped out by other Schemes.
>
> As far as being an LFE, 1.8.x has been a big improvement over 1.6.
> The API is much cleaner when wrapping stuff by hand.
>
> > From: Roland Orre <[EMAIL PROTECTED]>
>
> > Today, however, I find that there are nearly no extension
> > libraries available for guile. As a shell scripting language
> > I prefer python because it has a very simple and clean
> > shell interface. To extend my applications beyond real number
> > crunching with e.g. graphical interphases (currently working
> > with xlib...) I feel a limitation and have more and more often
> > looked upon python where a lot of libraries are available for
> > GUI, database and you name it.
>
> One problem here is that there does need to be a richer library
> that is official and downloadable right from
> www.gnu.org/software/guile.  Unit test, documentation,
> cgi, http, sql, md5, utf8, xml, and perhaps pickle.
>
> Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
> but, each has its own packaging scheme, documentation
> scheme.  None of them are released in a coordinated manner
> with the Guile releases themselves.
>
> This goes back to the packaging problem.  After I've written a program,
> I'd like to give it away for others to use.  Giving code away in a scripting
> language should be easy.  It isn't easy here.
>
> First, dependencies on the many libraries are
> difficult to coordinate.
>
> Second, most non-trivial scripts require the whole of the configure,
> make, make install, LD_LIBRARY_PATH, %load-path overhead.
>
> Where is the analog of a Java jar file?
>
> Apologies if my rant has drifted off topic.


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Call for contributions to update the project list

[Ludovic Courtès]

Hi,

With all these lengthy debates, I think time has come to update the
Guile project page.  :-)

I started a new project page (almost) from scratch:

  http://www.gnu.org/software/guile/gnu-guile-projects.html

The previous one is still available at:

  http://www.gnu.org/software/guile/old-gnu-guile-projects.html

The rationale for the new page is:

  * to list only reasonably active projects, preferably projects that
work with 1.8, so that the list is really helpful to newcomers;

  * to simplify list entries to make them more perennial, faster to
read, and hopefully easier to update;

  * to try to have a better categorization (previous page had
"Libraries" as a category, which is way too vague IMO).

So far very few projects are listed (and I'm involved in several of
them, I'm shameless ;-)).

People working on Guile-related projects, please provide updated entries
using the following HTML format:

  http://PROJECT-URL";>PROJECT-NAME
  
  description
  A few sentences describing the project...
  license
  A free software licence
  requires
  a list of dependencies, e.g., Guile 1.8
  

Make sure to not depart from this format so that it's easy to integrate.
In addition, tell what category your project belongs to.  If your
project does not fit well in the existing categories, please propose a
new category.

Thanks in advance,
Ludovic.



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Andy Wingo]

Greets,

I have had sufficient wine to respond.

On Tue 04 Dec 2007 07:50, "Marco Maggi" <[EMAIL PROTECTED]> writes:

> I think that  it is time for a chat on  the future of Guile.

Sure, why not. (Stop justifying your emails, it looks stupid in
fixed-width fonts.)

> [Guile] does not have to [compete] because, like it or not, Guile is a
> language for extensions.

Totally. This is what defines guile. (Making it a good standalone scheme
is another goal.)

> 3b. Death to  structs!  IMO they were "an  attempt", but the
> resulting code is awful (sorry, but can you disagree?). 

No, I cannot :) But solving this would go to solving a lot of your other
points. Record types are the hip disjoint type in Schemeland, and you
certainly need a way to deal with them from Guile. Structs might not be
it, but you will need something smarter than SMOBs... Suggestions?

> 4. If  a garbage  collector allows  to remove  the  need for
>"scm_remember_upto_here"  it must be  adopted even  if it
>makes Guile slower  and it raises memory usage  a bit (or
>more than a bit). 

Who cares? I have written thousands and thousands of lines of guile
extensions in C. I have not yet had to use this. Perhaps it's just dumb
luck or something.

> 5. Guile  must be loadable/unloadable  as a  shared library.
>Use case: once I have read a configuration file or a sexp
>data file, I do not need it anymore.

If you aren't running your app with Guile extensions / code, you don't
need a whole scheme interpreter to read s-expressions...

> 6. More modularity. 

Sure, but any breaking of Guile into modules without thinking about
syncase is half-baked. This is one bit that r6rs definitely got right
IMO.

> 7a.  It makes no sense to discuss if Guile should go R6RS or
> not.   The  only meaningful  discussion  is about  which
> hooks are needed in  Guile's code to make those features
> available   as   loadable   modules.   (Yes,   this   is
> difficult).

Oh, I don't know. Standards are definitely relevant, whether it's ERR5RS
or R6RS or whatever. The guile hacker community is a small part of the
scheme hacker community, we should cooperate if at all possible.

In summary, may I unfairly caricature your attitude: "Guile does not
follow a number of 'modern' norms, and therefore we should update it."
Unfortunately for you Guile is widely deployed and coded to; those users
also define "what guile is". Radical changes to the C interface are not
going to be forthcoming.

Just another Guile hacker,

Andy
-- 
http://wingolog.org/


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Roland Orre]

On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
> Pre-answer to all: the most important thing is to make clear
> what are  the priorities.  With a  "language for extensions"
> (LFE)   there  are  certain   priorities,  with   a  "Scheme
> implementation"  (SI) there are  others. I  fear that  if no
> choice is made Guile will be wiped out by other Schemes.

I agree with Marco, that the reason for choosing a particular
language is essential. My choice of guile is based upon my
earlier choice of scm (Aubrey Jaffer) as extension language as
scm was the basis for guile.

At that time (early 90ies) I wanted a small and efficient scheme
with a simple C interface. The choices were basically between ELK
and scm as I remember, but as I remember scm had much better
performance and some other benefits.

My strategy is to write the high level scripts in scheme and
heavy number crunching (data mining) stuff in C. For this purpose
scm and later guile has served very well.

Today, however, I find that there are nearly no extension
libraries available for guile. As a shell scripting language
I prefer python because it has a very simple and clean
shell interface. To extend my applications beyond real number
crunching with e.g. graphical interphases (currently working
with xlib...) I feel a limitation and have more and more often
looked upon python where a lot of libraries are available for
GUI, database and you name it.

However, I like scheme and I think I ideally would like an
environment where I could use scheme,C and python arbitrarily.
I consider that scheme is a much cleaner language than e.g. python,
and have several advantages.

How about setting up a voting/wishing site to collect wishes for
our visions and desires about guile, and in what way we can
contribute to this? For my own I haven't done much, I added the
sorting routines a few years ago and the first apropos function
but if there was a way to make a "language independent" nucleus
where applications could easily be written in e.g. scheme,
python or possible other popular langauges like ruby I could
possibly contribute to this.

Could e.g. the goops package be used for implementation of a
common object structure as python?

OK, it is not for granted that a multi language platform
may be optimal, other ideas?

/Roland





___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user