unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Christine Lemmer-Webber <cwebber@dustycloud.org>,
	Chris Vine <vine35792468@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: Ideas for making Guile easier to approach
Date: Wed, 09 Feb 2022 22:05:05 +0100	[thread overview]
Message-ID: <0e1b4d4f7b0e097870326da44d4f51be3b6a1b98.camel@telenet.be> (raw)
In-Reply-To: <87o83fdeqz.fsf@dustycloud.org>

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

Christine Lemmer-Webber schreef op wo 09-02-2022 om 10:18 [-0500]:
> We had:
> 
>   (define-module (my-module)
>     #:use-module (guile match)
>     #:use-module (guile format)
>     #:use-module (srfi list-utils)
>     #:use-module (srfi records)
>     #:use-module (srfi args-fold)
>     #:use-module (srfi streams)
>     #:use-module (srfi tests))
> 
> Much easier to follow, no?

The RnRS reserved the (srfi ...) namespace for the SRFI process,
possibly adding our own names here would be against the standard.

OTOH, standards in Scheme-land seem to be ‘merely’ friendly suggestions
and conventions, and there doesn't seem to be any backwards
incompatibility problems, so maybe not a problem.

A potential problem is that people using 'library' and 'define-library'
forms for portability with other Schemes would find their code to be
unportable when using (srfi SOME-NAME), although that's easily resolved
whenever it happens and perhaps (srfi SOME-NAME) will eventually become
standard.

Greetings,
Maxime.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  parent reply	other threads:[~2022-02-09 21:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 12:19 Newbie thoughts on Guile Hall + Guix Blake Shaw
2022-02-08 19:46 ` Chris Vine
2022-02-09 15:18   ` Ideas for making Guile easier to approach Christine Lemmer-Webber
2022-02-09 20:33     ` Daniel Tornabene
2022-02-09 21:05     ` Maxime Devos [this message]
2022-02-09 23:06       ` Keith Wright
2022-02-09 21:05     ` Olivier Dion via General Guile related discussions
2022-02-09 21:07     ` Maxime Devos
2023-10-05 14:15       ` Dr. Arne Babenhauserheide
2022-02-09 23:01     ` Chris Vine
2022-02-10  0:56     ` Timothy Sample
2022-02-10 10:01       ` Ricardo Wurmus
2022-02-10  1:32     ` Blake Shaw
2022-02-10  2:02     ` paul
2022-02-10 11:27     ` Mikael Djurfeldt
2022-02-10 14:34       ` Leo Butler
2022-02-10 15:58         ` Mikael Djurfeldt
2022-02-10 18:25         ` Olivier Dion via General Guile related discussions
2023-09-27 19:29     ` Christine Lemmer-Webber
2023-09-28 12:30       ` Maxime Devos
2022-02-09  6:28 ` Newbie thoughts on Guile Hall + Guix Catonano

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=0e1b4d4f7b0e097870326da44d4f51be3b6a1b98.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=cwebber@dustycloud.org \
    --cc=guile-user@gnu.org \
    --cc=vine35792468@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).