This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: guile-occam and question


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]