[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: guile-occam and question
From: |
Arjan J. Molenaar |
Subject: |
RE: guile-occam and question |
Date: |
Mon, 11 Sep 2000 09:26:51 +0200 |
Marius Vollmer [mailto:address@hidden
> "Arjan J. Molenaar" <address@hidden> 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