Thanks for the response! Inline comments below:

On 11/17/24 07:50, Artyom Bologov wrote:
> Well, the sample implementation is trying to be as portable as possible,
> relying on most portable features. First goes the standard (R7RS), then
> SRFIs, then old standards (R6RS) and implementations. So the order more
> or less makes sense.
>
> As for many implementation-specific expectations, cond-expand can safely
> be dropped and replaced with raw Chicken-specific code. I'll certainly
> do this for (upcoming, I'm okay if someone beats me to it) Kawa and
> Guile implementations.
>

I'll go ahead and do this then. I was leaving it in there for the sake
of touching as little as possible but that will never execute on
CHICKEN's side.

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

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.

Well, either that or a conforming implementation can also just silently
do nothing with different compilation / evaluation modes, which seems
tough.

>> # Exports / Imports
>>
>> The correct list of exports for the sample implementation is:
>>
>> (export check-arg
>>          values-checked
>>          check-case
>>          lambda-checked
>>          define-checked
>>          case-lambda-checked
>>          define-record-type-checked)
>>
>> However, the sample implementation still tries to export
>> opt-lambda-checked and define-optionals-checked, and fails to export
>> check-case. You might want to fix this for other Scheme
>> implementations.
>
> Oh, right, I'll open a pull request in the original repo. In the
> meanwhile, feel free to proceed with 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.

>> Aside from that, good job! Many of the tests "just worked" and diving
>> in wasn't too bad for someone who is not a macro expert. I think most
>> of these issues come down to familiarity with CHICKEN and a sort of
>> chicken-egg problem where packaging the code as an egg helps diagnose
>> some of these issues when trying to use CHICKEN overall.
>
> Thanks a lot! I'm glad there wasn't many problems and I totally share
> your opinions on most changes you've made!
>
>> I don't know if I'll wait for any feedback on this message to merge
>> the above MR on GitLab and tell the chicken-users mailing list, but I
>> am definitely open to any help that can be provided here to make the
>> CHICKEN implementation better.
>
> I hope I'm not too late with my comments...

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

Thank you for the quick response here, I think I have a clear idea of
how to move forward now.

Cheers,
--
Jeremy Steward