[Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (27 May 2011 02:12 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Alaric Snell-Pym (27 May 2011 14:09 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (28 May 2011 06:44 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (28 May 2011 18:25 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (29 May 2011 04:26 UTC)

Re: [Scheme-reports] General comments on the draft WG1 R7 report. Alaric Snell-Pym 27 May 2011 14:08 UTC

On 05/27/11 03:11, Jay Reynolds Freeman wrote:

> #### About the record system:  In that context, noting that the WG1
> R7 record system appears to have grown  out of SRFI 9, it looks to me
> as if a reasonable bare-bones requirements for built-ins would be (a)
> a record abstraction, together with (b) procedures "record?",
> "make-record", "record-ref" and "record-set!" ("record" -- analagous
> to "vector" or "string" -- might also be useful), all as defined in
> SRFI #9.  As SRFI #9 points out, "record" is a simple variant on
> "vector", so should be easy to install in most implementations.  With
> these primitives built in, any implementor could use just the rest of
> the the SRFI #9 code to get a required "record" module going, and
> anyone -- implementor or user -- could write a better (or at least
> different) version of the required "record" module, with some
> expectation that it would be portable among implementations.

The problem is, making "record-ref" et al visible to users means that
modules can no longer hide the internals of records by not exporting the
accessors. Whether language-enforced abstraction boundaries are good or
not is perhaps debatable, but I think it's important that we don't make
it impractical to use Scheme to build sandboxed execution environments;
where records might be created outside the sandbox, passed into it, and
only be accessible via a published interface. Unconstrained
introspective facilities are useful for debugging, so might be made
available in an optional module that's filtered out of sandboxes.

I proposed a record system that is below the level of user-visible
records (so could be used to build SRFI9 etc), but which didn't have
general record-ref etc systems, but people wanted to keep it simple and
go for SRFI-9 ;-)

[stuff about modules skipped as it's not an area I feel very qualified on]

> #### About exception handling: My worries here are a little vaguer,
> not least because I find the discussion of exception handling in the
> draft report sufficiently confusing that I am not sure what it all
> does.  (Mea culpa, I am sure I will figure it out somehow.)  Yet
> still I think there is too much stuff here; at least, too much built
> in.  Java seems to get along with just "try", "catch" and "throw".
> Do we really need more mandatory stuff in a language that is supposed
> to be simple?

At heart, the exception system is a very basic notion of a current
handler and how to invoke it; the "guard" stuff sits on top of that (and
I'm not so sure it should be in WG1...)

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports