* Re: Ideas for making Guile easier to approach
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
` (8 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Daniel Tornabene @ 2022-02-09 20:33 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: guile-user
Really grateful for that email, I agree on the Racket manuals, though I
totally get the PLT comment of your friend. I also had somehow never heard
of guile studio, really excited to check that out.
Guide vs Reference
As I put in the other email I have alot of thoughts about this too! More
than I think I'd care to put in a mailing list, going to save that for a
blog post. What I will say is that, while some may bemoan too many "how do
I use X" blogpost tutorials or even essay/book length tutorials in software
communities, guile could definitely use some of that now and I would be
glad to see others ideas around pedagogy or narrative structure!
Wisp
Don't really know what that is.
SRFIs
Not invested but I do think that your example is clearer.
On Wed, Feb 9, 2022 at 2:12 PM Christine Lemmer-Webber <
cwebber@dustycloud.org> wrote:
> I've been appreciating the feedback in this thread about Guile; I'm
> starting a new topic name because I think we've deviated from talking
> about Guile Hall and more about Guile.
>
> Some stuff below.
>
> Chris Vine <vine35792468@gmail.com> writes:
>
> > On Tue, 08 Feb 2022 19:19:06 +0700
> > Blake Shaw <blake@nonconstructivism.com> wrote:
> >
> >> Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
> >> > I don't think it's fair to say that using packages in Guile just as
> >> > easy/hard as other languages. Python / Javascript make this incredibly
> >> > easy, and their ecosystem is evidence for that success. Their package
> >> > managers have flaws, but they have benefits too, and those benefits
> >> > would be great for Guile.
> >>
> >> I would just like to tag onto this convo that I agree that its not fair
> >> to say that Guile is easy and will quickly bless those who endeavor to
> >> learn it with superpowers. My experience w/Racket was very smooth and I
> >> got working in it very quickly. I was a contracted to work on a project
> in
> >> Python a few months ago and without ever studying it I was able to
> >> start doing production work in it (ridiculous how intuitive it is,
> >> really). Before I started learning Guile I read Edwin Brady's book on
> >> Idris and found Idris much easier to get from start to end of small
> >> projects I was working on (because there is a well written book on it).
> >>
> >> While Guile has become my favorite programming language, it took me
> >> several months to learn how to navigate & figure out how to navigate the
> >> SRFIs, how to plan a program so that I can know what to expect along the
> >> way (what features I'll need to implement myself, etc) before I was able
> >> to get productive in it beyond the realm of Guix. And I think most would
> >> agree that Scheme is a less advanced language than Idris (I did some
> >> category theory in school so I have some intuition for the ideas, but
> >> still). And to be honest, I still hit plenty of road blocks.
> >>
> >> There were definitely some times where I was digging around trying to
> >> figure out how to do things and came across messages in the archives
> >> saying "its so easy you just do [vague hand wavy explanation]". And I
> >> found that quite frustrating, like there is an insularity meant to weed
> >> out the bad apples. And when this topic popped up on the guix list a few
> >> weeks ago some others expressed similar concerns, folks who are doing
> >> very impressive work. A programming language should never make
> >> programmers feel dumb -- it should make us feel empowered!
> >
> > Everything is capable of improvement but the guile manual is a manual
> > and not I think primarily intended as a language tutorial (although
> > Chapter 3 of the manual does have a very cursory introduction to the
> > scheme language). If you are looking for a tutorial, I suggest reading
> > https://www.scheme.com/tspl4/ . It covers the R6RS flavour, but at the
> > tutorial level I don't think the various current standard flavours
> > (R5RS, R6RS and R7RS) matter too much.
> >
> > I would be reluctant to see the manual turned into a tutorial if that
> > were to mean abridging any of its current completeness.
>
> The manual does contain a very brief tutorial, but it's brief... the
> Guix cookbook also contains something short. Both seem a bit lacking to
> me but they could be starting points.
>
> Regarding the manual as a manual, I actually personally like the Guile
> manual a lot. I think it's very well written. But it's a reference
> guide.
>
> But I do remember finding it overwhelming and confusing initially. I
> think a few things could improve the situation, some manual related,
> some other things:
>
>
> Guile Reference vs Guile Guide
> ==============================
>
> Personally I think the *best* experience I have ever had in reading
> manuals is in Racket.
>
> Racket has a nice way of handling things:
>
> - There's a set of initial "short tutorials" that are really to get you
> up and running and feel like you "did something cool" fast. This is
> great, and it would be nice to have some of these, maybe with
> screencast examples.
>
> - Racket also separates the "Guide" from the "Reference". Well that's
> sensible! Guile actually has a very good "reference manual", maybe
> what it needs is a *companion* in terms of the "Guile Guide".
>
> (Note that despite my high praise for Racket's manuals, that's not a
> universal impression; I have a friend who has told me several times that
> Racket's manuals were hard for her because they seem too aimed at PLT
> type folks. I still think highly of them but want to note that.)
>
>
> Module names
> ============
>
> ice-9 -> guile
> --------------
>
> I think that ice-9 is a weird namespace for "guile's standard library"
> but it's what we have for historical reasons. Still I would have
> preferred that namespace simply be "guile", so we have (guile match) and
> (guile format) instead of (ice-9 ...). It would be clearer what ice-9
> *is* to have it be called "guile" instead. But maybe it's too late for
> that. How much work would it be to do an alias like this?
>
>
> Named SRFIs
> -----------
>
> If it's possible to do such aliases, I'd also say that making sense of
> what SRFI module is what is a real mess for me. (srfi srfi-9) doesn't
> tell me what that SRFI *is*. However, if we supported "named" versions
> of SRFIs, that would help me. Which of these would be easier to read?
>
> Heck, maybe I should make a SRFI for common human readable SRFI names.
> #mildlyspicytake #maybenotabadidea
>
>
> An example, a comparison
> ------------------------
>
> Taken all together, imagine if instead of:
>
> (define-module (my-module)
> #:use-module (ice-9 match)
> #:use-module (ice-9 format)
> #:use-module (srfi srfi-1)
> #:use-module (srfi srfi-9)
> #:use-module (srfi srfi-37)
> #:use-module (srfi srfi-41)
> #:use-module (srfi srfi-64))
>
> 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?
>
>
> Guile Studio and the picture language!
> ======================================
>
> I've finally, finally tried out Ricardo Wurmus' Guile Studio, which is
> actually quite impressive. It sets up Emacs to be like DrRacket, easy
> to pick up and hack for a complete newcomer. Very nice! If we do have
> screencasty type things it might be nice to use Guile Studio as the
> environment we start showing people in.
>
>
> Wisp
> ====
>
> I'd like to actually see Guile integrate Wisp as a core language and
> think about what it would be like to support it as a recommended
> alternate way of writing programs. I think with the new block-level
> highlighting that Arne has written, Wisp could be near ready for prime
> time. This could mean:
>
> - Getting wisp actually in Guile's official languages
> - Figuring out how to get geiser to be nicely integrated
> - Figuring out how to make importing Wisp modules be as easy as
> importing parenthetical-lisp ones
>
>
> Anyway, those are my thoughts. This email was longer than I meant or
> expected. Maybe it's useful. Thoughts?
>
> - Christine
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
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
2022-02-09 23:06 ` Keith Wright
2022-02-09 21:05 ` Olivier Dion via General Guile related discussions
` (7 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Maxime Devos @ 2022-02-09 21:05 UTC (permalink / raw)
To: Christine Lemmer-Webber, Chris Vine; +Cc: guile-user
[-- 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 --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 21:05 ` Maxime Devos
@ 2022-02-09 23:06 ` Keith Wright
0 siblings, 0 replies; 21+ messages in thread
From: Keith Wright @ 2022-02-09 23:06 UTC (permalink / raw)
To: Maxime Devos; +Cc: guile-user
Maxime Devos <maximedevos@telenet.be> writes:
> Christine Lemmer-Webber schreef op wo 09-02-2022 om 10:18 [-0500]:
>> We had:
>>
>> #:use-module (srfi args-fold)
>> #:use-module (srfi streams)
>> #:use-module (srfi tests))
>
> The RnRS reserved the (srfi ...) namespace for the SRFI process,
I don't know off-hand if that's true, but it's a good idea...
> possibly adding our own names here would be against the standard.
...and not a problem. Pick a new name for your new thing.
>> #:use-module (guile-srfi args-fold)
>> #:use-module (guile-srfi streams)
>> #:use-module (guile-srfi tests))
That's just as easy to follo9w, and you know what this meains:
>> #:use-module (chicken-srfi lazy-streams)
>> #:use-module (s48-srfi tests))
and you know where to put any little thing needed to
translate s48 tests to guile tests if inconsistencies are found.
-- Keith
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
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
@ 2022-02-09 21:05 ` Olivier Dion via General Guile related discussions
2022-02-09 21:07 ` Maxime Devos
` (6 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-02-09 21:05 UTC (permalink / raw)
To: Christine Lemmer-Webber, Chris Vine; +Cc: guile-user
On Wed, 09 Feb 2022, Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:
> Module names
> ============
>
> ice-9 -> guile
> --------------
> I think that ice-9 is a weird namespace for "guile's standard library"
> but it's what we have for historical reasons. Still I would have
> preferred that namespace simply be "guile", so we have (guile match) and
> (guile format) instead of (ice-9 ...). It would be clearer what ice-9
> *is* to have it be called "guile" instead. But maybe it's too late for
> that. How much work would it be to do an alias like this?
This is so true. (guile) should have be the name of that module. It
can be very confusing for newcomers.
> Named SRFIs
> -----------
>
> If it's possible to do such aliases, I'd also say that making sense of
> what SRFI module is what is a real mess for me. (srfi srfi-9) doesn't
> tell me what that SRFI *is*. However, if we supported "named" versions
> of SRFIs, that would help me. Which of these would be easier to read?
I too find this very weird. I don't have a cheat sheet for SRFI name
mapping on my desk and it's very awkward. Image if python was doing
this ..
import srfi.srfi-1
import srfi.srfi-26
import srfi.srfi-64
now very much human friendly.
> 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?
Yes! For the aliases I think something like this could work for now:
(define-syntax-rule (alias-module module-name)
(let ((mod (current-module)))
(module-for-each (lambda (sym var) (module-define! mod sym var))
(module-public-interface
(resolve-module (quote module-name))))
(module-export-all! mod)
#f))
then in srfi/tests.scm:
(define-module (srfi tests))
(alias-module (srfi srfi-64))
Ideally, something like this should be supported instead:
(define-module (srfi srfi-64)
#:alias (srfi tests))
--
Olivier Dion
Polymtl
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (2 preceding siblings ...)
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
` (5 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Maxime Devos @ 2022-02-09 21:07 UTC (permalink / raw)
To: Christine Lemmer-Webber, Chris Vine; +Cc: guile-user
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Christine Lemmer-Webber schreef op wo 09-02-2022 om 10:18 [-0500]:
> I'd like to actually see Guile integrate Wisp as a core language and
> think about what it would be like to support it as a recommended
> alternate way of writing programs. I think with the new block-level
> highlighting that Arne has written, Wisp could be near ready for prime
> time. This could mean:
>
> - Getting wisp actually in Guile's official languages
> - Figuring out how to get geiser to be nicely integrated
> - Figuring out how to make importing Wisp modules be as easy as
> importing parenthetical-lisp ones
I thought that Wisp = Scheme + a custom (non-parenthetical) reader,
so I importing Wisp modules would work the same way as Guile modules I
think?
(use-modules (some wisp foo))
AFAIK the only issue here is file extensions (mapping foo/bar.go to
foo/bar.THE-FILE-EXTENSION-OF-WISP).
Greetings,
Maxime.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 21:07 ` Maxime Devos
@ 2023-10-05 14:15 ` Dr. Arne Babenhauserheide
0 siblings, 0 replies; 21+ messages in thread
From: Dr. Arne Babenhauserheide @ 2023-10-05 14:15 UTC (permalink / raw)
To: Maxime Devos; +Cc: Christine Lemmer-Webber, Chris Vine, guile-user
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
Maxime Devos <maximedevos@telenet.be> writes:
> [[PGP Signed Part:No public key for 49E3EE22191725EE created at 2022-02-09T22:07:58+0100 using EDDSA]]
> Christine Lemmer-Webber schreef op wo 09-02-2022 om 10:18 [-0500]:
>> I'd like to actually see Guile integrate Wisp as a core language and
>> think about what it would be like to support it as a recommended
>> alternate way of writing programs. I think with the new block-level
>> highlighting that Arne has written, Wisp could be near ready for prime
>> time. This could mean:
>>
>> - Getting wisp actually in Guile's official languages
>> - Figuring out how to get geiser to be nicely integrated
>> - Figuring out how to make importing Wisp modules be as easy as
>> importing parenthetical-lisp ones
>
> I thought that Wisp = Scheme + a custom (non-parenthetical) reader,
> so I importing Wisp modules would work the same way as Guile modules I
> think?
>
> (use-modules (some wisp foo))
>
> AFAIK the only issue here is file extensions (mapping foo/bar.go to
> foo/bar.THE-FILE-EXTENSION-OF-WISP).
You can enable that via commandline flags to Guile, but you have to
precompile wisp files for that:
$ echo "define-module : foo
. #:export : bar
define : bar
. 'bar
" > foo.w
$ guild compile -f wisp foo.w
$ guile -L . -x .w
scheme@(guile-user)> (import (foo))
scheme@(guile-user)> (bar)
$1 = bar
This is not the most convenient of options, but it already provides a
way to actually ship wisp to people without them having to know about
it.
Aside: this is my header for wispwot:
#!/usr/bin/env bash
# -*- wisp -*-
exec -a "$0" ${GUILE:-guile} --language=wisp -x .w -L "$(dirname "$(realpath "$0")")" -C "$(dirname "$(realpath "$0")")" -e '(run-wispwot)' -c '' "$@"
; !#
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (3 preceding siblings ...)
2022-02-09 21:07 ` Maxime Devos
@ 2022-02-09 23:01 ` Chris Vine
2022-02-10 0:56 ` Timothy Sample
` (4 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Chris Vine @ 2022-02-09 23:01 UTC (permalink / raw)
To: guile-user
On Wed, 09 Feb 2022 10:18:27 -0500
Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:
> - Racket also separates the "Guide" from the "Reference". Well that's
> sensible! Guile actually has a very good "reference manual", maybe
> what it needs is a *companion* in terms of the "Guile Guide".
I think that is right.
I agree with the rest of your analysis except possibly as regards Wisp,
which I am not a great fan of, and as regards Racket, about which I know
little and am not qualified to have a view. The success of python as
compared with other dynamically typed languages such as guile and the
other schemes (which for the most part run considerably faster than
python) may be down to its more approachable syntax than scheme's
sexpressions, but I think there is probably more to it than that and
anyway that ship has now sailed. I positively like sexpressions. (I
could be wrong about my view on this so I wouldn't want to stand in the
way of a greater push for Wisp. But ocaml with the other MLs has a
syntax which many dislike but ocaml's Reason alternative does not appear
to have been much of a success either.)
Python was I think better marketed as a tool anyone could use, is
reasonably easy for novice programmers to get a grip of and has
developed the critical mass to give it an advantage over other dynamic
languages. Scheme/guile on the hand in the past has perhaps cultivated
the wizardish SICP ethos. And at the end of it scheme is in the main a
functional programming language even though it has mutation and has
dallied with common lispish things like GOOPS (which I don't like).
Many programmers find functional programming confusing. Javascript and
python have reached a sort of middle ground on that which maybe eludes
scheme.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (4 preceding siblings ...)
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
` (3 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Timothy Sample @ 2022-02-10 0:56 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: guile-user
Hi Christine,
Christine Lemmer-Webber <cwebber@dustycloud.org> writes:
> Heck, maybe I should make a SRFI for common human readable SRFI names.
> #mildlyspicytake #maybenotabadidea
It looks to be about as spicy as a cucumber. :)
I remembered that the R7RS Large process was giving library names to
SRFIs, but it looks like many of them now have a “library name” field in
their metadata. For instance, see <https://srfi.schemers.org/srfi-2/>,
which says “library name: and-let*”. Unfortunately, there are conflicts
(for example, 43 and 133 are both called “vectors”), so we might not be
able to take their names whole cloth.
Having many libraries named with a number is annoying to experienced
users and beginners alike. Let’s fix it!
(I liked the rest of your message too, but the SRFI names really stand
out as something to be fixed IMO.)
-- Tim
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-10 0:56 ` Timothy Sample
@ 2022-02-10 10:01 ` Ricardo Wurmus
0 siblings, 0 replies; 21+ messages in thread
From: Ricardo Wurmus @ 2022-02-10 10:01 UTC (permalink / raw)
To: Timothy Sample; +Cc: guile-user
Timothy Sample <samplet@ngyro.com> writes:
> I remembered that the R7RS Large process was giving library names to
> SRFIs, but it looks like many of them now have a “library name” field in
> their metadata. For instance, see <https://srfi.schemers.org/srfi-2/>,
> which says “library name: and-let*”. Unfortunately, there are conflicts
> (for example, 43 and 133 are both called “vectors”), so we might not be
> able to take their names whole cloth.
Optionally, the SRFI number could be appended to disambiguate:
vectors:43
vectors:133
As a user I would find this less confusing than the plain numbers.
--
Ricardo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (5 preceding siblings ...)
2022-02-10 0:56 ` Timothy Sample
@ 2022-02-10 1:32 ` Blake Shaw
2022-02-10 2:02 ` paul
` (2 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Blake Shaw @ 2022-02-10 1:32 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: guile-user
Just a reminder I'm doing a presentation that covers all this (almost
verbatim!) and more for Guix Days :)
(ie Christine you be stealing my thunder! 😆 🤣 😂)
I'm kidding (kinda). it doesn't hurt to have the conversations already
rolling and im sure it will mean the session will be extra productive :)
So continue forth and steal!
On Thu, Feb 10, 2022, 03:12 Christine Lemmer-Webber <cwebber@dustycloud.org>
wrote:
> I've been appreciating the feedback in this thread about Guile; I'm
> starting a new topic name because I think we've deviated from talking
> about Guile Hall and more about Guile.
>
> Some stuff below.
>
> Chris Vine <vine35792468@gmail.com> writes:
>
> > On Tue, 08 Feb 2022 19:19:06 +0700
> > Blake Shaw <blake@nonconstructivism.com> wrote:
> >
> >> Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
> >> > I don't think it's fair to say that using packages in Guile just as
> >> > easy/hard as other languages. Python / Javascript make this incredibly
> >> > easy, and their ecosystem is evidence for that success. Their package
> >> > managers have flaws, but they have benefits too, and those benefits
> >> > would be great for Guile.
> >>
> >> I would just like to tag onto this convo that I agree that its not fair
> >> to say that Guile is easy and will quickly bless those who endeavor to
> >> learn it with superpowers. My experience w/Racket was very smooth and I
> >> got working in it very quickly. I was a contracted to work on a project
> in
> >> Python a few months ago and without ever studying it I was able to
> >> start doing production work in it (ridiculous how intuitive it is,
> >> really). Before I started learning Guile I read Edwin Brady's book on
> >> Idris and found Idris much easier to get from start to end of small
> >> projects I was working on (because there is a well written book on it).
> >>
> >> While Guile has become my favorite programming language, it took me
> >> several months to learn how to navigate & figure out how to navigate the
> >> SRFIs, how to plan a program so that I can know what to expect along the
> >> way (what features I'll need to implement myself, etc) before I was able
> >> to get productive in it beyond the realm of Guix. And I think most would
> >> agree that Scheme is a less advanced language than Idris (I did some
> >> category theory in school so I have some intuition for the ideas, but
> >> still). And to be honest, I still hit plenty of road blocks.
> >>
> >> There were definitely some times where I was digging around trying to
> >> figure out how to do things and came across messages in the archives
> >> saying "its so easy you just do [vague hand wavy explanation]". And I
> >> found that quite frustrating, like there is an insularity meant to weed
> >> out the bad apples. And when this topic popped up on the guix list a few
> >> weeks ago some others expressed similar concerns, folks who are doing
> >> very impressive work. A programming language should never make
> >> programmers feel dumb -- it should make us feel empowered!
> >
> > Everything is capable of improvement but the guile manual is a manual
> > and not I think primarily intended as a language tutorial (although
> > Chapter 3 of the manual does have a very cursory introduction to the
> > scheme language). If you are looking for a tutorial, I suggest reading
> > https://www.scheme.com/tspl4/ . It covers the R6RS flavour, but at the
> > tutorial level I don't think the various current standard flavours
> > (R5RS, R6RS and R7RS) matter too much.
> >
> > I would be reluctant to see the manual turned into a tutorial if that
> > were to mean abridging any of its current completeness.
>
> The manual does contain a very brief tutorial, but it's brief... the
> Guix cookbook also contains something short. Both seem a bit lacking to
> me but they could be starting points.
>
> Regarding the manual as a manual, I actually personally like the Guile
> manual a lot. I think it's very well written. But it's a reference
> guide.
>
> But I do remember finding it overwhelming and confusing initially. I
> think a few things could improve the situation, some manual related,
> some other things:
>
>
> Guile Reference vs Guile Guide
> ==============================
>
> Personally I think the *best* experience I have ever had in reading
> manuals is in Racket.
>
> Racket has a nice way of handling things:
>
> - There's a set of initial "short tutorials" that are really to get you
> up and running and feel like you "did something cool" fast. This is
> great, and it would be nice to have some of these, maybe with
> screencast examples.
>
> - Racket also separates the "Guide" from the "Reference". Well that's
> sensible! Guile actually has a very good "reference manual", maybe
> what it needs is a *companion* in terms of the "Guile Guide".
>
> (Note that despite my high praise for Racket's manuals, that's not a
> universal impression; I have a friend who has told me several times that
> Racket's manuals were hard for her because they seem too aimed at PLT
> type folks. I still think highly of them but want to note that.)
>
>
> Module names
> ============
>
> ice-9 -> guile
> --------------
>
> I think that ice-9 is a weird namespace for "guile's standard library"
> but it's what we have for historical reasons. Still I would have
> preferred that namespace simply be "guile", so we have (guile match) and
> (guile format) instead of (ice-9 ...). It would be clearer what ice-9
> *is* to have it be called "guile" instead. But maybe it's too late for
> that. How much work would it be to do an alias like this?
>
>
> Named SRFIs
> -----------
>
> If it's possible to do such aliases, I'd also say that making sense of
> what SRFI module is what is a real mess for me. (srfi srfi-9) doesn't
> tell me what that SRFI *is*. However, if we supported "named" versions
> of SRFIs, that would help me. Which of these would be easier to read?
>
> Heck, maybe I should make a SRFI for common human readable SRFI names.
> #mildlyspicytake #maybenotabadidea
>
>
> An example, a comparison
> ------------------------
>
> Taken all together, imagine if instead of:
>
> (define-module (my-module)
> #:use-module (ice-9 match)
> #:use-module (ice-9 format)
> #:use-module (srfi srfi-1)
> #:use-module (srfi srfi-9)
> #:use-module (srfi srfi-37)
> #:use-module (srfi srfi-41)
> #:use-module (srfi srfi-64))
>
> 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?
>
>
> Guile Studio and the picture language!
> ======================================
>
> I've finally, finally tried out Ricardo Wurmus' Guile Studio, which is
> actually quite impressive. It sets up Emacs to be like DrRacket, easy
> to pick up and hack for a complete newcomer. Very nice! If we do have
> screencasty type things it might be nice to use Guile Studio as the
> environment we start showing people in.
>
>
> Wisp
> ====
>
> I'd like to actually see Guile integrate Wisp as a core language and
> think about what it would be like to support it as a recommended
> alternate way of writing programs. I think with the new block-level
> highlighting that Arne has written, Wisp could be near ready for prime
> time. This could mean:
>
> - Getting wisp actually in Guile's official languages
> - Figuring out how to get geiser to be nicely integrated
> - Figuring out how to make importing Wisp modules be as easy as
> importing parenthetical-lisp ones
>
>
> Anyway, those are my thoughts. This email was longer than I meant or
> expected. Maybe it's useful. Thoughts?
>
> - Christine
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (6 preceding siblings ...)
2022-02-10 1:32 ` Blake Shaw
@ 2022-02-10 2:02 ` paul
2022-02-10 11:27 ` Mikael Djurfeldt
2023-09-27 19:29 ` Christine Lemmer-Webber
9 siblings, 0 replies; 21+ messages in thread
From: paul @ 2022-02-10 2:02 UTC (permalink / raw)
To: guile-user
Hey all,
Just a rando on the internet, but wanted to chime in and express
my support for the idea of low-hanging fruit fixes to make Guile
more approachable. Since nobody else called it out yet,
On 2022-02-09 at 10:18 -05, quoth Christine Lemmer-Webber
<cwebber@dustycloud.org>:
> [...]
> ice-9 -> guile
> --------------
>
> I think that ice-9 is a weird namespace for "guile's standard
> library"
> but it's what we have for historical reasons. Still I would
> have
> preferred that namespace simply be "guile", so we have (guile
> match) and
> (guile format) instead of (ice-9 ...). It would be clearer what
> ice-9
> *is* to have it be called "guile" instead. But maybe it's too
> late for
> that. How much work would it be to do an alias like this?
> [...]
I wanted to say that i found this extremely baffling, too. I
initially assumed `ice-9` must be somebody's side-project to add
"helpful features" to the Guile stdlib, and searched around a bit
and (predictably) found a reference to a scifi novel i was unaware
of. I dismissed that out of hand because surely "ice" in the
context of Guile must stand for something else, but a few weeks
later i decided to search this very mailing list archive, finding
lo and behold, `ice-9` _is_ in fact the stdlib :). As a Guile
newbie myself, i agree that it'd be immensely easier to grok
what's going on if we're presented with module names such as
Christine suggests.
I didn't think to mention my confusion because.. well, i'm just
the peanut gallery. But i won't miss the opportunity to say "i
agree"! :)
All the best to everyone reading,
paul
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (7 preceding siblings ...)
2022-02-10 2:02 ` paul
@ 2022-02-10 11:27 ` Mikael Djurfeldt
2022-02-10 14:34 ` Leo Butler
2023-09-27 19:29 ` Christine Lemmer-Webber
9 siblings, 1 reply; 21+ messages in thread
From: Mikael Djurfeldt @ 2022-02-10 11:27 UTC (permalink / raw)
To: Christine Lemmer-Webber; +Cc: guile-user
Den ons 9 feb. 2022 21:12Christine Lemmer-Webber <cwebber@dustycloud.org>
skrev:
>
> ice-9 -> guile
> --------------
>
> I think that ice-9 is a weird namespace for "guile's standard library"
> but it's what we have for historical reasons. Still I would have
> preferred that namespace simply be "guile", so we have (guile match) and
> (guile format) instead of (ice-9 ...). It would be clearer what ice-9
> *is* to have it be called "guile" instead. But maybe it's too late for
> that. How much work would it be to do an alias like this?
>
Indeed. And, no, I don't think it is a lot of work at all. We should have
an easy way to create module aliases, rename it, setup ice-9 as an alias
and deprecate it.
But, I wonder if "guile" is the right name? Does that mean that the other
sibling directories, like "language", "oop" and "sxml" is *not* guile?
Perhaps "base" or "core" are good alternatives?
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Ideas for making Guile easier to approach
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
0 siblings, 2 replies; 21+ messages in thread
From: Leo Butler @ 2022-02-10 14:34 UTC (permalink / raw)
To: Mikael Djurfeldt; +Cc: guile-user
Mikael Djurfeldt <mikael@djurfeldt.com> writes:
> Den ons 9 feb. 2022 21:12Christine Lemmer-Webber <cwebber@dustycloud.org>
> skrev:
>
>>
>> ice-9 -> guile
>> --------------
>>
>> I think that ice-9 is a weird namespace for "guile's standard library"
>> but it's what we have for historical reasons.
My 2c: The guile reference manual is worth reading. Early on, I found this:
(info "(guile)Status")
#+begin_quote
...eventually resulting in the Emacsification of the entire GNU
system. Indeed, this is the reason for the naming of the many Guile
modules that live in the ‘ice-9’ namespace, a nod to the fictional
substance in Kurt Vonnegut’s novel, Cat’s Cradle, capable of acting as a
seed crystal to crystallize the mass of software.
#+end_quote
It would be a pity to deprecate and/or remove that little bit of culture
for the sake of...OTOH, creating a workable system that allowed one to
dynamically alias modules would definitely be useful.
Leo
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
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
1 sibling, 0 replies; 21+ messages in thread
From: Mikael Djurfeldt @ 2022-02-10 15:58 UTC (permalink / raw)
To: Leo Butler; +Cc: guile-user
On Thu, Feb 10, 2022 at 3:34 PM Leo Butler <leo.butler@umanitoba.ca> wrote:
> ...eventually resulting in the Emacsification of the entire GNU
> system. Indeed, this is the reason for the naming of the many Guile
> modules that live in the ‘ice-9’ namespace, a nod to the fictional
> substance in Kurt Vonnegut’s novel, Cat’s Cradle, capable of acting as a
> seed crystal to crystallize the mass of software.
>
Right, I'm aware of that. However, it's not a good idea if it works
*against* the Emacsification, as it has partially been doing all along.
Such naming is simply crazy. To take it to the extreme, what about renaming
the + and - operators to +Obama and -Trump, just to give a nod to general
reason?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
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
1 sibling, 0 replies; 21+ messages in thread
From: Olivier Dion via General Guile related discussions @ 2022-02-10 18:25 UTC (permalink / raw)
To: Leo Butler, Mikael Djurfeldt; +Cc: guile-user
On Thu, 10 Feb 2022, Leo Butler <leo.butler@umanitoba.ca> wrote:
> It would be a pity to deprecate and/or remove that little bit of
> culture for the sake of...OTOH, creating a workable system that
> allowed one to dynamically alias modules would definitely be useful.
The cultural reference can still be there in the manual and the module
has to be there for retro compatibility in any case.
The OTOH is actually very important IMO. What paul said in his message
is also true for me. I though that ice-9 what some hack library that
had nothing to do with Guile at first. Yes yes you eventually
understand when you stumble across the *10 lines out of 800 pages* that
ice-9 is the Guile standard library, but it would be easier if it was
(guile) or (core) or something that is actually meaningful for newcomers
before reading those 10 lines.
For me, module aliases would be the perfect solution to all of this.
--
Olivier Dion
Polymtl
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Ideas for making Guile easier to approach
2022-02-09 15:18 ` Ideas for making Guile easier to approach Christine Lemmer-Webber
` (8 preceding siblings ...)
2022-02-10 11:27 ` Mikael Djurfeldt
@ 2023-09-27 19:29 ` Christine Lemmer-Webber
2023-09-28 12:30 ` Maxime Devos
9 siblings, 1 reply; 21+ messages in thread
From: Christine Lemmer-Webber @ 2023-09-27 19:29 UTC (permalink / raw)
To: Chris Vine, guile-user
Here's another interesting thread to revisit on the topic of making
Guile easier to use :)
Christine Lemmer-Webber <cwebber@dustycloud.org> writes:
> I've been appreciating the feedback in this thread about Guile; I'm
> starting a new topic name because I think we've deviated from talking
> about Guile Hall and more about Guile.
>
> Some stuff below.
>
> Chris Vine <vine35792468@gmail.com> writes:
>
>> On Tue, 08 Feb 2022 19:19:06 +0700
>> Blake Shaw <blake@nonconstructivism.com> wrote:
>>
>>> Vijay Marupudi <vijaymarupudi@gatech.edu> writes:
>>> > I don't think it's fair to say that using packages in Guile just as
>>> > easy/hard as other languages. Python / Javascript make this incredibly
>>> > easy, and their ecosystem is evidence for that success. Their package
>>> > managers have flaws, but they have benefits too, and those benefits
>>> > would be great for Guile.
>>>
>>> I would just like to tag onto this convo that I agree that its not fair
>>> to say that Guile is easy and will quickly bless those who endeavor to
>>> learn it with superpowers. My experience w/Racket was very smooth and I
>>> got working in it very quickly. I was a contracted to work on a project in
>>> Python a few months ago and without ever studying it I was able to
>>> start doing production work in it (ridiculous how intuitive it is,
>>> really). Before I started learning Guile I read Edwin Brady's book on
>>> Idris and found Idris much easier to get from start to end of small
>>> projects I was working on (because there is a well written book on it).
>>>
>>> While Guile has become my favorite programming language, it took me
>>> several months to learn how to navigate & figure out how to navigate the
>>> SRFIs, how to plan a program so that I can know what to expect along the
>>> way (what features I'll need to implement myself, etc) before I was able
>>> to get productive in it beyond the realm of Guix. And I think most would
>>> agree that Scheme is a less advanced language than Idris (I did some
>>> category theory in school so I have some intuition for the ideas, but
>>> still). And to be honest, I still hit plenty of road blocks.
>>>
>>> There were definitely some times where I was digging around trying to
>>> figure out how to do things and came across messages in the archives
>>> saying "its so easy you just do [vague hand wavy explanation]". And I
>>> found that quite frustrating, like there is an insularity meant to weed
>>> out the bad apples. And when this topic popped up on the guix list a few
>>> weeks ago some others expressed similar concerns, folks who are doing
>>> very impressive work. A programming language should never make
>>> programmers feel dumb -- it should make us feel empowered!
>>
>> Everything is capable of improvement but the guile manual is a manual
>> and not I think primarily intended as a language tutorial (although
>> Chapter 3 of the manual does have a very cursory introduction to the
>> scheme language). If you are looking for a tutorial, I suggest reading
>> https://www.scheme.com/tspl4/ . It covers the R6RS flavour, but at the
>> tutorial level I don't think the various current standard flavours
>> (R5RS, R6RS and R7RS) matter too much.
>>
>> I would be reluctant to see the manual turned into a tutorial if that
>> were to mean abridging any of its current completeness.
>
> The manual does contain a very brief tutorial, but it's brief... the
> Guix cookbook also contains something short. Both seem a bit lacking to
> me but they could be starting points.
>
> Regarding the manual as a manual, I actually personally like the Guile
> manual a lot. I think it's very well written. But it's a reference
> guide.
>
> But I do remember finding it overwhelming and confusing initially. I
> think a few things could improve the situation, some manual related,
> some other things:
>
>
> Guile Reference vs Guile Guide
> ==============================
>
> Personally I think the *best* experience I have ever had in reading
> manuals is in Racket.
>
> Racket has a nice way of handling things:
>
> - There's a set of initial "short tutorials" that are really to get you
> up and running and feel like you "did something cool" fast. This is
> great, and it would be nice to have some of these, maybe with
> screencast examples.
>
> - Racket also separates the "Guide" from the "Reference". Well that's
> sensible! Guile actually has a very good "reference manual", maybe
> what it needs is a *companion* in terms of the "Guile Guide".
>
> (Note that despite my high praise for Racket's manuals, that's not a
> universal impression; I have a friend who has told me several times that
> Racket's manuals were hard for her because they seem too aimed at PLT
> type folks. I still think highly of them but want to note that.)
>
>
> Module names
> ============
>
> ice-9 -> guile
> --------------
>
> I think that ice-9 is a weird namespace for "guile's standard library"
> but it's what we have for historical reasons. Still I would have
> preferred that namespace simply be "guile", so we have (guile match) and
> (guile format) instead of (ice-9 ...). It would be clearer what ice-9
> *is* to have it be called "guile" instead. But maybe it's too late for
> that. How much work would it be to do an alias like this?
>
>
> Named SRFIs
> -----------
>
> If it's possible to do such aliases, I'd also say that making sense of
> what SRFI module is what is a real mess for me. (srfi srfi-9) doesn't
> tell me what that SRFI *is*. However, if we supported "named" versions
> of SRFIs, that would help me. Which of these would be easier to read?
>
> Heck, maybe I should make a SRFI for common human readable SRFI names.
> #mildlyspicytake #maybenotabadidea
>
>
> An example, a comparison
> ------------------------
>
> Taken all together, imagine if instead of:
>
> (define-module (my-module)
> #:use-module (ice-9 match)
> #:use-module (ice-9 format)
> #:use-module (srfi srfi-1)
> #:use-module (srfi srfi-9)
> #:use-module (srfi srfi-37)
> #:use-module (srfi srfi-41)
> #:use-module (srfi srfi-64))
>
> 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?
>
>
> Guile Studio and the picture language!
> ======================================
>
> I've finally, finally tried out Ricardo Wurmus' Guile Studio, which is
> actually quite impressive. It sets up Emacs to be like DrRacket, easy
> to pick up and hack for a complete newcomer. Very nice! If we do have
> screencasty type things it might be nice to use Guile Studio as the
> environment we start showing people in.
>
>
> Wisp
> ====
>
> I'd like to actually see Guile integrate Wisp as a core language and
> think about what it would be like to support it as a recommended
> alternate way of writing programs. I think with the new block-level
> highlighting that Arne has written, Wisp could be near ready for prime
> time. This could mean:
>
> - Getting wisp actually in Guile's official languages
> - Figuring out how to get geiser to be nicely integrated
> - Figuring out how to make importing Wisp modules be as easy as
> importing parenthetical-lisp ones
>
>
> Anyway, those are my thoughts. This email was longer than I meant or
> expected. Maybe it's useful. Thoughts?
>
> - Christine
^ permalink raw reply [flat|nested] 21+ messages in thread