unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Catonano <catonano@gmail.com>, Chris Vine <vine35792468@gmail.com>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: "Missing" libraries/concepts found in other languages/ecosystems?
Date: Sat, 11 Jul 2020 02:34:22 +0200	[thread overview]
Message-ID: <f32d1aa8-8e2d-6aa4-911d-0fde04bf3291@posteo.de> (raw)
In-Reply-To: <14a24bd8-2664-c7bf-eff8-ca3f4e068ef8@posteo.de>

The comments about exception handling also reminded me of the following
blog post:

https://blog.sulami.xyz/posts/common-lisp-restarts/

Pretty cool concept as well.

If there anything like it in Guile or is something like it possible
(probably, right?)?


On 7/11/20 2:19 AM, Zelphir Kaltstahl wrote:
> Hi all!
>
> On 7/10/20 1:20 PM, Catonano wrote:
>> Il giorno ven 10 lug 2020 alle ore 12:21 Chris Vine <vine35792468@gmail.com>
>> ha scritto:
>>
>>> On Fri, 10 Jul 2020 10:49:37 +0200
>>> Catonano <catonano@gmail.com> wrote:
>>>> Il giorno mer 8 lug 2020 alle ore 20:22 Zelphir Kaltstahl <
>>>> zelphirkaltstahl@gmail.com> ha scritto:
>>>>
>>>>> Hi Simen!
>>>>>
>>>>> On 7/8/20 6:00 PM, guile-user-request@gnu.org wrote:
>>>>>> Hi, I'm new to scheme/lisp, so I'm trying to find out how to do
>>>>>> things the "lisp
>>>>>> way". On the other hand, I like things from other ecosystems too,
>>>>>> and I'm having
>>>>>> problems finding this for Guile. It might be because there's no
>>>>>> need for it/I'm
>>>>>> terrible at searching/nobody had the time yet, or something else.
>>>>>>
>>>>>> I've been trying to find implementations for https://reactivex.io
>>>>>> without any
>>>>>> luck. And I'm unable to find implementation of FP concepts as
>>>>>> found in Haskell
>>>>>> and other languages. Functor, Monad, lenses (and other helpers for
>>>>>> working with
>>>>>> immutable data).
>>>>>>
>>>>>> Does things like this exists, or is it better to use something
>>>>>> else?
>>>>>>
>>>>>> Regards Simen
>>>>> To what others already have written I will add:
>>>>>
>>>>> From time to time one can copy ideas from Racket or look at what exists
>>>>> in Racket for solving a problem or seeing what the approach is.
>>>>>
>>>>> Catonano identified already the lack of examples in the Guile guide. I
>>>>> fight with that myself, so I created a repository with examples.
>>> Perhaps
>>>>> I should somehow add them to the guide. I've not looked into how to do
>>>>> that. Probably some commit in a repo somewhere for the guide:
>>>>>
>>>>> https://notabug.org/ZelphirKaltstahl/guile-examples
>>>>>
>>>>> Hope this can help!
>>>>>
>>>> Thank you, yes that helps
>>>>
>>>> In fact, it's a precious resource !
>>>>
>>>> I was especially delighted with the examples of using exceptions !
>>>>
>>>> I had so missed examples of those !
>>>>
>>>> As for the manual, very recently a mention of Guile Hall ended up being
>>>> included in the manual
>>>>
>>>> The same could be done with your examples collection
>>>>
>>>> I also think that your collection could be mentioned by the Guile web
>>> site,
>>>> maybe in the "learn" section
>>>>
>>>> Here's the repo for the web site:
>>>> https://git.savannah.gnu.org/cgit/guile/guile-web.git/
>>>>
>>>> a regular patch could do
>>>>
>>>> What do people think of mentioning this resource on the Guile web site ?
>>> Whilst I don't have strong feelings, as a general approach I think it is
>>> better to include additional examples (where needed) in the body of the
>>> manual, which I think is generally well written.
>>>
>> As long as some examples are reachable from an officially sanctioned
>> documentation source, I'm ok with that
>>
>> What I find problematic is the casualness in referring to bits scattered
>> all around
>>
>> The web site was just an idea, the manual would be perfectly fine
>>
>> Also, at this level of detail what some find helpful others don't.  You
>>> were delighted above with the exceptions example, whereas (if I read
>>> the right one) I thought that that was one of the weaker ones.  It
>>> concentrates on R6RS/R7RS exceptions and with-exception-handler rather
>>> than with guile's much easier to use catch expression (for guile-2.2)
>>> or (for guile-3.0) its beefed-up with-exception-handler and exception
>>> objects.
>>>
>> Ah there has been a misunderstanding here
>>
>> I was convinced that the exceptions example was of the last layout for
>> using exceptions reached recently in Guile 3.x
>>
>> If it's not, I agree it's less valuable
>>
>> But I think the author was just confused or led astray by the casualness of
>> referring to scattered bits, I'm not blaming them
>>
>> I'd be grateful if anyone with enough understanding of the issue would
>> contribute a proper example of how to use exceptions according to the last
>> exceptions reorganization in Guile 3.x
>>
>> I would be happy to send a patch for the manual containing such example and
>> a few words, as I did with the mention of Guile Hall
>>
>>
>> with-exception-handler is a tricky beast and the example didn't deal
>>> with the main case: most uses of exceptions involve handling them and
>>> moving on with program execution from the point where the exception is
>>> caught, and to do that using with-exception-handler instead of
>>> guile's 'catch' form you have to have a call/ec helper (or with
>>> guile-3.0 you can just set the #unwind argument to true).  Instead you
>>> are left with the idea that you use continuable exceptions for that
>>> (which while they do stop the program exiting are something different)
>>> or the R6RS/R7RS guard form.
>>>
>> I'm not following you on this because I don't know enough of both the Guile
>> new idea of how to use exceptions and the R6/7RS one
>>
>>
>>> I am not trying to be critical here - I think examples are useful to
>>> convey points and some of them were fine.  My point is more about venue.
>>>
>>  No, that's ok, that's why I asked
>>
>> In fact, should we end up with a proper example in the manual, that would
>> be a positive outcome
>>
>> I'd say more, here
>>
>> I'd go systematically through all the examples in that repo and do a
>> similar assessment if we can add it to the manual as is or if it needs
>> refinement
>>
>> I can't do this on my own because in many cases I don't know enough to come
>> up with valid examples myself
>>
>> But I'd be happy to prepare patches for the manual, given the right
>> directions
>
> I would be glad, if any non-optimal example was extended or updated by a
> more knowledgeable person or I was told what I could improve in some
> example. The examples in the repository are only, what I was able to
> understand and I often find myself looking up, how to do something again.
>
> If anyone wants to take any example and put it in the docs, go ahead.
> Only don't think that my examples are the last word on how to do things.
> Far from it!
>
> About the exceptions thing: Aha! I should look into that again. I
> thought the "conditions" thing was already pretty cool and useful. Once
> an exception happens, you can react on it. I did not understand the
> "call/ec helper" part, but perhaps I can understand it, when I check the
> docs for the new exceptions in Guile 3.
>
> I had another thought: Why do we not create this kind of so called
> "awesome list" for Guile? There were some links in this discussion,
> which might be a good fit on such a list and it is kind of informal,
> easy to extend. Whenever someone asks for pointers, we could also
> mention that list and perhaps they can find cool things in it. They
> could see, that Guile is viable, because there are so many things people
> do with Guile, or they could see their use case covered already.
>
> Best regards,
> Zelphir
>
>



  reply	other threads:[~2020-07-11  0:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.75.1594224014.21222.guile-user@gnu.org>
2020-07-08 18:22 ` "Missing" libraries/concepts found in other languages/ecosystems? Zelphir Kaltstahl
2020-07-09 18:12   ` Leo Butler
2020-07-09 19:34     ` Zelphir Kaltstahl
2020-07-10  7:39   ` Aleix Conchillo Flaqué
2020-07-10  8:14     ` Alex Sassmannshausen
2020-07-10  8:49   ` Catonano
2020-07-10 10:21     ` Chris Vine
2020-07-10 11:20       ` Catonano
2020-07-11  0:19         ` Zelphir Kaltstahl
2020-07-11  0:34           ` Zelphir Kaltstahl [this message]
2020-07-11 10:14             ` Chris Vine
2020-07-11 13:45               ` Stefan Israelsson Tampe
2020-07-11 14:46             ` Linus Björnstam
2020-07-11 10:13           ` Chris Vine
2020-07-11 18:20             ` John Cowan
2020-07-11 22:39               ` Chris Vine
2020-07-11 22:41                 ` John Cowan
2020-07-11 23:09                   ` Chris Vine
2020-07-12  1:52                     ` John Cowan
2020-07-12 20:26                       ` Chris Vine
2020-07-13 10:10                 ` Chris Vine
2020-07-12 16:08             ` Catonano
2020-07-12 16:10               ` Catonano
2020-07-12 17:46               ` John Cowan
2020-07-12 19:14               ` Chris Vine
2020-07-12 19:32                 ` Chris Vine
2020-07-14 10:32                   ` Catonano
2020-07-14 11:06                     ` Catonano
2020-07-14 16:21                     ` Chris Vine
2020-07-12 20:33               ` Zelphir Kaltstahl
2020-07-08  7:38 Simen Endsjø
2020-07-08  8:15 ` Vladimir Zhbanov
2020-07-08 10:08 ` Catonano
2020-07-08 11:29 ` Chris Vine
2020-07-10 12:15 ` Christopher Lam
2020-07-10 15:52   ` Chris Vine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f32d1aa8-8e2d-6aa4-911d-0fde04bf3291@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=catonano@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=vine35792468@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).