Re: Wisp as shipped language in Guile?

[Nala Ginrut]

Well yes, it looks good if we have it. And I could let users of Artanis
write HTML template like Ruby slim.
http://slim-lang.com/

2017年9月19日 下午10:10，"Christopher Allan Webber" 写道：

> Matt Wette writes:
>
> >> On Sep 17, 2017, at 4:22 PM, Arne Babenhauserheide 
> wrote:
> >>
> >>
> >> Matt Wette  writes:
> >>> Looks promising, especailly if the footprint is small.
> >>> Can someone post the sample guix specification?
> >>> I could not access from the gnunet log.
> >>
> >> Do you mean the wisp package for Guix?
> >
> > No, I meant the guix package spec for package foo written in wisp.
> >
> > define-public foo
> >package
> >   name "guile-wisp"
> >   source : origin
> >  ...
>
> https://dustycloud.org/blog/wisp-lisp-alternative/
>
>

Re: Wisp as shipped language in Guile?

[Christopher Allan Webber]

Matt Wette writes:

>> On Sep 17, 2017, at 4:22 PM, Arne Babenhauserheide  wrote:
>> 
>> 
>> Matt Wette  writes:
>>> Looks promising, especailly if the footprint is small.  
>>> Can someone post the sample guix specification?
>>> I could not access from the gnunet log.
>> 
>> Do you mean the wisp package for Guix?
>
> No, I meant the guix package spec for package foo written in wisp.
>
> define-public foo
>package 
>   name "guile-wisp"
>   source : origin 
>  ...

https://dustycloud.org/blog/wisp-lisp-alternative/

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Matt Wette  writes:
> On Sep 17, 2017, at 4:22 PM, Arne Babenhauserheide  wrote:
>> Matt Wette  writes:
>>> Looks promising, especailly if the footprint is small.  
>>> Can someone post the sample guix specification?
>>> I could not access from the gnunet log.
>> 
>> Do you mean the wisp package for Guix?
>
> No, I meant the guix package spec for package foo written in wisp.
>
> define-public foo
>package 
>   name "guile-wisp"
>   source : origin 
>  ...

Ah, yes. I don’t have that yet. I’ll try it — ideally in a way which
allows calling guix environment with it — but it may take a few days (I
can’t experiment at all times).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Matt Wette]

> On Sep 17, 2017, at 4:22 PM, Arne Babenhauserheide  wrote:
> 
> 
> Matt Wette  writes:
>> Looks promising, especailly if the footprint is small.  
>> Can someone post the sample guix specification?
>> I could not access from the gnunet log.
> 
> Do you mean the wisp package for Guix?

No, I meant the guix package spec for package foo written in wisp.

define-public foo
   package 
  name "guile-wisp"
  source : origin 
 ...


Thanks,
Matt

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Matt Wette  writes:
> Looks promising, especailly if the footprint is small.  
> Can someone post the sample guix specification?
> I could not access from the gnunet log.

Do you mean the wisp package for Guix?

It’s here:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm?id=v0.13.0-2323-g35131babc#n1251

guile-wisp

Wisp is really just parsing the code structure differently:

- it creates the tree structure by adding parens for indentation
  - in chunks delimited by double-empty-lines
  - with syntax for double-parens and
  - generalizing the dot prefix from (equal? 1 (. 1)) to meaning "this
line does not start with a parenthesis" and

- treats the result as regular Scheme.

(plus the nitty gritty to make that work with string-parsing, character
literals, quoting, unquoting and so on)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Matt Wette]

Looks promising, especailly if the footprint is small.  
Can someone post the sample guix specification?
I could not access from the gnunet log.

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Hi Nala,

Nala Ginrut  writes:

> 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?

I would prefer to invest the work needed to get wisp accepted into Guile
core, because that opens up new usecases and makes using it much easier
for new users on multiple platforms.

Wisp as external package is already available and gets much more
attention than I had anticipated (easily more than anything else on my
site) and I’d like to remove the hurdle of having to install a package.

I think the maintenance effort won’t be a limiting factor, because Wisp
is pretty much completed. I did not see any need to add anything for
more than two years, and the core code changed very little while I
experiemented with structures which do not need any work on the parser
itself. It might need minor fixes or tweaks, but aside from that I see
wisp the Guile-language as done.

Thanks to syntax-case, they can be implemented without having to touch
anything in modules/language/. One example is duel, which turns this
into a valid game script:


Enter : Galtag Nimbleday
___ Lowlife Pirate

Lowlife Pirate
_ You will lay down your life today!

Galtag Nimbleday
_ We’ll see about that.

Duel
_ Galtag Nimbleday
_ Lowlife Pirate


(the underscores are added to ensure that this code is still valid if
copied from a non-indentation-preserving mailing list archive site)

This is the advantage of making Wisp an extremely thin wrapper around
Scheme (actually the thinnest possible full-featured¹ indentation-based
representation of Scheme I could find): Whatever is added in Guile is
directly available via Wisp.

¹: with full-featured meaning that the Wisp can represent any and all
   Scheme structures without overly ugly corner-cases and without
   crutches: it has no special casing for stuff which is en vogue today.

Therefore I want to get it included as a standard language in Guile.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Nala Ginrut]

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" 写道：

> 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  writes:
>
> > Hi Mark,
> >
> > Mark H Weaver  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//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 ..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
> > 

more extensible reader directive, was: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Arne Babenhauserheide  writes:

>> 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

After pondering this a bit, I’m worried that this might push people
towards using reader directives as a replacement for
syntax-definitions. One problem with that is that reader directives
aren’t necessarily composable: While srfi-105 and srfi-119 compose well,
the indentation parsing in srfi-119 and srfi-110 is mutually exclusive.


For Racket I have the impression that this has the effect that the
easiest way to experiment is to define a new language. The main reason
why I think that is #lang typed/racket: Instead of creating a
(define-typed ...) syntax, which would have been available in all
languages, they added the (: ...)  special form.
(https://docs.racket-lang.org/ts-guide/quick.html)

When you define something in a module, it can be used in other languages
— including ecmascript and elisp. More exactly: You know that it can be
(at least I think that — I used Guile features from ecmascript: Is there
a limit to that which I did not hit?). With reader adjustments that’s
different.

However in Racket which started as a teaching language, this easier
experimentation likely outweights the cost of fragmentation into
different structures which cannot easily be used together. If you have
lots of students going into lots of different directions, and you don’t
actually want to recombine their work in specific applications, then you
can easily afford the price of limited composability.


But I’m biased in this: To avoid such fragmentation while providing
indentation-based syntax (which cannot be done at all without adjusting
the reader), I tried to keep the reader adaption in Wisp as minimal as
possible — to defer to regular Scheme as quickly as possible. This
should minimize friction from different approaches for tackling
problems, making it easy for people who start with Wisp to understand
any Scheme code (and vice versa).


Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Hi Mark,

Mark H Weaver  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//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 ..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/

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  to
> refresh my memory about Wisp details, my browser tried to access
> port  on my local machine.  Looking at your site code, I 

Re: Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Panicz Maciej Godek  writes:

> 2017-05-13 3:52 GMT+02:00 Mark H Weaver :
>
>> Hi Arne,
>>
>> Arne Babenhauserheide  writes:
>> > A few weeks ago I asked in IRC whether wisp[1] could be included with
>> > Guile in modules/language/wisp to allow every guile users to run wisp
>> > code from any Guile installation via
>> >
>> >
>> > $ guile --language=wisp []
>> >
>> >
>> > 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’m using curly infix in cond-expressions, both with wisp and with
regular Scheme:

(cond
  ({a < 5}
   (something)
   (more))
  ({a > 7}
   (something-else)))

cond
  : {a < 5}
something
more
  : {a > 7}
something-else


>> Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
>> say the same of either Wisp or SRFI-110 (Sweet expressions).
>>
> "The idea of introducing Algol-like syntax into Lisp keeps popping up and
> has seldom failed to create enormous controversy between those who find the
> universal use of S-expressions a technical advantage
…

This is a nice read, but does not apply to Wisp itself, since Wisp just
infers the parentheses from indentation but otherwise does not change
anything.

It does apply to some degree to SRFI-105, but not fully.
A rationale is provided here:
https://web.archive.org/web/20160505180131/http://srfi.schemers.org/srfi-105/srfi-105.html#rationale_changereader

(being able to use infix for pattern matching)

That said: I like is as infix very much and would love to see it
included — e.g. in (ice-9 is).

On the other hand, a SRFI for is would make it easier to build
cross-system scheme with it.

> and (is x < y <= z) is more concise than (and (< x y) (<= y z)).

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: Wisp as shipped language in Guile?

[Panicz Maciej Godek]

2017-05-13 3:52 GMT+02:00 Mark H Weaver :

> Hi Arne,
>
> Arne Babenhauserheide  writes:
> > A few weeks ago I asked in IRC whether wisp[1] could be included with
> > Guile in modules/language/wisp to allow every guile users to run wisp
> > code from any Guile installation via
> >
> >
> > $ guile --language=wisp []
> >
> >
> > 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.
>
> Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
> say the same of either Wisp or SRFI-110 (Sweet expressions).
>
>
"The idea of introducing Algol-like syntax into Lisp keeps popping up and
has seldom failed to create enormous controversy between those who find the
universal use of S-expressions a technical advantage (and don’t mind the
admitted relative clumsiness of S-expressions for numerical expressions)
and those who are certain that algebraic syntax is more concise, more
convenient, or even more natural (whatever that may mean, considering that
all these notations are artificial).

We conjecture that Algol-style syntax has not really caught on in the Lisp
community as a whole for two reasons. First, there are not enough special
symbols to go around. When your domain of discourse is limited to numbers
or characters, there are only so many operations of interest, and it is not
difficult to assign one special character to each and be done with it. But
Lisp has a much richer domain of discourse, and a Lisp programmer often
approaches an application as yet another exercise in language design; the
style typically involves designing new data structures and new functions to
operate on them—perhaps dozens or hundreds—and it’s just too hard to invent
that many distinct symbols (though the APL community certainly has tried).
Ultimately one must always fall back on a general function-call notation;
it’s just that Lisp programmers don’t wait until they fail.

Second, and perhaps more important, Algol-style syntax makes programs look
less like the data structures used to represent them. In a culture where
the ability to manipulate representations of programs is a central
paradigm, a notation that distances the appearance of a program from the
appearance of its representation as data is not likely to be warmly
received (and this was, and is, one of the principal objections to the
inclusion of loop in Common Lisp).

On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to experiment
with alternative notations.  Therefore we expect future generations of Lisp
programmers to continue to reinvent Algol-style syntax for Lisp, over and
over and over again, and we are equally confident that they will continue,
after an initial period
of infatuation, to reject it. (Perhaps this process should be regarded as a
rite of passage for Lisp hackers.)"

Guy L. Steele, Jr. and Richard P. Gabriel, "The Evolution of Lisp"

My personal opinion is that adding new ways for expressing the same thing
that can already be expressed in the language is a bad thing, because it
only increases the entropy of your code base.

When it comes to readability, I don't think that we need to make the reader
syntax more complex. What we need is an editor with a good typesetting
feature, so that various programmers could use the formatting of their
liking (say, making their code look more like Haskell or more like Julia or
some other mathematical idols like Mathematica) without making any invasive
changes to the code base.

When it comes to curly infix, I don't think that it really is an advantage
for arithmetic expressions. But I do agree that infix expressions are
actually clarifying in the case of asymmetrical binary relations: x < y is
a bit more obvious than (< x y). However, this can be achieved using
regular Scheme syntax, say, with the following macros:

(define-syntax infix (syntax-rules ()
  ((_ x related-to? y)
   (related-to? x y))
  ((_ x related-to? y . likewise)
   (and (infix x related-to? y)
(infix y . likewise)

(define-syntax is (syntax-rules (_)
  ((is _ related-to? right . likewise)
   (lambda (_)
 (infix _ related-to? right . likewise)))

  ((is left related-to? _ . likewise)
   (lambda (_)
 (infix left related-to? _ . likewise)))

  ((is x related-to? y . likewise)
   (infix x related-to? y . likewise))

  ((is x) ;; thanks to Arne's earlier suggestions
   (lambda (y)
 (equal? x y)))

  ((is left relation) ;; same as "(is left relation _)"
   (lambda (right)
 (relation left right)

Perhaps the "is" macro allows more than it should, and "infix" 

Re: Wisp as shipped language in Guile?

[Mark H Weaver]

Hi Arne,

Arne Babenhauserheide  writes:
> A few weeks ago I asked in IRC whether wisp[1] could be included with
> Guile in modules/language/wisp to allow every guile users to run wisp
> code from any Guile installation via
>
>
> $ guile --language=wisp []
>
>
> 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.

Although (a subset of) SRFI-105 seems like a clear win to me, I cannot
say the same of either Wisp or SRFI-110 (Sweet expressions).  Of those
latter two efforts, I prefer Wisp, and I can understand the motivation
for wanting to eliminate the parens, but to these eyes the cure seems
worse than the disease.  I tend to agree with Sylvain Benner, who you
quote on your site as saying "I find it less readable and actually it
adds complexity to the syntax because you have to deal with 3 components
to understand the structure [...] So in fact you add 2 more constructs
for readability which IMHO has not the expected effect on most 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.  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.

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.

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?

 Regards,
   Mark


PS: While visiting the web page  to
refresh my memory about Wisp details, my browser tried to access
port  on my local machine.  Looking at your site code, I see
that there's an iframe element with
src="http://127.0.0.1:/Sone/viewSone.html?sone=[...];, and also
an input element with value="http://127.0.0.1:;.  You might want
to fix those.

Re: Wisp as shipped language in Guile?

[Christopher Allan Webber]

Arne Babenhauserheide writes:

> Hi,
>
>
> A few weeks ago I asked in IRC whether wisp[1] could be included with
> Guile in modules/language/wisp to allow every guile users to run wisp
> code from any Guile installation via
>
>
> $ guile --language=wisp []
>
>
> Essentially this is about making wisp as language part of the
> "batteries" of Guile. I think it currently is at a point in its
> development where that’s useful, because wisp itself shouldn’t need
> major changes (and hopefully not many minor ones either, since it only
> transforms its syntax to Scheme and then lets the compiler tower take
> over).
>
>
> I got the answer that a viable path would be to add a wip-wisp branch in
> savannah. What would be required for that? Basics I know are:
>
> - copyright assignment (who can get me the papers to sign?)
> - access to https://savannah.gnu.org/projects/guile — should I get push
>   access or rather send patches here?
>
> Did I miss something?
>
>
> Best wishes,
> Arne
>
> [1]: http://draketo.de/english/wisp

+1 to wisp in Guile proper :)

Wisp as shipped language in Guile?

[Arne Babenhauserheide]

Hi,


A few weeks ago I asked in IRC whether wisp[1] could be included with
Guile in modules/language/wisp to allow every guile users to run wisp
code from any Guile installation via


$ guile --language=wisp []


Essentially this is about making wisp as language part of the
"batteries" of Guile. I think it currently is at a point in its
development where that’s useful, because wisp itself shouldn’t need
major changes (and hopefully not many minor ones either, since it only
transforms its syntax to Scheme and then lets the compiler tower take
over).


I got the answer that a viable path would be to add a wip-wisp branch in
savannah. What would be required for that? Basics I know are:

- copyright assignment (who can get me the papers to sign?)
- access to https://savannah.gnu.org/projects/guile — should I get push
  access or rather send patches here?

Did I miss something?


Best wishes,
Arne

[1]: http://draketo.de/english/wisp
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature