Re: Should records be able to mimic primitive types?

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3372 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mo., 12. Juni 2017 um
19:41 Uhr:

> >> It's not trying hard, just a simple check for a known, small, and
> >> rarely-changing list of primitive symbols.
> > To me, that's working very hard:
> > - extra code.
> > - extra maintenance
> > - extra run-time checks.
> > - no benefit since this doesn't catch a common situation.
>
> More concretely: what would be a scenario where such a check would
> be useful?
>
> AFAICT, you need all 3 of:
> 1- First, you'd need someone to be foolish enough to set his record's
>    type to be one of the primitive types.  This is the actual bug that
>    your extra check would aim to catch.
>

Yes, though I wouldn't consider it foolish. make-record can be called
indirectly, maybe even from a function that somehow generates the type
name. People might try to create records named 'integer' and be happy that
that appears to work.


> 2- Then you'd need to pass that object to a chunk of code which uses
>    `type-of` and then checks the result for that primitive type.
>    Otherwise, the type you set would behave just like any other
>    non-primitive type so the "bug" would be harmless anyway.
> 3- Furthermore, you'd need this object to be manipulated exclusively in
>    a way which also works with your record object without signaling an
>    error (e.g. if the primitive type used is `integer`, it means your
>    object should never be passed to the likes of `+` since otherwise the
>    bug would already be discovered by `+` without any need for your extra
>    check).
>
> I haven't seen any evidence that step 1 will ever occur, even by accident.
>

I don't care about how often some bug will occur. Rather the contrary: it's
the rare bugs that are insidious. People learn about the common ones
quickly, but nobody will expect a rare bug, until it arises.


>
> No idea how likely is step 2.  `type-of` is very rarely used (except via
> cl-defmethod) so it's fairly unlikely, but possible.
>
> Step 3 seems again very unlikely in itself, and even more so if step
> 2 occurred: if you checked with type-of that your object is of type
> `integer` there's a very high likelihood that you're going to then use
> operations which only work on integers.
>
> Will all 3 steps ever occur at the same time?
>

I don't think this is an important question. The important point is:
Previously, there were invariants such as (integerp x) == (eq (type-of x)
'integer) or that prin1 would only generate #s(hash-table ...) for actual
hash tables. Now these invariants are broken. But it's critical that
invariants are never broken, no matter how unlikely the breakage is.
Imagine a system where 1 + 1 = 3 in one trillionth of the executions: even
if the bug were rare, that system would be unusable. Even worse, because it
is so rare, it is much more disastrous when it happens, because people
started relying on the invariant that is "almost" guaranteed. But there's a
discontinuity between "invariant is guaranteed" and "invariant is almost
always guaranteed": the latter is identical to "invariant is not guaranteed
at all".


>
> Do we really want to make every call to `make-record` pay the extra test
> in order to hope to catch this hypothetical case?


Yes, absolutely. I don't care whether it's rare or hypothetical, it breaks
an invariant, and invariants must not be broken.

[-- Attachment #2: Type: text/html, Size: 4403 bytes --]