Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Hi Mark,

Mark H Weaver <address@hidden> 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