Final SRFI 253: Data (Type-)Checking Arthur A. Gleckler (15 Nov 2024 23:12 UTC)
Re: Final SRFI 253: Data (Type-)Checking Jeremy Steward (16 Nov 2024 23:21 UTC)
Re: Final SRFI 253: Data (Type-)Checking Artyom Bologov (17 Nov 2024 14:51 UTC)
Re: Final SRFI 253: Data (Type-)Checking Jeremy Steward (17 Nov 2024 17:04 UTC)
Re: Final SRFI 253: Data (Type-)Checking Artyom Bologov (17 Nov 2024 19:20 UTC)

Re: Final SRFI 253: Data (Type-)Checking Artyom Bologov 17 Nov 2024 19:19 UTC

Jeremy,

>> I'm okay with using a generic implementation, but I put a lot of
>> thought
>> into the `the` use, so I'll be grateful if you include it.
>>
>
> I can understand this! I just don't know how to reconcile that
> implementation so that it informs the compiler and still passes the
> provided test-suite. In particular:
>
>   (the TYPE EXPRESSION)
>
> is equivalent to EXPRESSION. The only difference is that you're
> stating (to the compiler) that it is of the given type. If you're
> running values-checked in the interpreter or without specializations,
> this may not even get checked at all! The only direct analogue I have
> for this is casting in C:
>
>    char *c = "abcdef";
>    uint8_t bytes = (uint8_t*)c;
>
> This more or less is just telling CHICKEN "I know what I'm doing and
> this is a value of TYPE."

Yes, and that's the intended logic: allow the compiler to do the
checking/optimization magic, while not stating in its/interpreter's way
when not prompted to.

> You might be able to replace instances of (the TYPE EXPRESSION) with:
>
>     (let ((v value))
>       (check-arg pred? v 'values-checked)
>       (the <type> v))
>
> This would produce the correct checking at runtime in the interpreter
> (and since check-arg uses `assert` that would be compiled out if -O4
> or -unsafe are passed), with the (the TYPE EXPRESSION) preserved for
> future type inference by the compiler down the line.

That's another way. Is that possible to specify this more correct logic
for interpreter, while leaving `the` for the compiler? Just an idea,
don't take it too seriously.

Anyway, I don't see any problem with using plain `the` in all
scenarios—it's still compliant and is the lowest overhead solution.

>> Oh, right, I'll open a pull request in the original repo. In the
>> meanwhile, feel free to proceed with the right exports!

Opened and merged in
https://github.com/scheme-requests-for-implementation/srfi-253/pull/41
Pull from the upstream to get the right exports.

> Thanks! I figured someone was probably testing this with just the .scm
> file rather than by packaging the full thing. I noticed that
> opt-lambda-checked was removed in an earlier round of feedback which
> tipped me off.

Yes, library definition file is quite broken, so I was mostly just using
the implementation file directly. Thus the outdated code in library
definition.

> It's never too late, but I do want to announce this to chicken-users
> soon and use it in my own projects.

Sure, I trust your judgment of a Chicken-aware person, so proceed as you
deem right.

Best of love,
--
Artyom Bologov
https://aartaka.me