unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Seeking Advice on syntax/macros in separate files
@ 2021-03-01 18:03 Andrew Burgess
  2021-03-02  8:23 ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Burgess @ 2021-03-01 18:03 UTC (permalink / raw)
  To: guile-user

Hello,

I'm trying to understand how I am supposed to make use of
define-syntax type constructs (or possibly, when working with older
code define-macros) in a code base split over many files

I'm updating a code base from guile 1.8.8, and currently having it
running successfully on guile 2 and 3.  With the new auto-compilation
in guile 2 and 3 I'm now trying to work out how users will invoke the
tool.

My concerns are based on this page of the guile manual:

  https://www.gnu.org/software/guile/manual/html_node/Compilation.html#Compilation

specifically this:

  "... Guile does not yet do proper dependency tracking, so that if
  file a.scm uses macros from b.scm, and b.scm changes, a.scm would
  not be automatically recompiled."

And just to confirm what the manual says, here's my test:

  $ cat f1.scm
  (use-modules (f2))
  (foo 123)
  (define-accessor xxx 3)
  (xxx 9)

  $ cat f2.scm
  (define-module (f2)
    #:export (foo)
    #:export-syntax (define-accessor))

  (define (foo arg)
    (display "foo: ")
    (display arg)
    (newline))

  (define-syntax-rule (define-accessor name n)
    (define (name obj)
      (display "accessor for field: ")
      (display n)
      (display " in ")
      (display obj)
      (newline)))

I'm then running `guile -L . -s f1.scm`, and indeed, as the manual
suggests, changes to `foo' are visible, but, unless I force
recompilation, changes to `define-accessor` are not.

I also tried replacing the use of `use-modules` with raw `include`,
but this is even worse, as now changes to `foo` are not seen either.

My choice of `define-accessor' is not random, this is drawn from an
example in the guile manual here:

  https://www.gnu.org/software/guile/manual/html_node/Vtable-Example.html

And here lies my confusion:

First, let me say I'm pretty much a scheme/guile newbie, but I thought
that macros (or syntax extensions) were a huge part of the power of
languages like scheme.  The guile manual itself uses them to show how
an object like system could be created.

However, it would seem natural to place such a system into a separate
file, presumably as a module.

But, and here's my problem: the first time I ship this software to the
user, everything's fine.  But if I ship them an update that touches
any of the macros, then I'm stuck.  The user now needs to be aware
that they have to take special steps in order to ensure the previously
compiled code is deleted.  And that's not great for a user experience.

So, my current thinking is to wrap the invocation of the guile script
in a shell script, which _always_ forces recompilation.  But, if I'm
doing that, I may as well just disable compilation completely.  But
this doesn't seem right.

So, I'm sure I must be missing something here.  How do others deal
with this situation?

- Am I missing an obvious solution for working with syntax/macros and
  multiple files?

- Am I wrong to think that syntax/macros are such a big part of the
  language?  Should I be limiting syntax/macro usage to small scopes,
  i.e. within a single file, and only true defines should be exposed
  outside of a file?

- Maybe Guile just isn't designed for writing large, multi-file
  projects?

- Maybe Guile projects are only ever shipped to users who are happy
  managing the compile cache themselves, e.g. more power users, and
  not really for general users?

As I said, I'm fairly new to guile/scheme so my expectation here is
that it's me that's missing something here.

Thank you for any help you can offer,

Andrew



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Seeking Advice on syntax/macros in separate files
  2021-03-01 18:03 Seeking Advice on syntax/macros in separate files Andrew Burgess
@ 2021-03-02  8:23 ` Ludovic Courtès
  2021-03-02  9:47   ` Andrew Burgess
  0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2021-03-02  8:23 UTC (permalink / raw)
  To: Andrew Burgess; +Cc: guile-user

Hi Andrew,

Andrew Burgess <andrew.burgess@embecosm.com> skribis:

> My concerns are based on this page of the guile manual:
>
>   https://www.gnu.org/software/guile/manual/html_node/Compilation.html#Compilation
>
> specifically this:
>
>   "... Guile does not yet do proper dependency tracking, so that if
>   file a.scm uses macros from b.scm, and b.scm changes, a.scm would
>   not be automatically recompiled."

Yes.  Concretely, that means you can either use Makefiles or similar
(like with most other languages) or turn off auto-compilation (with
‘--no-auto-compile’ or with ‘GUILE_AUTO_COMPILE=0’).

> So, my current thinking is to wrap the invocation of the guile script
> in a shell script, which _always_ forces recompilation.  But, if I'm
> doing that, I may as well just disable compilation completely.  But
> this doesn't seem right.
>
> So, I'm sure I must be missing something here.  How do others deal
> with this situation?

Common practice is to have makefiles or similar as part of your
software.  When you run “make”, it runs ‘guild compile’ to compile all
your Scheme source; upon “make install”, both .scm and .go files are
installed.

Here’s an example that does that using the GNU autotools:

  https://notabug.org/cwebber/guile-gcrypt

For a pure Guile project, Guile Hall helps get started:

  https://gitlab.com/a-sassmannshausen/guile-hall

> - Am I missing an obvious solution for working with syntax/macros and
>   multiple files?
>
> - Am I wrong to think that syntax/macros are such a big part of the
>   language?  Should I be limiting syntax/macro usage to small scopes,
>   i.e. within a single file, and only true defines should be exposed
>   outside of a file?

Macros are very useful and a salient point of Scheme, but there are many
other things in the language.  :-)

> - Maybe Guile just isn't designed for writing large, multi-file
>   projects?

There are large projects written in Guile, such as Guix.

> - Maybe Guile projects are only ever shipped to users who are happy
>   managing the compile cache themselves, e.g. more power users, and
>   not really for general users?

Like I wrote, non-trivial projects often install .go files alongside
.scm files such that things never go through ~/.cache/guile.

HTH!

Ludo’.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Seeking Advice on syntax/macros in separate files
  2021-03-02  8:23 ` Ludovic Courtès
@ 2021-03-02  9:47   ` Andrew Burgess
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Burgess @ 2021-03-02  9:47 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guile-user

* Ludovic Courtès <ludo@gnu.org> [2021-03-02 09:23:33 +0100]:

> Hi Andrew,
> 
> Andrew Burgess <andrew.burgess@embecosm.com> skribis:
> 
> > My concerns are based on this page of the guile manual:
> >
> >   https://www.gnu.org/software/guile/manual/html_node/Compilation.html#Compilation
> >
> > specifically this:
> >
> >   "... Guile does not yet do proper dependency tracking, so that if
> >   file a.scm uses macros from b.scm, and b.scm changes, a.scm would
> >   not be automatically recompiled."
> 
> Yes.  Concretely, that means you can either use Makefiles or similar
> (like with most other languages) or turn off auto-compilation (with
> ‘--no-auto-compile’ or with ‘GUILE_AUTO_COMPILE=0’).
> 
> > So, my current thinking is to wrap the invocation of the guile script
> > in a shell script, which _always_ forces recompilation.  But, if I'm
> > doing that, I may as well just disable compilation completely.  But
> > this doesn't seem right.
> >
> > So, I'm sure I must be missing something here.  How do others deal
> > with this situation?
> 
> Common practice is to have makefiles or similar as part of your
> software.  When you run “make”, it runs ‘guild compile’ to compile all
> your Scheme source; upon “make install”, both .scm and .go files are
> installed.
> 
> Here’s an example that does that using the GNU autotools:
> 
>   https://notabug.org/cwebber/guile-gcrypt
> 
> For a pure Guile project, Guile Hall helps get started:
> 
>   https://gitlab.com/a-sassmannshausen/guile-hall
> 

Many thanks.  I knew I must be missing something.  It never occurred
to me that I should be pre-compiling the project.

I'll investigate the two solutions you've proposed.

Thanks again,
Andrew



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-03-02  9:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-01 18:03 Seeking Advice on syntax/macros in separate files Andrew Burgess
2021-03-02  8:23 ` Ludovic Courtès
2021-03-02  9:47   ` Andrew Burgess

unofficial mirror of guile-user@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-user/0 guile-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-user guile-user/ https://yhetil.org/guile-user \
		guile-user@gnu.org
	public-inbox-index guile-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.user
	nntp://news.gmane.io/gmane.lisp.guile.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git