Re: Wisp as shipped language in Guile?

[Nala Ginrut <nalaginrut@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7060 bytes --]

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_bab@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_bab@web.de> writes:
>
> > Hi Mark,
> >
> > Mark H Weaver <mhw@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
>

[-- Attachment #2: Type: text/html, Size: 8972 bytes --]