Re: Newbie thoughts on Guile Hall + Guix

Re: Newbie thoughts on Guile Hall + Guix

[Blake Shaw]

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!

[end rant, thanks for humoring me]

-- 
“In girum imus nocte et consumimur igni”

Re: Newbie thoughts on Guile Hall + Guix

[Chris Vine]

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.

Re: Newbie thoughts on Guile Hall + Guix

[Catonano]

Hi Blake,

I'm Adriano <randomlooser@riseup.net>, it' just happens that I'm reading
this message of yours from another account

Il giorno mar 8 feb 2022 alle ore 14:39 Blake Shaw <
blake@nonconstructivism.com> ha scritto:

> 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!
>

I personally believe this is a good chunk of why Guile wasn't as successful
as Python

With Guile the overall experience is extremely frustrating

I've been hanging around here for years, on and off, and overall I haven't
done anything, in Guile

I managed to do some widgets in clojurescript, some modest datapipes in
Clojure, a game of life with some 2d graphics library in Clojure

I made some things in Python

In Guile ?

Nothing, nisba, nada

I can relate to the experience of feeling frustrated about how casually
some things are referred to on Guile channels

Last time it was about the new exceptions

But I remember I asked for an example of some usage of the APIs for web
serving in Guile, some years ago

I was kindly offered an example by Andy Wingo nonetheless

But then I could follow up, I got lost, I don't remember why exactly, but I
was ashamed to keep gong n any way

Something similar happened when I asked about lazyness

I don't think I've ever seen a community that suffers the curse of
knowledge more than the Guile community

This is why I was enticed to attempt the only video in my life about how to
read a file (a basic use case) with Guile

And I'm mumbling to do a new series about project management and package
building

And about delimited continuations

And, and, and....

That is, my hope now is that Guile can be made into something empowering,
so that it will be useful to someone else in the future

rather than disempowering as it has always been (for me at least)

I've been terribly frustrated about this in the past and I'm so refreshed
to see you landing here, in Guile land

One final note: while I have been emotional about this in the past, I
believe I'm not being emotional now

My remarks are not meant to disparage the Guile/Guix community, I
acknowledge the generosity of this community, overall

I just think that it's right and useful to raise perceived problems

And I think this initiative to reconsider the structure of the manual is
one of the best things that happened in a very long time

After so many years I still can't tell where to look in it when I need
something

Ideas for making Guile easier to approach

[Christine Lemmer-Webber]

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

Re: Ideas for making Guile easier to approach

[Daniel Tornabene]

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
>
>

Re: Ideas for making Guile easier to approach

[Maxime Devos]

[-- 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 --]

Re: Ideas for making Guile easier to approach

[Olivier Dion via General Guile related discussions]

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

Re: Ideas for making Guile easier to approach

[Maxime Devos]

[-- 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 --]

Re: Ideas for making Guile easier to approach

[Chris Vine]

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.

Re: Ideas for making Guile easier to approach

[Keith Wright]

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
 

Re: Ideas for making Guile easier to approach

[Timothy Sample]

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

Re: Ideas for making Guile easier to approach

[Blake Shaw]

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
>
>

Re: Ideas for making Guile easier to approach

[paul]

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

Re: Ideas for making Guile easier to approach

[Ricardo Wurmus]

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

Re: Ideas for making Guile easier to approach

[Mikael Djurfeldt]

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?

Re: Ideas for making Guile easier to approach

[Leo Butler]

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

Re: Ideas for making Guile easier to approach

[Mikael Djurfeldt]

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?

Re: Ideas for making Guile easier to approach

[Olivier Dion via General Guile related discussions]

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

Re: Ideas for making Guile easier to approach

[Christine Lemmer-Webber]

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

Re: Ideas for making Guile easier to approach

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 757 bytes --]



Op 27-09-2023 om 21:29 schreef Christine Lemmer-Webber:
> 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

See [PATCH] add languages/wisp to Guile.

In some of the first messages there are proposals on how to fix the 
importing.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: Ideas for making Guile easier to approach

[Dr. Arne Babenhauserheide]

[-- 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 --]