guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The progress of hacking guile and prolog


From: Noah Lavine
Subject: Re: The progress of hacking guile and prolog
Date: Tue, 23 Nov 2010 20:54:37 -0500

Hello,

That might make sense. The documentation certainly looks interesting.

What I'm thinking of is like racket contracts, but with the idea of
"trusted modules", which might involve static checking. For instance,
if the contract is that map's second parameter is a list, you'd
normally want to check that. But if a module that used map could
guarantee that it would always pass a list as the second argument,
then you'd arrange things so the second module could skip the type
check.

I'm curious in general though whether it would be possible and
worthwhile to statically check programmer-defined ideas, as long as
the interface is easy enough to use. For instance, what if you could
ask Guile to check that your tree structure always remained a binary
tree? Or better, what if you wrote a GUI program and checked that the
callbacks you passed to the GUI library would always return? (I know
it's not possible in general, but I think it will work for a subset of
procedures that will include some interesting ones.)

Noah

On Sat, Nov 20, 2010 at 6:25 AM, Andy Wingo <address@hidden> wrote:
> Hi Noah,
>
> On Thu 04 Nov 2010 03:40, Noah Lavine <address@hidden> writes:
>
>> I think that Guile should offer optional static checking - not just of
>> types, but of everything that we can check.
>
> It seems like you're really asking for *dynamic* checking -- not only
> checking properties that can be proved statically, without running the
> program, but also runtime properties.
>
> In this regard, I have a positive impression of the work that people are
> doing on "contracts", especially the Racket folks.
>
>    http://docs.racket-lang.org/reference/contracts.html
>
> Happy reading,
>
> Andy
> --
> http://wingolog.org/
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]