unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: wolf <wolf@wolfsden.cz>
To: Taylan Kammer <taylan.kammer@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: Does declaration order matter in guile?
Date: Tue, 14 Feb 2023 21:00:47 +0100	[thread overview]
Message-ID: <Y+vob884XBXd9h4V@ws> (raw)
In-Reply-To: <3c8f41c0-2978-1ab8-b265-a8ab59030929@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]

Hello,

first, let me thank you for thorough explanation, it helped and I (hopefully)
now have better understanding. Few more questions are below.

On 2023-02-12 20:52:16 +0100, Taylan Kammer wrote:
> On 12.02.2023 19:46, wolf wrote:
> 
> > So, I have few questions I would like to ask:
> > 
> > 1. When does order matter? What is going on here?
> 
> Heya.
> 
> The order matters in this case because the SRFI-9 implementation in Guile defines
> syntax (macros) rather than just variables bound to procedures.
> 
> If you use an undefined variable in a lambda body like '(define (blah) <HERE>)'
> then it will be compiled into a variable lookup in the global environment, so you
> can make it work by later defining that variable to something appropriate.
> 
> However, the "macro expansion" needs to happen immediately, so what happens here is:
> 
> 1. (foo y) is compiled into code that will:
>    - Look up the global variable 'foo'
>    - Try to "apply" its value to the value of 'y'
> 
> 2. You then bind 'foo' to a "syntax transformer" (macro) in the global environment.
> 
> 3. When the code is executed, it tries to apply the syntax transformer as if it were
>    a procedure or another type that can be "applied," which fails, because syntax
>    transformers are not a type that can be "applied" like procedures and such.
> 
> (The error message would be clearer if it said "is not a procedure" instead of "wrong
> type to apply" but there's other types in Guile that can be "applied" and not just
> procedures, hence that slightly less clear error message.)
> 
> What *needs* to happen for it to work instead, is:
> 
> 1. You bind 'foo' to the syntax transformer.
> 
> 2. During the compilation of (foo y), the compiler calls the syntax transformer to
>    affect the generation of code, so it will do the right thing.
> 

Interesting, I think I understand the difference. So in some ways this can be
compared to the C pre-processor? Is there a way to view the resulting code
after all the transformations were applied?

> > 2. Why does guile recommend SRFI-9 over the R6RS records? They seem less
> >    verbose and more robust. At least to novice like me.
> 
> SRFI-9 is smaller and more widespread.  Ultimately, it's a matter of taste, since
> both have advantages and disadvantages, and some things that are either an advantage
> or a disadvantage depending on who you ask. :-)
> 
> > 3. What does guile implement by default? There are --r6rs and --r7rs arguments,
> >    what scheme is used when neither is supplied? R5RS? Sorry if this is stupid
> >    question, the scheme landscape seems... complicated.
> 
> No worries, not a stupid question at all.  What Guile uses by default could be called
> "Guile Scheme."  It neither completely fulfills the requirements of R7RS or R6RS, nor
> is it limited to either.  I think that's what most Scheme implementations do...  The
> standardization of Scheme is in a sad state.

Meaning that if I want to use the many guile- libraries available under guix
and elsewhere, the most pragmatic approach would be to just not care about R6RS
vs R7RS all that much, and just do what guile manual recommends. Correct?

> 
> > 4. Is the (install-r6rs!) global and affecting all reading from that point on
> >    or is it scoped to the file being currently read? I ask because I am curious
> >    if I can mix files using R6RS and R7RS in one program.
> 
> I'm not 100% sure on this one, but I don't think it can affect the reading of the file
> it appears in, because the entirety of reading happens before anything is executed.
> 
> It should affect *explicit* reading you do from that point on, i.e., what the 'read'
> procedure will do with its input.
> 
> > Thank you very much,
> > W.
> > 
> 
> You're welcome, and have fun with Guile!

Thanks again and have a nice day,
W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-02-14 20:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-12 18:46 Does declaration order matter in guile? wolf
2023-02-12 19:52 ` Taylan Kammer
2023-02-13  8:05   ` Sascha Ziemann
2023-02-13 10:44     ` Dr. Arne Babenhauserheide
2023-02-13 17:07     ` Maxime Devos
2023-02-14 20:00   ` wolf [this message]
2023-02-14 20:26     ` Dr. Arne Babenhauserheide
2023-02-13 17:10 ` Maxime Devos

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=Y+vob884XBXd9h4V@ws \
    --to=wolf@wolfsden.cz \
    --cc=guile-user@gnu.org \
    --cc=taylan.kammer@gmail.com \
    /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).