TODO list for Guile R7RS support

TODO list for Guile R7RS support

[Mark H Weaver]

Hello all,

I skimmed through the R7RS (draft 5) looking for things we need to do to
claim full compliance.  Here's the list I came up with.

    Mark


R7RS TODO
=========
* optional ellipsis specifier for syntax-rules et al
* syntax-error
* define-values
* let-values and let*-values (without loading SRFI-11)
* include-ci
* bytevectors in core R7RS
* lazy and eager (without loading SRFI-45)
* |...| symbol notation, and \xXX within symbols
* support #\escape and "\escape"
* support \xXXXX in string literals
* allow whitespace between \ and newline in string literals
* #!fold-case and #!no-fold-case
* #true and #false
* datum labels for circular and shared substructures
* nan? and finite? now accept complex numbers
  (should probably change inf? and infinite? as well)
* exact-integer?
* R7RS exceptions
* make sure define-record-type is R7RS compliant
* optional third parameter to 'member' and 'assoc'
* define-library
* digit-value
* char-foldcase
* string-ni=? et al
* vector->string and string->vector
* vector-copy supports optional (start end fill) args
* vector-fill! supports optional (start end) args
* bytevector-copy! with 3 args
* bytevector-copy-partial{,!}
* write bytevectors with #u8 (and elements in hex) by default?
* {map,for-each} stops when shortest list runs out
* string-{map,for-each} accepts multiple strings
* vector-{map,for-each}
* make sure {map,vector-map,string-map} are multi-return safe
* {scheme-report,null}-environment for R7RS
* 'environment'
* 'port-open?'
* R7RS binary ports and bytevector ports
   * {textual-binary}-port?
   * binary-port?
   * open-binary-{input,output}-file
   * open-{input,output}-bytevector
   * get-output-bytevector
   * {read,peek,write}-u8, u8-ready?
   * read-bytevector{,!}
   * write-bytevector
   * write-partial-bytevector
* read-line
* write-simple
* flush-output-port
* load with optional 'environment specifier' as second argument
* get-environment-variable{,s}
* current-{second,jiffy}, jiffies-per-second
* R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
  ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
  freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
  lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> * bytevectors in core R7RS

What does it mean?  That bindings are available by default?

[...]

> * bytevector-copy! with 3 args
> * bytevector-copy-partial{,!}

[...]

> * R7RS binary ports and bytevector ports
>    * {textual-binary}-port?
>    * binary-port?
>    * open-binary-{input,output}-file
>    * open-{input,output}-bytevector
>    * get-output-bytevector
>    * {read,peek,write}-u8, u8-ready?
>    * read-bytevector{,!}
>    * write-bytevector
>    * write-partial-bytevector

Seems to be that, following R6RS’ lead, R7RS decided to come up with
new APIs that are close to, but slightly from, existing APIs.  :-/

[...]

> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0

I wonder how these are specified.  Does a *-kfreebsd-gnu build have
‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
isn’t used?  Does Cygwin have ‘unix’?

And above all: are people going to write #ifdef __linux__ish code when
what they mean is #ifdef __GLIBC__ or even something different?

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> * bytevectors in core R7RS
>
> What does it mean?  That bindings are available by default?

Yes.

>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>
> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
> isn’t used?  Does Cygwin have ‘unix’?
>
> And above all: are people going to write #ifdef __linux__ish code when
> what they mean is #ifdef __GLIBC__ or even something different?

Yes, this is a very good point, and one that should be raised with the
R7RS working group.  The C library is usually far more relevant to user
code than the kernel.  This strikes me as another instance of the
widespread confusion that "linux" is an operating system, when in fact
it is only a kernel.  It would be a shame for this confusion to be
codified into the R7RS.

    Thanks,
      Mark

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:

[...]

>>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>>
>> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
>> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
>> isn’t used?  Does Cygwin have ‘unix’?
>>
>> And above all: are people going to write #ifdef __linux__ish code when
>> what they mean is #ifdef __GLIBC__ or even something different?
>
> Yes, this is a very good point, and one that should be raised with the
> R7RS working group.  The C library is usually far more relevant to user
> code than the kernel.  This strikes me as another instance of the
> widespread confusion that "linux" is an operating system, when in fact
> it is only a kernel.

Exactly, and it goes beyond the “GNU slash Linux” issue, as I illustrated.

> It would be a shame for this confusion to be codified into the R7RS.

Indeed.  If you’re following R7RS discussions, could you raise the
issue?

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Alex Shinn]

On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>
> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
> isn’t used?  Does Cygwin have ‘unix’?

First note the list of feature identifiers is one of the
things most likely to be trimmed in the next draft.

There is no "gnu" feature proposed in R7RS, though
Guile can of course define whatever non-portable
features it needs.  I don't see why "gnu" would imply
"linux".

The point about the "unix" feature being vague is well
taken.  I think it's meant to be widely encompassing
and refer to Unix-like systems, including cygwin, with
a guarantee of a Bourne-like shell in /bin/sh and common
Unix programs like cp, rm, ls etc. available, but we'll
be sure to revisit this.

> And above all: are people going to write #ifdef __linux__ish code when
> what they mean is #ifdef __GLIBC__ or even something different?

This particular analogy doesn't apply.  As I see with
the current list of proposed features the only confusion
is in the granularity of the feature to use, where, e.g.

  freebsd < bsd < posix, unix

as opposed to two completely unrelated concepts like
OS and libc.

Regardless, we're likely to add a disclaimer that you
should only resort to cond-expanded code as a last
resort.

-- 
Alex

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi Alex,

Thanks for your feedback.

Alex Shinn <alexshinn@gmail.com> skribis:

> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>>
>> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
>> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
>> isn’t used?  Does Cygwin have ‘unix’?
>
> First note the list of feature identifiers is one of the
> things most likely to be trimmed in the next draft.

Good.  :-)

> There is no "gnu" feature proposed in R7RS,

That would be for GNU, aka. GNU/Hurd.

> The point about the "unix" feature being vague is well
> taken.

It’s not just ‘unix’, see the above examples.

>> And above all: are people going to write #ifdef __linux__ish code when
>> what they mean is #ifdef __GLIBC__ or even something different?
>
> This particular analogy doesn't apply.

IMO it applies in the sense that, as with C code, people will check for
‘linux’ when what they really care about is what the libc provides, or
whether the core utilities support --color, etc.

The libc/kernel confusion has been causing a lot of troubles to people
porting C applications from GNU/Linux to GNU/kFreeBSD and GNU/Hurd.
This class of problem should be avoided as much as possible.

[...]

> Regardless, we're likely to add a disclaimer that you
> should only resort to cond-expanded code as a last
> resort.

Yes, definitely.

I haven’t checked whether R7RS has something like that, but I think it
would be nice to provide well-defined, fine-grain indicators instead.
For instance, a ‘file-separator’ variable, which would be ‘/’ on Unices
and Cygwin, and ‘\’ on raw Windows.

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Alex Shinn]

On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi Alex,
>
> Thanks for your feedback.
>
> Alex Shinn <alexshinn@gmail.com> skribis:
>
>> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>
>>>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>>>
>>> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
>>> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
>>> isn’t used?  Does Cygwin have ‘unix’?
>>
>> First note the list of feature identifiers is one of the
>> things most likely to be trimmed in the next draft.
>
> Good.  :-)
>
>> There is no "gnu" feature proposed in R7RS,
>
> That would be for GNU, aka. GNU/Hurd.

Wouldn't the feature be better named "hurd" then?

How can a system be both Hurd and Linux?

>>> And above all: are people going to write #ifdef __linux__ish code when
>>> what they mean is #ifdef __GLIBC__ or even something different?
>>
>> This particular analogy doesn't apply.
>
> IMO it applies in the sense that, as with C code, people will check for
> ‘linux’ when what they really care about is what the libc provides, or
> whether the core utilities support --color, etc.

Yes, but you're talking about C features, when we
only have to worry about Scheme features, so I need
more relevant examples to be able to give explanations
or take corrective action.

> I haven’t checked whether R7RS has something like that, but I think it
> would be nice to provide well-defined, fine-grain indicators instead.
> For instance, a ‘file-separator’ variable, which would be ‘/’ on Unices
> and Cygwin, and ‘\’ on raw Windows.

Presumably this would be part of the R7RS large
pathnames library.

-- 
Alex

Re: TODO list for Guile R7RS support

[William ML Leslie]

On 13 February 2012 10:57, Alex Shinn <alexshinn@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Alex Shinn <alexshinn@gmail.com> skribis:
>>> There is no "gnu" feature proposed in R7RS,
>>
>> That would be for GNU, aka. GNU/Hurd.
>
> Wouldn't the feature be better named "hurd" then?
>
> How can a system be both Hurd and Linux?

A GNU configuration option would seem to me to specify that any
feature that 'all GNU systems' support must be available; regardless
of which kernel it is running on.

-- 
William Leslie

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi,

Alex Shinn <alexshinn@gmail.com> skribis:

> On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <ludo@gnu.org> wrote:

>> Alex Shinn <alexshinn@gmail.com> skribis:
>>
>>> On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>
>>>>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
>>>>>   ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
>>>>>   freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
>>>>>   lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>>>>
>>>> I wonder how these are specified.  Does a *-kfreebsd-gnu build have
>>>> ‘freebsd’?  And ‘bsd’?  Do *-gnu* have ‘linux’ defined, even when Linux
>>>> isn’t used?  Does Cygwin have ‘unix’?
>>>
>>> First note the list of feature identifiers is one of the
>>> things most likely to be trimmed in the next draft.
>>
>> Good.  :-)
>>
>>> There is no "gnu" feature proposed in R7RS,
>>
>> That would be for GNU, aka. GNU/Hurd.
>
> Wouldn't the feature be better named "hurd" then?

Well, no, because the operating system is called “GNU”, or “GNU/Hurd”
(“the Hurd” designates the “kernel”, not the OS.)

> How can a system be both Hurd and Linux?

For GNU/Linux, one could imagine adding a ‘linux-gnu’ symbol, for
instance.  Likewise for GNU/kFreeBSD.

>>>> And above all: are people going to write #ifdef __linux__ish code when
>>>> what they mean is #ifdef __GLIBC__ or even something different?
>>>
>>> This particular analogy doesn't apply.
>>
>> IMO it applies in the sense that, as with C code, people will check for
>> ‘linux’ when what they really care about is what the libc provides, or
>> whether the core utilities support --color, etc.
>
> Yes, but you're talking about C features, when we
> only have to worry about Scheme features, so I need
> more relevant examples to be able to give explanations
> or take corrective action.

These aren’t necessarily C features.  I think one has to think about
what these features would be used for.

I’m quite confident that in many cases people would be checking for,
say, ‘linux’, when what they’re interested in is a particular feature of
the GNU/Linux environment, not specifically the kernel; or they’d be
checking for ‘unix’ when what they want to know is whether to use slash
or backslash to separate path components; etc.

In general, I think fine-grain feature checks should be encouraged over
coarse-grain identity checks, because it’s likely to be more robust.

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Alex Shinn]

On Mon, Feb 13, 2012 at 8:50 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Alex Shinn <alexshinn@gmail.com> skribis:
>> On Mon, Feb 13, 2012 at 8:46 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Alex Shinn <alexshinn@gmail.com> skribis:
>>>
>>>> There is no "gnu" feature proposed in R7RS,
>>>
>>> That would be for GNU, aka. GNU/Hurd.
>>
>> Wouldn't the feature be better named "hurd" then?
>
> Well, no, because the operating system is called “GNU”, or “GNU/Hurd”
> (“the Hurd” designates the “kernel”, not the OS.)

Well, the suggested "linux" also designates the kernel (and also
arguably the OS depending on what definition you choose).

The list of OS features is not exhaustive - it includes arbitrarily "freebsd"
but not "netbsd" or "openbsd", for instance, and does not include
minor operating systems like "plan9" (already used in chibi).  We
should probably flesh it out a little more, and clarify granularity -
do we include separate features for kernels, OSes and distributions?

>> How can a system be both Hurd and Linux?
>
> For GNU/Linux, one could imagine adding a ‘linux-gnu’ symbol, for
> instance.  Likewise for GNU/kFreeBSD.

I'd like to hear feature recommendations, but you'd need specific
examples of where such features would be useful.  Almost all of
the suggested features are already used in existing libraries, and
those that aren't are likely to be removed.

-- 
Alex

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi,

Alex Shinn <alexshinn@gmail.com> skribis:

> On Mon, Feb 13, 2012 at 8:50 PM, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> For GNU/Linux, one could imagine adding a ‘linux-gnu’ symbol, for
>> instance.  Likewise for GNU/kFreeBSD.
>
> I'd like to hear feature recommendations, but you'd need specific
> examples of where such features would be useful.

Sorry for being unclear.

I’m actually arguing that these feature symbols are largely useless, for
they cannot be rigorously specified and would almost certainly lead to
misuses.

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Andy Wingo]

Hi,

On Thu 16 Feb 2012 22:05, ludo@gnu.org (Ludovic Courtès) writes:

> I’m actually arguing that these feature symbols are largely useless, for
> they cannot be rigorously specified and would almost certainly lead to
> misuses.

I very much agree.  I think that the R7RS should specify no features
that relate to operating systems.

Andy
-- 
http://wingolog.org/

Re: TODO list for Guile R7RS support

[Andy Wingo]

Hi Mark!

Hope all is well.  I'm behind as usual.  Just an additional perspective
here.

On Thu 09 Feb 2012 06:09, Mark H Weaver <mhw@netris.org> writes:

> R7RS TODO

I think you probably agree, but we should be clear about it in any case:
the current drafts are not final.  I look forward to R7RS being a report
that Guile can happily support.  However I think there is room for some
discussion on various points, before the final version comes out :)

Most things are well-thought-out and I won't comment on them.

> * let-values and let*-values (without loading SRFI-11)

This and other "what bindings are visible" questions can be solved
without affecting Guile's default environment, as Guile supports
`library' without having R6RS libs in its default environment.

That said, it might make sense to expose more bindings to the default
environment.  The mounting number of bindings makes me cringe, but hey,
maybe it's the right thing?  Dunno.

> * |...| symbol notation, and \xXX within symbols

I'm looking forward to |...|.  \xXX are r6rs hex escapes, which are off
by default it seems.  Should we turn it on by default?

> * support \xXXXX in string literals

Again, supported, but off by default currently; to flip in 2.2?

> * allow whitespace between \ and newline in string literals

A bug in the spec, I think:

  http://thread.gmane.org/gmane.lisp.guile.bugs/4859/focus=4873

> * #true and #false

Yes!

> * datum labels for circular and shared substructures

Yes!

> * nan? and finite? now accept complex numbers
>   (should probably change inf? and infinite? as well)

Do you need to file a bug with the spec?  Have you?

> * R7RS exceptions

Are they like R6RS exceptions?

The semantics of the interaction of guard with dynamic wind is still
batshit crazy, and I hope guard doesn't make it into the spec as is.

> * define-library

A big one, and something to check in the newer specs..

> * vector->string and string->vector

Real wtf procedures, if you ask me...

> * write bytevectors with #u8 (and elements in hex) by default?

Is this incompatible wrt srfi-4?

> * {map,for-each} stops when shortest list runs out

WDYT about this?

> * string-{map,for-each} accepts multiple strings
> * vector-{map,for-each}

Bleh...

> * make sure {map,vector-map,string-map} are multi-return safe

This is an interesting one.  It would be nice to have expandable stacks
so we can do the straightforward implementation.  Dunno.

Just some off the cuff thoughts.  Happy hacking!

Andy
-- 
http://wingolog.org/

Re: TODO list for Guile R7RS support

[Alex Shinn]

On Thu, Feb 23, 2012 at 7:06 AM, Andy Wingo <wingo@pobox.com> wrote:
>
>> * datum labels for circular and shared substructures
>
> Yes!

Note this is one thing a reference implementation will
be provided for.

>> * nan? and finite? now accept complex numbers
>>   (should probably change inf? and infinite? as well)
>
> Do you need to file a bug with the spec?  Have you?

A complex number is nan? if either component is nan.
A complex number is finite? if both components are finite.

Implementations may not necessarily support complex
numbers with nan or inf components.

>> * R7RS exceptions
>
> Are they like R6RS exceptions?

Yes, just the exceptions with no condition hierarchy.

> The semantics of the interaction of guard with dynamic wind is still
> batshit crazy, and I hope guard doesn't make it into the spec as is.

Not disagreeing, but you'll need to clarify what about it
is crazy and ideally provide an alternative :)

>> * define-library
>
> A big one, and something to check in the newer specs..

It hasn't change much and shouldn't be too hard.

>> * vector->string and string->vector
>
> Real wtf procedures, if you ask me...

Agreed.

>> * write bytevectors with #u8 (and elements in hex) by default?
>
> Is this incompatible wrt srfi-4?

R7RS says nothing about the base.  So long as you write with
a prefix, e.g. #u8(#xFF ...) this is compatible with SRFI-4.

>> * make sure {map,vector-map,string-map} are multi-return safe
>
> This is an interesting one.  It would be nice to have expandable stacks
> so we can do the straightforward implementation.  Dunno.

The straightforward implementation doesn't need expandable
stacks.  Basically, all you need to do is avoid mutation - i.e.
cons up a list and reverse at the end.

We will also provide a reference implementation of this.

-- 
Alex

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi,

Alex Shinn <alexshinn@gmail.com> skribis:

> On Thu, Feb 23, 2012 at 7:06 AM, Andy Wingo <wingo@pobox.com> wrote:

[...]

>>> * R7RS exceptions
>>
>> Are they like R6RS exceptions?
>
> Yes, just the exceptions with no condition hierarchy.

Ouch, like SRFI-35--.  I’d be curious to see the rationale for yet
another record API, and one that doesn’t support inheritance.

Thanks,
Ludo’.

Re: TODO list for Guile R7RS support

[Alex Shinn]

2012/2/26 Ludovic Courtès <ludo@gnu.org>:
> Hi,
>
> Alex Shinn <alexshinn@gmail.com> skribis:
>
>> On Thu, Feb 23, 2012 at 7:06 AM, Andy Wingo <wingo@pobox.com> wrote:
>
> [...]
>
>>>> * R7RS exceptions
>>>
>>> Are they like R6RS exceptions?
>>
>> Yes, just the exceptions with no condition hierarchy.
>
> Ouch, like SRFI-35--.  I’d be curious to see the rationale for yet
> another record API, and one that doesn’t support inheritance.

No, not like SRFI-35, no condition types at all.
Instead you raise arbitrary objects (you can make
your own hierarchy if you want), and condition
types will be defined in the large language.

You seem to be confused about inheritance.
SRFI-35 and R6RS provided multiple inheritance,
while the record system supported only single
inheritance.  We will not repeat this mistake.

-- 
Alex

Re: TODO list for Guile R7RS support

[Ludovic Courtès]

Hi Alex,

Alex Shinn <alexshinn@gmail.com> skribis:

> 2012/2/26 Ludovic Courtès <ludo@gnu.org>:
>> Hi,
>>
>> Alex Shinn <alexshinn@gmail.com> skribis:
>>
>>> On Thu, Feb 23, 2012 at 7:06 AM, Andy Wingo <wingo@pobox.com> wrote:
>>
>> [...]
>>
>>>>> * R7RS exceptions
>>>>
>>>> Are they like R6RS exceptions?
>>>
>>> Yes, just the exceptions with no condition hierarchy.
>>
>> Ouch, like SRFI-35--.  I’d be curious to see the rationale for yet
>> another record API, and one that doesn’t support inheritance.
>
> No, not like SRFI-35, no condition types at all.
> Instead you raise arbitrary objects

OK, sort-of like SRFI-34 then, right?

> You seem to be confused about inheritance.
> SRFI-35 and R6RS provided multiple inheritance,
> while the record system supported only single
> inheritance.  We will not repeat this mistake.

Thanks for the clarification.  I see, and I concur.

Ludo’.