Email list hosting service & mailing list manager

Practicality of the srfi Shiro Kawai (29 Jun 2016 21:52 UTC)
Re: Practicality of the srfi Marc Nieper-Wißkirchen (30 Jun 2016 14:45 UTC)
Re: Practicality of the srfi Shiro Kawai (30 Jun 2016 21:14 UTC)
Re: Practicality of the srfi Marc Nieper-Wißkirchen (12 Jul 2016 12:07 UTC)
Re: Practicality of the srfi Shiro Kawai (12 Jul 2016 21:00 UTC)
Re: Practicality of the srfi John Cowan (13 Jul 2016 01:07 UTC)
Re: Practicality of the srfi shiro.kawai@xxxxxx (13 Jul 2016 01:38 UTC)
Re: Practicality of the srfi John Cowan (14 Jul 2016 01:27 UTC)

Re: Practicality of the srfi shiro.kawai@xxxxxx 13 Jul 2016 01:38 UTC

But why does it want to avoid r7rs record? Providing procedural record on srfi 137 is just about the same effort as providing one using r7rs record (l mean just use r7rs record as infrastructure, not making the procedural record type be r7rs record type).

> On Jul 12, 2016, at 3:06 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
>
> Shiro Kawai scripsit:
>
>> So, srfi-137 is certainly useful for having portable implementations of
>> experiment / PoC / transient code until it is ported on native type system,
>> etc.   It may serve as a common language of defining type-related systems.
>
> It can also be used in any R7RS-small system to provide a purely procedural
> record system that is not coupled with R7RS-small define-record in any way,
> using the portable SRFI 137 implementation.
>
> --
> John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
> I should say generally that that marriage was best auspiced, for the
> achievement of happiness, which contemplated a relation between a man and a
> woman in which the independence was equal, the dependence mutual, and the
> obligations reciprocal.  --Louis Anspacher (1944)