comp.lang.ada
 help / color / mirror / Atom feed
From: Phil Thornley <phil.jpthornley@gmail.com>
Subject: Re: SPARK - an idea for high integrity data structures
Date: Wed, 21 Jul 2010 05:40:17 -0700 (PDT)
Date: 2010-07-21T05:40:17-07:00	[thread overview]
Message-ID: <a816345d-ac85-45e2-b919-c926c13b6c21@q12g2000yqj.googlegroups.com> (raw)
In-Reply-To: m2lj96t10m.fsf@pushface.org

On 20 July, 20:18, Simon Wright <si...@pushface.org> wrote:
> "Peter C. Chapin" <pcc482...@gmail.com> writes:
>
> > I know Praxis is working on generics support in SPARK. Once that was
> > ready it probably wouldn't be too hard for the original author of a
> > high integrity collections library to generalize the code as
> > appropriate. At least that would be my hope.
>
> An alternative might be to use an external macro processor to generate
> appropriate code complete with annotations. I guess that would depend on
> whether the proofs (a) didn't depend on the contained type, (b) didn't
> need (much) human intervention.

There are occasional hints about generics, and I guess that the
pressure for these is increasing. OTOH I know that some work on this
had already been done five years ago, so I'm not holding my breath.

There are a couple of options for a usable version of these data
structures before we get generics - it would be quite easy to add an
arbitrary data component, so that the proofs never depended on the
actual definition of that component and they would rerun with whatever
any user required as the type for that data.

Another option, which avoids changing anything in the data structure
code, is to make the client code responsible for storing the actual
data, and just to supply a key for storage/retrieval in the data
structure.  The operations then have output parameters that tell the
client code the index for the data in the array that the client
maintains.

I have both of these possibilities in mind if these exercises are
successfull - but am aware that they both place a constraint on the
data structure code: that no element in the data structure is ever
copied from one position to another.  For the first option this could
be grossly inefficient, if the data is large, and it would be invalid
for the second option.  (This means e.g. that I can't use the easy way
of deleting an internal node of a binary tree, it has to be done by
changing multiple tree links.)

Cheers,

Phil



  reply	other threads:[~2010-07-21 12:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20 12:40 SPARK - an idea for high integrity data structures Phil Thornley
2010-07-20 14:33 ` Matteo Bordin
2010-07-20 19:02   ` Phil Thornley
2010-07-20 19:07 ` Peter C. Chapin
2010-07-20 19:18   ` Simon Wright
2010-07-21 12:40     ` Phil Thornley [this message]
2010-07-21 13:23       ` Peter C. Chapin
2010-07-22 10:14         ` Matteo Bordin
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox