Re: [Caml-list] Scoped Bound Resource Management just for C++?

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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

For an example of a language with linear types for resource management, as
mentioned by Andreas Rossberg, see ATS : http://www.ats-lang.org/

Of particular interest to the present discussion are the following pages:
- Stack allocation :
http://www.ats-lang.org/TUTORIAL/contents/stack-allocation.html
  memory and closures are allocated on the stack, with the type system
guaranteeing that such values cannot be referenced after the current
function exit
- Cairo basics :
http://www.ats-lang.org/DOCUMENTATION/ATSCAIRO/HTML/c28.html
  a small tutorial for programming with the Cairo library; linear types are
used to track the cairo resources, which internally -- on the C side -- use
reference counting
- "Implementing Reliable Linux Device Drivers in ATS" :
http://www.ats-lang.org/PAPER/LDD-plpv07.pdf

On Wed, Feb 9, 2011 at 9:47 PM, Norman Hardy <norm@cap-lore.com> wrote:

>
> On 2011 Feb 8, at 15:57 , orbitz@ezabel.com wrote:
>
> > One of the benefits, in my opinion, of C++ is SBRM.  You can reason about
> the lifetime of an object and have an give yourself guarantees about its
> clean up.  The method of initialization and clean up are also consistent for
> every object in the language.
> >
> > My questions are:
> > 1) Do other people in the FP world consider this to be a good strategy?
> > 2) Can this be done in a sane way in a GCd language?
> > 3) What are the alternatives in a language like Ocaml?
>
> Keykos was a platform intended for program agents from diverse and even
> hostile interests.
> http://cap-lore.com/CapTheory/KK/
> It had an adversarial space allocation technology.
> http://cap-lore.com/CapTheory/KK/Space.html
> It was an operating system with a space allocation facility that was both
> safer and less safe than GC.
> It was safer in that it was feasible to write applications therein safe
> from space exhaustion.
> It was less safe in that programming errors might delete space too soon.
> It did not suffer, however, from ‘memory safety’ errors when ‘stale
> pointers’ were used.
> The behavior of stale pointers was determined and ‘threw exceptions’ by
> default.
> Lurking forgotten references that were indeed destined not to be used were
> not a problem as in GC.
>
> Releasing storage was explicit and indeed an extra additional application
> burden.
> It was also possible for the agent paying for the storage to reclaim the
> storage despite access by others.
>
> The allocation mechanisms were responsible for space on timescales from
> milliseconds to years.
>
> Many complex agreements on data access between parties, positive and
> negative, were possible in Keykos, and enforced by mutually trusted software
> agents therein.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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