This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
RE: guile-occam and question
- To: "'Marius Vollmer'" <mvo at zagadka dot ping dot de>
- Subject: RE: guile-occam and question
- From: "Arjan J. Molenaar" <A dot J dot Molenaar at xirion dot nl>
- Date: Mon, 11 Sep 2000 09:26:51 +0200
- Cc: "'guile-user at gnu dot org'" <guile-user at gnu dot org>
- List-Id: <guile-user.gnu.org>
Marius Vollmer [mailto:mvo@zagadka.ping.de]
> "Arjan J. Molenaar" <A.J.Molenaar@xirion.nl> writes:
>
> > 1. I can make it a module by adding something like (define-module
> > ...) at the beginning of the file. But where should I put the file
> > if I want it to be accessed as a module from any other scheme
> > program?
>
> You should install your file in a location where Guile can
> automatically find it. Whenever a module is requested that is not
> already present in the system, Guile looks in its load path and tries
> to load a file that will define the module.
>
> The current load path is in the variable %load-path.
>
> When your module is named `(foo bar)', say, then you should make a
> directory named "foo" in some directory that is on the load path and
> put a file named "bar.scm" in it. The file "bar.scm" would contain a
> `(define-module (foo bar))'.
>
> > 2. Where should I add docstrings for my scheme functions/macros and
> > how can I generate nice docs from them?
>
> The docstring is the first form of the body of a function, like so:
>
> guile> (define (foo) "This is foo." 12)
> guile> (help ,foo)
> This is foo.
>
> > 3. How can I make SMOB's from scheme code? I'd like to see a channel
> > as a special type. Otherwise: how can I check if something is indeed
> > a channel?
>
> You don't use SMOBs from Scheme code. For new data types, using GOOPS
> is the best options. It is on the module `guile-oops'.
I'll try that.
> > 4. Is this the way scheme code is to be written ;-)?
>
> Hmm, no. ;)
I was afraid so...
> I'd say you are using way too much macros. Most of your macros
> can just be functions. Functions are generally preferable to macros
> when you can use them.
>
> Among your exported definitions, only `define-channel', `seq', `par',
> and `alt' should be macros, the rest can be functions. They way you
> define `seq' is not really clean, you should rather use
>
> (defmacro-public seq forms
> `(begin ,@forms))
>
> This is because macros are not really first-class objects that can be
> passed around. They happen to be it right now, but you shouldn't use
> that fact.
Thanks. I've been writing some stuff over the weekend and it already moves from macro's to functions in a natural way ;-).
> While I don't have the time to rewrite your code, I think it would be
> an excellent exercise to do so. :-) Any takers?
Working on it...
Arjan
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user