From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Olivier Dion via General Guile related discussions Newsgroups: gmane.lisp.guile.user Subject: Re: Shell commands with output to string Date: Wed, 23 Feb 2022 13:25:28 -0500 Message-ID: <87bkyx5tk7.fsf@laura> References: <877d9lo4mv.fsf@nonconstructivism.com> Reply-To: Olivier Dion Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Zelphir Kaltstahl , Leo Butler To: Blake Shaw , Olivier Dion via General Guile related discussions Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Feb 23 19:26:04 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nMwKy-0000rf-7B for guile-user@m.gmane-mx.org; Wed, 23 Feb 2022 19:26:04 +0100 Original-Received: from localhost ([::1]:45810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMwKx-0001Ln-4o for guile-user@m.gmane-mx.org; Wed, 23 Feb 2022 13:26:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMwKi-0001Le-Ip for guile-user@gnu.org; Wed, 23 Feb 2022 13:25:48 -0500 Original-Received: from smtp.polymtl.ca ([132.207.4.11]:49887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMwKb-00057G-BI for guile-user@gnu.org; Wed, 23 Feb 2022 13:25:47 -0500 Original-Received: from localhost (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 21NIPS9N010586 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Feb 2022 13:25:33 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 21NIPS9N010586 In-Reply-To: <877d9lo4mv.fsf@nonconstructivism.com> X-Poly-FromMTA: (modemcable094.169-200-24.mc.videotron.ca [24.200.169.94]) at Wed, 23 Feb 2022 18:25:28 +0000 Received-SPF: pass client-ip=132.207.4.11; envelope-from=olivier.dion@polymtl.ca; helo=smtp.polymtl.ca X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:18134 Archived-At: On Thu, 24 Feb 2022, Blake Shaw wrote: > Olivier Dion via General Guile related discussions > writes: >> This is great and should be merged into the standard library of Guile. >> Maybe not at it's (I have not read everything), but this would be trully >> benifical to all Guile users. >> > I very much disagree. While it's a large implementation of Scheme, > Guile is still Scheme. This is all really simple stuff, and there are > many ways to implement these functions. Do the Guile maintainers > really need to be burdened by adding trivial functionality to the core > library? It it's simple stuff, but as you mentioned, it's difficult to determine how things are done in Guile as a beginer. So maybe the problem is not the lack of functionality, but lack of knowledge/understanding. I for one am a big advocate of do your own stuff if you can. That's what I do for my projects. But some people prefers to just glue stuffs together instead and that's okay too. >> - Field -> Can I develop in my field (e.g. video game, mathematic) >> with this language? Is there a community? > Yes and yes to those fields, with great tools! (Haunt, recent vector > libs) But the community, like many a scheme, is a bit hermetic, and > this is based in practices like mailing lists, which I don't think > can/will change. We could start a guile-hackers discourse server, or > something else more public-facing, but would any of the current users > join? So then we are the Day Zero guile crew, and thats gonna be > rough to get going. I think that would certainly reach out to more people. In my experience -- at least where I live -- people in their mid 20 like me don't use mailing list or see them as a thing of the past of dead project. > I agree with much of what you're saying, but I disagree with the idea > of Guile becoming a "batteries included" Scheme loaded with > conveniences. Andy et al have far more important issues to worry > about. I don't think that Guile should have a batteries included standard library like Python does. Maybe just a few more friendly functions that are commonly used. And I certainly don't want to impose any burden on anyone to implement them! > On the other hand, I would be down to organize and contribute to an > effort to create a battery pack, based on a study of the utilities > offered by Python. We saw that Guix is picking up in production use > and such a library would be very helpful (and I think Tropin's RDE > might be trying to accomplish something like this) I think this would be the best option. Leaving it to the community. This would remove the burden on the maintainers while making the library bigger and bigger while also ensuring the prefer coding style of the community. However, we should probably also lookg at what is done on the Racket side. They have very nice things like type system and contract programming! > There is the existing Guile-lib, which seems to have intended something > similar in the past. Let me briefly comment on its TOC: Everytime I've looked into it I feel like it was a dead project by the look of the website. Even though its last update was in 2021. The documentation is also lacking in my souvenir. But something like this is a good start. >>(os process) >> Spawning processes and capturing their output > where has this been my whole guile experience?!? too late, I made one > myself (: We all did I believe ^^ >>(scheme kwargs) >> Defining functions with flexible keyword arguments > how is that different from existing kwargs? I think this was before curried definitions were introduced? > As you can see, much of this is stuff that won't come in handy until > you already feel compfortable with guile. > > In fact, some of it will just seem like weird alien technology until > you've spent some time with scheme. > > So while I agree that an organized effort to roll-out a battery pack > would be hugely beneficial, I think efforts to make the existing > knowledge base of guile more accessible/easier to navigate/less messy > would get folks moving with the large ecosystem faster, > speaking/thinking in guile, and thus would be more rewarding than > porting conventional idioms into a box that makes guile more familiar > for python and JS developers. Refactoring of the documentation I think we all agree on that after your talk last week and its echo on the ML. I also believe that things need to be modernized a bit. Like your discourse proposition for discussion, but also things like the website of guile-lib. -- Olivier Dion Polymtl