Re: Minor conditions cleanup

--===============0525555201==
Content-Type: multipart/alternative; boundary=e89a8f839d71b368a804f9ae3d44

--e89a8f839d71b368a804f9ae3d44
Content-Type: text/plain; charset=UTF-8

Hey Carl,

Sorry for the long delay in responding to this.

I think that it would be a good chance to have a common base class (be it
<key-error> or <collection-error> or whatever).

However, I do like having the more specific and descriptive errors, so I'd
rather not see those go away.

Cheers,

 - Bruce


On Mon, May 12, 2014 at 2:53 AM, Carl Gay <[email protected]> wrote:

> I'd like to make a minor cleanup to the condition classes signaled for
> collections code.  Please let me know if you object to these changes or if
> you would suggest specific changes.  If there are no objections in
> principle I can send a patch for review to the list.
>
> Summary:
>
>    - All collection access that involves a bad key of any kind will
>    signal a subclass of <key-error> instead of the current disjoint set of
>    conditions: <not-found-error>, <invalid-index-error>,
>    <subscript-out-of-bounds-error>, and <empty-collection-error>.  This
>    includes
>    - invalid index for sequence
>       - invalid number of array subscripts (rank errors)
>       - reduce1, pop, first, second, last, etc on an empty (or too small)
>       collection
>       - element(<set>, value) if value not present
>
> This would *not* cover, for example, element(<string-table>, <integer>)
> and other type errors, as it looks to me like that would involve inserting
> run-time checks that would slow down access.  (I only took a very brief
> look at this.  I suspect these cases currently signal <type-error>.)
>
> The main point is to have one shared condition class for invalid
> collection accesses.  I personally don't see a lot of advantage in keeping
> the existing condition classes around as subclasses of <key-error> (except
> perhaps <subscript-error>, see diff), but I'd like to hear what others
> think.
>

--e89a8f839d71b368a804f9ae3d44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Hey =
Carl,</div><div class=3D"gmail_quote"><br>Sorry for the long delay in respo=
nding to this.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">
I think that it would be a good chance to have a common base class (be it &=
lt;key-error&gt; or &lt;collection-error&gt; or whatever).</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">However, I do like ha=
ving the more specific and descriptive errors, so I&#39;d rather not see th=
ose go away.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</di=
v><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=C2=A0- B=
ruce</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><=
br></div><div class=3D"gmail_quote">
On Mon, May 12, 2014 at 2:53 AM, Carl Gay <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I&#39;d like to make a minor cleanup to the condition=
 classes signaled for collections code. =C2=A0Please let me know if you obj=
ect to these changes or if you would suggest specific changes. =C2=A0If the=
re are no objections in principle I can send a patch for review to the list=
.</div>

<div><br></div><div>Summary:</div><div><ul><li>All collection access that i=
nvolves a bad key of any kind will signal a subclass of &lt;key-error&gt; i=
nstead of the current disjoint set of conditions: &lt;not-found-error&gt;, =
&lt;invalid-index-error&gt;, &lt;subscript-out-of-bounds-error&gt;, and &lt=
;empty-collection-error&gt;. =C2=A0This includes<br>

</li><ul><li>invalid index for sequence</li><li>invalid number of array sub=
scripts (rank errors)</li><li>reduce1, pop, first, second, last, etc on an =
empty (or too small) collection</li><li>element(&lt;set&gt;, value) if valu=
e not present</li>

</ul></ul>This would <b>not</b> cover, for example, element(&lt;string-tabl=
e&gt;, &lt;integer&gt;) and other type errors, as it looks to me like that =
would involve inserting run-time checks that would slow down access. =C2=A0=
(I only took a very brief look at this. =C2=A0I suspect these cases current=
ly signal &lt;type-error&gt;.)<br>

</div><div><br></div><div>The main point is to have one shared condition cl=
ass for invalid collection accesses. =C2=A0I personally don&#39;t see a lot=
 of advantage in keeping the existing condition classes around as subclasse=
s of &lt;key-error&gt; (except perhaps &lt;subscript-error&gt;, see diff), =
but I&#39;d like to hear what others think.</div>
</div></blockquote></div></div></div>

--e89a8f839d71b368a804f9ae3d44--

--===============0525555201==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers

--===============0525555201==--