Hi Mark, Mark H Weaver <m...@netris.org> writes:
>> Essentially this is about making wisp as language part of the >> "batteries" of Guile. > > About 4.5 years ago, I went out on a limb and added SRFI-105 (curly > infix expressions) to core Guile. Even now, I'm of the opinion that > judicious use of curly infix could be beneficial for readability, but as > far as I can tell, there's been essentially no uptake. If I'm wrong > about that, please let me know. I’ve been using SRFI-105 quite a bit — not only in Wisp. It helped me in reducing the reservations colleagues of mine had against Scheme (prefix-comparisons and prefix-math look odd to many people). > Anyway, regardless of my personal opinion, I think we need to be careful > not to add things to Guile that will go unused and merely contribute to > its increasing bloat. Given that language/wisp (as I have it here) is less than half the size of language/elisp or language/ecmascript, and will require much less maintenance (it is in final form and will automatically benefit from all improvements to Scheme proper — different from both elisp and ecmascript which need to follow a moving target to keep their utility) and that it is less than twice the size of language/brainfuck, I think calling Wisp part of bloat isn’t right. > I think the relevant question is: are a > non-trivial number of people likely to use this? For starters, do you > know anyone writing non-trivial amounts of Wisp code other than > yourself? You might expect that to change if we added it to core Guile, > but that didn't seem to happen with SRFI-105. This depends on what you consider non-trivial. Two weeks ago CalGuixSD said in IRC he’d written the system definition for Guix in Wisp. However he had to give up on that, because it would have required to install Wisp while he did not have Guix yet. (https://gnunet.org/bot/log/guix/2017-05-03). This is actually what prompted me to write here again: In this usecase it acts to facilitate entry into Scheme, because using the language for setup is an obvious case where people get put off by the parens at first. And different from other notations, going from Wisp to regular Scheme is trivial: automatic conversion even keeps the comments. Using Wisp as system language is among the things people can only do when they always have Wisp with Guile — when it’s part of its batteries (along with brainfuck, javascript and elisp). Aside from being a good starter, there are domains where I see Wisp as a different quality of readability, for example when it comes to text-rich formats (I think you know the talk from FOSDEM: https://fosdem.org/2017/schedule/event/naturalscriptwritingguile/ ). Finally I see that Wisp is the one project of mine which generates the most interest (as estimated by people reading its site — easily twice as many as those who have read my Freenet articles (since 2010!) — and from people asking how to use it), so I would like to make Wisp easier for people to use. It seems that Wisp draws people. > So, unless Wisp is being used by more people than I suspect, my personal > take on this is that we should not incorporate Wisp into Guile at this > time. > > On the other hand, if there are sane changes that we can make to Guile > that would facilitate adding support for languages like Wisp and > SRFI-110 to Guile via external libraries, I would absolutely be in favor > of working toward that goal. The main missing piece I see right now would be the option for language/<lang>/spec.scm to automatically add suffixes to %load-extensions when switching to a language and removing them when switching back (along with a solution for .<ext>.go). Or providing a mapping from extension to language. One of these would also be needed for *.el(elisp) and *.js(ecmascript). However this will not allow using Wisp in the REPL on Guile installations without adapting the load path or installing a package systemwide. For usability there is a large difference between guile --language=wisp and guile --language=wisp -L ~/.local/lib/<something> Also if you’re on a readonly system with Guile but without admin-added Wisp, or on a system without internet access, you cannot use Wisp if it is not provided by Guile or the admin/system author. > For example, I've pondered the idea of making the "reader directive" > mechanism (e.g. things like #!curly-infix) easily extensible. For > example, we could perhaps arrange for 'read', when encountering "#!FOO" > in the input stream, to look for a module named something like (system > reader-directives FOO) which would extend the reader as needed. > > What do you think? That sounds useful on its own, though it does not resolve the problem of having to adjust the load path or needing the permission to install systemwide. > PS: While visiting the web page <http://draketo.de/english/wisp> to > refresh my memory about Wisp details, my browser tried to access > port 8888 on my local machine. Looking at your site code, I see > that there's an iframe element with > src="http://127.0.0.1:8888/Sone/viewSone.html?sone=[...]";, and also > an input element with value="http://127.0.0.1:8888";. You might want > to fix those. That iframe is for using a Freenet service (Sone) as decentralized comment system for websites, so these aren’t mistakes per-se. However they got broken by recent security tightening in Freenet, so I actually should remove them until I create a stronger system. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
