Type declarations and data validation utils?

Type declarations and data validation utils?

[Artyom Bologov]

Hi y'all,

I've compiled a generic collection of data-checking macros (which I'm
consider contributing as SRFI), but I'm not satisfied with their
performance. Dave Thompson's blog post shows benefits from adding type
predicates before the code, but it seems that my approach of adding
assert-s to the start of the function is less effective and adds a lot
of performance overhead.

Thus the question: is there any way to declare types that Guile will
accept and act on? Especially if this way it exported for user to play
with. I haven't found any pointers in the manual, thus I'm asking it
here (I'm also asking it on the devel list because devs are more likely
to know the ins and outs of typing and maybe even able to act on it.)

Thanks,
--
Artyom Bologov
https://aartaka.me

Re: Type declarations and data validation utils?

[Artyom Bologov]

Hi y'all,

I'm terribly sorry, my email was down for a bit. In case anyone wanted
to reply, you're welcome to! I'm still eager to know how Guile code can
be type-annotated and checked.

Thanks,
--
Artyom Bologov

RE: Type declarations and data validation utils?

[Maxime Devos]

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

>I've compiled a generic collection of data-checking macros (which I'm
consider contributing as SRFI), but I'm not satisfied with their
performance. Dave Thompson's blog post shows benefits from adding type
predicates before the code, but it seems that my approach of adding
assert-s to the start of the function is less effective and adds a lot
of performance overhead.

Is it this one: https://dthompson.us/posts/optimizing-guile-scheme.html?
An example demonstrating the overhead could be useful to determine how to improve things.

>Thus the question: is there any way to declare types that Guile will
accept and act on? Especially if this way it exported for user to play
with. I haven't found any pointers in the manual, thus I'm asking it
here (I'm also asking it on the devel list because devs are more likely
to know the ins and outs of typing and maybe even able to act on it.)

The way to ‘declare’ it is to add those asserts or equivalent. The reason that there is no more about it in the manual is that currently there is not more to it than that.

I do think some support in Guile for type declaration could be useful, however.

For example:
(define (foo x y z)
  [type declarations]
  [do stuff with x y z])

could perhaps be translated into:

(define (foo-error1 x y z) [...]) ; ← raises some type error
(define (foo-error2 x y z) [...]) ; ← raises some type error
(define (foo-actual x y z)
  [do stuff with x y z, and let compiler / optimiser assume the types are correct])
(define (foo x y z) ; this one the compiler should attempt to inline
  (cond
    ([typecheck1 fails on x y z] (foo-error1 x y z))
    ([typecheck2 fails on x y z] (foo-error2 x y z))
    (#true (foo-actual x y z))))

That way, external code using ‘foo’ can perhaps have the typechecks eliminated at compile time (without having to inline ‘foo-actual’). Or if not all typechecks could be eliminated but most typechecks are repeated (for example because ‘foo’ is called in a loop with shared values of x and y), then some typechecks could be moved to the front and the code ‘foo-error1’ and ‘foo-error2’ for constructing the condition object (and raising it) doesn’t need to be duplicated ...

Best regards,
Maxime Devos

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

Re: Type declarations and data validation utils?

[Artyom Bologov]

Hi Maxime,

> Is it this one: https://dthompson.us/posts/optimizing-guile-scheme.html?

Yes, that's the one!

> An example demonstrating the overhead could be useful to determine how to improve things.

I'm not yet that familiar with Guile disassembler to infer any useful
insights, that's why I'm not sure which techniques work and which
don't. It's part of why I'm asking it here.

> The way to ‘declare’ it is to add those asserts or equivalent. The reason that there is no more about it in the manual is that currently
> there is not more to it than that.

That's the route I'm taking for now.

Thanks for the rest of the message, there is indeed a lot of type
checking opportunities, and I want my potential SRFI to actually fit
these, so I'll ping y'all here when I have something polished enough.

Still, if someone knows more strict ways to enforce types/validation,
speak up—I want to use what's there in Guile to optimize things as much
as possible!

Thanks,
--
Artyom