New C5 egg: SRFI-145: Assumptions

[Vasilij Schneidermann-2]

Hello everyone,

I've implemented SRFI-145 in terms of the existing assert macro.
`salmonella` and `test-new-egg` run fine with
<https://depp.brause.cc/srfi-145/srfi-145.release-info>.  A wiki page is
ready to be submitted after inclusion into the coop.

This egg is part of an effort to get SRFI-168 (Generic Tuple Store
Database) working.  I plan to port SRFI-158 (Generators), SRFI-146
(Mappings), SRFI-167 (Ordered Key Value Store) and the
persistent-hash-map egg (currently C4-only, with no customizable
hash/equality procedures), then to create an egg for a suitable
persistent ordered key-value store (for example the sophia database) and
another one for a compatible interface for use by SRFI-168.

Vasilij

[Vasilij Schneidermann-2]

Hello again,

SRFI-158 (Generators) is ready as well:
https://depp.brause.cc/srfi-158/srfi-158.release-info

Vasilij

[Jeremy Steward]

Ooh boy, is SRFI 158 ready to go?

If that's the case, should we deprecate / remove SRFI 121 from the coop?

I am currently the maintainer, but am happy to focus efforts on 158 over 121.
--
Jeremy Steward

[Vasilij Schneidermann-2]

Hello Jeremy,

> If that's the case, should we deprecate / remove SRFI 121 from the coop?

SRFI-121 is only in the C4 coop and likewise SRFI-158 only in the C5
one, so I don't see any need for removal.  A deprecation notice could be
added for SRFI-121 to the C4 wiki page.   If you insist you could add a
stub C5 wiki page pointing out the existence of SRFI-158, much like it
was done with readline/breadline: https://wiki.call-cc.org/eggref/5/readline

Vasilij

[Mario Domenech Goulart-4]

On Mon, 9 Nov 2020 12:58:37 +0100 Vasilij Schneidermann <[hidden email]> wrote:

> I've implemented SRFI-145 in terms of the existing assert macro.
> `salmonella` and `test-new-egg` run fine with
> <https://depp.brause.cc/srfi-145/srfi-145.release-info>.  A wiki page is
> ready to be submitted after inclusion into the coop.
>
> This egg is part of an effort to get SRFI-168 (Generic Tuple Store
> Database) working.  I plan to port SRFI-158 (Generators), SRFI-146
> (Mappings), SRFI-167 (Ordered Key Value Store) and the
> persistent-hash-map egg (currently C4-only, with no customizable
> hash/equality procedures), then to create an egg for a suitable
> persistent ordered key-value store (for example the sophia database) and
> another one for a compatible interface for use by SRFI-168.

Thanks Vasilij!  Your egg has been added to the coop.

All the best.
Mario
--
http://parenteses.org/mario

[Mario Domenech Goulart-4]

On Mon, 9 Nov 2020 18:04:30 +0100 Vasilij Schneidermann <[hidden email]> wrote:

> SRFI-158 (Generators) is ready as well:
> https://depp.brause.cc/srfi-158/srfi-158.release-info

Thanks again.  It's been added as well.

All the best.
Mario
--
http://parenteses.org/mario

[noosphere]

A couple more considerations to take in to account:

First, even if both eggs were available for Chicken 5, is 158 fully
backwards compatible with 121?  If not, then it might not be the best
idea to remove 121.

Second, I think it's a good idea for Chicken to have more eggs rather
than less because some people may look at the list of libraries or supported
SRFIs as one of their considerations when choosing which language to use,
so it just looks good for Chicken to have more eggs, when looked at from
comparison tables like these:

  https://htmlpreview.github.io/?https://github.com/schemedoc/srfi-metadata/blob/master/table.html

If we can get that SRFI list full, Chicken will look very good indeed.
Gaps in the table, on the other hand, look bad.

Also, if someone is considering porting some library or application that
requires SRFI-121, they might not know that they could substitute 158,
and would just see that Chicken doesn't support 121 so might give up
without investigating further.

So, again, I would err on the side of leaving in already existign
support unless there's a compelling reason to remove it.

  --Sergey

On Mon 09 Nov 2020 07:22:32 PM +01, Vasilij Schneidermann wrote:

>
> Hello Jeremy,
>
>> If that's the case, should we deprecate / remove SRFI 121 from the coop?
>
> SRFI-121 is only in the C4 coop and likewise SRFI-158 only in the C5
> one, so I don't see any need for removal.  A deprecation notice could be
> added for SRFI-121 to the C4 wiki page.   If you insist you could add a
> stub C5 wiki page pointing out the existence of SRFI-158, much like it
> was done with readline/breadline: https://wiki.call-cc.org/eggref/5/readline
>
> Vasilij

[Mario Domenech Goulart-4]

Hi Jeremy,

On Mon, 09 Nov 2020 10:13:19 -0700 Jeremy Steward <[hidden email]> wrote:

> Ooh boy, is SRFI 158 ready to go?
>
> If that's the case, should we deprecate / remove SRFI 121 from the coop?
>
> I am currently the maintainer, but am happy to focus efforts on 158 over 121.

Thanks for following up on that.

Regardless of the decision on that, the srfi-121 egg will stay in the
coop.  It can be deprecated, but never removed (considering the CHICKEN
major version it is available for).

All the best.
Mario
--
http://parenteses.org/mario

[Jeremy Steward]

>> SRFI-121 is only in the C4 coop and likewise SRFI-158 only in the C5
>> one, so I don't see any need for removal.  A deprecation notice could
>be
>> added for SRFI-121 to the C4 wiki page.   If you insist you could add
>a
>> stub C5 wiki page pointing out the existence of SRFI-158, much like
>it
>> was done with readline/breadline:
>https://wiki.call-cc.org/eggref/5/readline

Actually, CHICKEN 5 support for SRFI 121 was added earlier this year, so it should be in the coop?

>Second, I think it's a good idea for Chicken to have more eggs rather
>than less because some people may look at the list of libraries or
>supported
>SRFIs as one of their considerations when choosing which language to
>use,
>so it just looks good for Chicken to have more eggs, when looked at
>from
>comparison tables like these:

I would disagree, in that sometimes less is more. SRFI names are baroque and hard to parse in the first place, and presenting a (mostly false) choice to users can create confusion and anxiety. I am completely on board with updating the 121 docs to point to 158 over completely removing it from the coop, though, so as not to yank the library out from anyone who may currently be using it (and doesn't want a harsh transition).

I guess in essence, I don't want to pull a leftpad.js :-)
--
Jeremy Steward

[John Cowan]

FWIW, SRFI 158 is fully downwardly compatible.

On Mon, Nov 9, 2020 at 1:40 PM Mario Domenech Goulart <[hidden email]> wrote:

Hi Jeremy,

On Mon, 09 Nov 2020 10:13:19 -0700 Jeremy Steward <[hidden email]> wrote:

> Ooh boy, is SRFI 158 ready to go?
>
> If that's the case, should we deprecate / remove SRFI 121 from the coop?
>
> I am currently the maintainer, but am happy to focus efforts on 158 over 121.

Thanks for following up on that.

Regardless of the decision on that, the srfi-121 egg will stay in the
coop.  It can be deprecated, but never removed (considering the CHICKEN
major version it is available for).

All the best.
Mario
--
http://parenteses.org/mario

[Vasilij Schneidermann-2]

SRFI-146 is ready for inclusion as well:
https://depp.brause.cc/srfi-146/srfi-146.release-info

Vasilij

[Mario Domenech Goulart-4]

On Tue, 10 Nov 2020 01:26:33 +0100 Vasilij Schneidermann <[hidden email]> wrote:

> SRFI-146 is ready for inclusion as well:
> https://depp.brause.cc/srfi-146/srfi-146.release-info

Thanks!  Your egg has been added to the coop.

All the best.
Mario
--
http://parenteses.org/mario