Re: Should records be able to mimic primitive types?

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Will all 3 steps ever occur at the same time?
> I don't think this is an important question.

But in the absence of the combination of those 3 steps, your check will
make no difference.  Are you saying that you don't think "whether my
check makes a difference" 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.

Every patch we install changes an "invariant" (except for cosmetic
patches, changes to the build system, ...).

So we can't take such an absolute position, if we want to keep
developing Emacs (including fixing bugs): we necessarily have to judge
which invariants are worthy of being preserved and which ones aren't.
E.g. if we ever get good support for bignums, we'll likely have to break
your first invariant.

Also we have to distinguish between breaking an invariant and not
enforcing it.  I do consider an Elisp code which creates a record of
type `integer` as a bug, but I don't think it's worth this particular
effort to enforce it.

Even with your extra check the above two invariants won't always hold.
I can trivially break the first one with some add-advice on type-of.
Should we add another check to prevent breaking the "invariant" in that
other way?  The second can be broken without even using an advice on
`prin1` simply by creating a record of type (make-symbol "hash-table").
Should we also add yet another check to try and avoid this other way to
break your "invariant"?

> 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".

In Elisp, the general rule is that thanks to the dynamic nature of the
language, there are precious few invariants which really always hold.
E.g. as soon as your "invariant" calls a function by name, you're
exposed to breakage via the advice mechanism.

So, in a sense, Elisp is a landmine just like C.

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

You might like to try Agda or Coq, but Elisp will inevitably disappoint
you in this area.

In case you're interested, my own hobby language, Typer, tries to
combine Coq with Lisp.


        Stefan