From: "Marco Maggi" <marco.maggi-ipsu@poste.it>
To: "guile-user" <guile-user@gnu.org>
Subject: Re: the future of Guile
Date: Wed, 5 Dec 2007 23:32:24 +0100 [thread overview]
Message-ID: <JSLLA0$76B5CC32269412E85DAE8087202702C6@poste.it> (raw)
@Julian Graham
>I've been frustrated with the situation, too. Might I
>direct your attention to the Snow project?
>(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) <SMOB-NAME>)'
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
next reply other threads:[~2007-12-05 22:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-05 22:32 Marco Maggi [this message]
2007-12-05 22:56 ` the future of Guile Ludovic Courtès
[not found] <cmu-lmtpd-4316-1197047238-3@mail-imap2.uio.no>
2007-12-07 17:42 ` Kjetil S. Matheussen
-- strict thread matches above, loose matches on Subject: below --
2007-12-07 6:28 Marco Maggi
[not found] <cmu-lmtpd-27643-1196871540-1@mail-imap2.uio.no>
2007-12-06 14:52 ` Kjetil S. Matheussen
2007-12-05 21:02 Marco Maggi
2007-12-05 15:40 Mike Gran
2007-12-05 16:05 ` Julian Graham
2007-12-05 16:18 ` Daniel Ridge
2007-12-05 20:41 ` Ludovic Courtès
2007-12-05 9:01 Marco Maggi
2007-12-05 14:19 ` Roland Orre
2007-12-05 20:28 ` Ludovic Courtès
[not found] <34.F3.20110.D6985574@avas19>
2007-12-04 19:54 ` the future of guile Daniel Llorens del Río
[not found] <cmu-lmtpd-7104-1196779864-1@mail-imap2.uio.no>
2007-12-04 18:08 ` the future of Guile Kjetil S. Matheussen
2007-12-04 18:34 ` Kjetil S. Matheussen
2007-12-04 20:06 ` Roland Orre
2007-12-04 20:42 ` Ludovic Courtès
2007-12-04 22:30 ` Kjetil S. Matheussen
[not found] <F8.1B.18780.B4965574@avas11>
2007-12-04 15:55 ` the future of guile Daniel Llorens del Río
2007-12-04 6:50 the future of Guile Marco Maggi
2007-12-04 8:48 ` Stephen Compall
2007-12-04 12:41 ` Ludovic Courtès
2007-12-04 14:50 ` Bill Schottstaedt
2007-12-04 15:30 ` Ludovic Courtès
2007-12-04 23:00 ` Neil Jerram
2007-12-05 23:11 ` Andy Wingo
2007-12-06 19:48 ` Mikael Djurfeldt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='JSLLA0$76B5CC32269412E85DAE8087202702C6@poste.it' \
--to=marco.maggi-ipsu@poste.it \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).