Hi Arne! Personally, I'd like to see many languages on Guile. But I prefer maintain mine, guile-lua-rebirth and a new shell language(undone) as an external package. GNU official project reviews contributions too strictly, it's good for the quality and free software ethics, but too difficult for new contributors as a compromise. I will be happy to see if wisp accepted to be in Guile core. But if not, it's not a big deal IMO, especially when we have Guix now. What do you think?
Best regards 2017年8月11日 下午5:11，"Arne Babenhauserheide" <arne_...@web.de>写道： > Hi, > > Any word on this? We have ecmascript, we have elisp, we have brainfuck, > why not wisp — which is finished and stable and does not require any > non-sexp-scheme code in Guile? > > Best wishes, > Arne > > Arne Babenhauserheide <arne_...@web.de> writes: > > > 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 >
