From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Arne Babenhauserheide Newsgroups: gmane.lisp.guile.user Subject: Re: How to make GNU Guile more successful Date: Tue, 14 Feb 2017 23:20:01 +0100 Message-ID: <874lzw5sa6.fsf@web.de> References: <87lgtajpkc.fsf@web.de> <878tp967p4.fsf@elektro.pacujo.net> <87shnhabln.fsf@web.de> <87zihp48k4.fsf@elektro.pacujo.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1487110836 14492 195.159.176.226 (14 Feb 2017 22:20:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 22:20:36 +0000 (UTC) User-Agent: mu4e 0.9.16; emacs 25.1.1 Cc: "guile-user@gnu.org" To: Marko Rauhamaa Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 14 23:20:31 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdlSW-0003Bq-GR for guile-user@m.gmane.org; Tue, 14 Feb 2017 23:20:28 +0100 Original-Received: from localhost ([::1]:37458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdlSc-0000PL-5R for guile-user@m.gmane.org; Tue, 14 Feb 2017 17:20:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdlSE-0000Lf-N3 for guile-user@gnu.org; Tue, 14 Feb 2017 17:20:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdlSB-0003sA-9V for guile-user@gnu.org; Tue, 14 Feb 2017 17:20:10 -0500 Original-Received: from mout.web.de ([212.227.15.3]:63879) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdlSA-0003rL-TT for guile-user@gnu.org; Tue, 14 Feb 2017 17:20:07 -0500 Original-Received: from fluss ([85.212.4.135]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0M4ZVE-1cTpHD05Ns-00yeUK; Tue, 14 Feb 2017 23:20:03 +0100 In-reply-to: <87zihp48k4.fsf@elektro.pacujo.net> X-Provags-ID: V03:K0:ekpxbOum8REZmrtDTo3z5Sige5k9WWAIctGkhKgW7BzxGVNbgB0 /JdEyT5iY4wgRKLpgjmuKbuBXwejxyZox3UzdHTgopg6AtHZZP/1HWR+cEkxTC+TLs7BBjr yl0Kl7qtS/5vx4cB/cZ3nQPznLizBCghWi9xrqbTAVWshAt6rFb7dWgR6P2JE6VTj7UfqF4 /j53NMkk1YfEtHe01Tz0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:pdov5SbeLiw=:9DptObbdSrbLeKWXkp52Hf WCYjlHXOe58TuacaINknM61Ne0KdQVrV2s6jQ+2DRMayLqu9NEfKE+8bJEhybRNnXzy/0XV3m ppqPq2v8IOM7gVeSgWI2oJ8r/+MFWnbMZkZc/FkGBTx4D3i8WFZsIALNwIZRCmobb/XWgczr0 b38ZnCgZAYmmjAzKKMTEx8KLfa7OQvfa2ElJXLHGlBoeuA2b5ZpMNudNbzSPiMLUmc30yHXHr qXBWQVomA4Q7nIijqWzEkQmjcoAgXg1ehz73xAt9I9nPujFgt7YqviR83pubTNDZtDdh5k+Zp gt+UvaGB2Oof9rLtHzyBcobizf6rXAdcLEBKnTK0NDLWXaH02OuBTtpp+mX0FxoNZVFvm15RB gqtu8fyO9xGcfa8RTgEeEZLTbwrpVnZGOv9egsmzEo8JvcmFugIh39m3BqSn/WAZBTt4ZzO44 JOxg65EjRnKjTehQH858hrkysHzhFc0We/ev7aLA4BuXr2IkR9Z80cy1RMkYGh8O2rOKKSSGN zK33l1grmKijEuxV9m3DqD7sAAsPWsoeV/MJvY2srxaTOKK/LfO7trSmJmHL8mrGM04Pyzl4b 5sfjZDavapJHIF3X54QpUdJsLLkpQf1GJ82JtXbHglTfY2X215b5tHmk30gge5zmw2Ai9PXOj b0GugqKs9rik/7u0Lqoeb/GNI0L02rFtypBhjfYV8KZBUzysocO9adXRVQQJ6z7lXOd3ZeMYp 6LAJFxVUmVtNSXq+JNWecDoHgIdzZyWr9gvlL3SgwM53j3km3hlBWeJAdHI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13211 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marko Rauhamaa writes: > Arne Babenhauserheide : > >> Marko Rauhamaa writes: >>> Then, there's GOOPS, which in my opinion is simply an unnatural way >>> to go about object-oriented programming. It does violence both to >>> ordinary OO way of thinking and classic Lisp idioms. >> >> GOOPS works pretty well for me where I use it (for dispatch by type). >> Could you clarify your criticism: Do you think it is bad or is it just >> different? > > GOOPS starts by defining slots. Slots are an objects internal business > and should not be visible to the outside. Instead, objects should be > black boxes that interact with methods. For example, the port interface > is a nice, classic OO API. You don't know anything about the slots of a > port. > > Furthermore, I think an extensive type system is un-Lisp-like. OO is not > about things belonging to a type but objects interacting through > methods. In fact, the concept of a "class" could be done away with. > >>> Continuations and multiple values are obstacles instead of enablers. >> >> I think multiple values are nice. But they are not well-integrated (I >> have to import something to use them). Why do you think them enablers? > > Yes, the multiple values API is a problem in and of itself, but more > generally, what does: > > (values a b c) > > give you on top of, say: > > (list a b c) Practically it gives me (let-values (((a b c) (values 1 2 3))) a) I could get the same by using match on a list, but then I have to use match on a list instead of just assigning the values. let-values could be designed to work with lists, though. So conceptually I assume that the real difference is in implementation: avoiding the construction of a list. >> Why do you think that continuations are an obstacle (do you mean >> general continuations or do you mean prompts)? > > Continuations prevent you from implementing Python's try/finally and > emacs' (unwind-protect). If I understand it correctly, this is only true, if there are resources in use which do not get created in the try. I hit that problem when implementing 'with': https://bitbucket.org/ArneBab/wisp/src/3a654cfe6632af4b0002ce98c753c07c400a= ac55/examples/with.w#with.w-8 with (open-file "with.w" "r") as port format #t "~a\n" (read port) ^ working Guile code which ensures that the port is closed after it is no longer used. But it can break if a continuation is used. To fix that, I=E2=80=99d have to add guards which save the state of the port when code creates a continuation and reconstructs that state when the continuation is used. > On the other hand, I don't think any application developer would come to > a point of thinking, "Hey, I know, I'll use a continuation!" Error-handling is simply a specific case of that. In Python people use exceptions for flow control, which can be efficient when the non-exception case is much, much more common than the exception case (because in the first case the overhead of that is almost zero). >>> asyncio, type annotation, >> >> type annotations should provide nice ways to optimize for pypy and >> other more optimizing Python implementations. > > You can't have it bothways. A dynamic language liberates you from > shackles and boilerplate even if it destroys your performance. The > moment you bring in the boilerplate, you are back to Java. It=E2=80=99s optional boilerplate which you only add where you really need = it. >> Decorators are really cool to use: > > Have yet to find a need for one. I used them quite a bit. The most efficient one was a caching decorator: @cached def fun(a): # something expensive return a In Python 3.2 you can use the standard lru-cache for that: https://docs.python.org/3/library/functools.html#functools.lru_cache >>> dunder jungle, >> >> What=E2=80=99s that? > > Ah, yes :) I think these are a good way to show that I as developer am venturing into regions I should only enter when I am really, really sure I want to, because they can cause problems I may not see right away. Sadly this rule is broken with if __name__ =3D=3D "__main__": ... and for def __init__(self) So I think it=E2=80=99s good to have that, but not good that programmers ne= ed to use that during typical programming tasks. >>> meta-object programming, >> >> That=E2=80=99s needed to make some things elegant. "Different 20%"-rule = again. > > Again, I haven't yet found a need to deviate from the regular object > semantics. I saw some, like actually accessing and changing the bytecode at runtime to add tracing commands. >>> Unicode illusion. (Guile has fallen into that last trap as well, >>> unfortunately.) >> >> I=E2=80=99m using Python and Guile for physics and math (to some degree)= , and >> having good Unicode-support is great for that. What=E2=80=99s your pract= ical >> criticism here? > > In Linux, all pathnames, files, sockets, environment variables and > command-line arguments are, or deal with, bytes. The bytes are often > encoded with UTF-8, but a programming language cannot assume that, even > if LOCALE promises otherwise. > > It would be better to leave Unicode out of Guile's system interface and > have the application encode and decode explicitly where needed. I=E2=80=99m not sure about that. Python3 requires explicit encode/decode, a= nd it=E2=80=99s a lot of hassle to port from Py2 to Py3 if your application do= es lots of socket-operations. I have firsthand experience with that, and the debugging is gruesome. But it might have been much better if the program had been created with Python3 from the start. >>> There's one thing Python has over Guile, still: Python's system call >>> support is outstanding. For example, I managed to implement a >>> full-blown shell using Python. That was the first time I ever ran >>> into terminal-related system calls, and Python had them all. >> >> Which ones are missing in Guile? > > For example tcgetattr(3). (Ok, not a system call.) > > Missing epoll(2) is inconvenient. Not being able to transfer an open > file descriptor via sendmsg(2) is really bad. Do you know whether there is a specific reason for that or whether these could be added? Best wishes, Arne =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein ohne es zu merken --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYo4KRAAoJEBPvjUUkA8PrV+0P/jLeLCpYYvx2nEjHpcefx3X6 VsQool3SbLVURtQW67oAYin+tYxwPJbivNeXYtUUx+XHAyXr2dMMmGh+XGpmUwQJ ZzUfTvZHLI1LppVqWsJ69uNj49RZeSaAzr4eO+zwl1eL67GreMUugZ/8R6gMvy+B g2eAjRL34l+PD1pBtoQlI6yW655qxfyIDX9nyB4nTv0sl5YTSxXlaXIZ51kOV4gz ZUxd8Ka73A5pYF10kAKUmNSQA3dIeF+g4EBoPVEZAYTneVB+im4mcVUQjaO9PBOl I/39VQXnuiONQUgrPKKHvCRzGBDq2K1kussc1jwNwjrmzkpHbskhDxowwXacP4ma lAFuYaOGMYWqVOBrKvDYxbLcWmniT8womztdVV0bMnpgjLyJk0n1rwgj06IVQAxF es1XEu1r1W2xFXgUwllLIKRhvffiI+sbUGxoc+3eUYqOTdTssAl8iMpBom0+jG9L 5W7VKzoDy0r/zyyZJZrXimOTHl+mvtnO+uCTUEYPYBoq3GvH/ArrxHzwzXMp5SDB SG46m8GJ508R3xLfYSR/QZNor5aG6doR2ERNrZIjxE8cpQp6vuBriKTqO9BvIgCC L5KWvvmra1QQr0HSKWjWGf6vHSaGb2t0auzhf6Q3Kl6DrX3mzDh9lFSk31ujPgCZ 5Msjz6s8IrnxJ3jUqyOI =1adM -----END PGP SIGNATURE----- --=-=-=--