Looking for prior art for patent application US20140196015 "Declaration of Lifetime resource reference"

Question

I'm looking for prior art related to following patent:

http://www.freepatentsonline.com/y2014/0196015.html

DECLARATION OF LIFETIME OF RESOURCE REFERENCE
A language extension that advances safety in system programming by specifying a lifetime of a reference that represents a resource. In accordance with the language extension, the lifetime references a particular scope in a manner that the compiler generates computer-executable instructions that enforce the lifetime of the reference to be a function of (e.g., no longer than) the lifetime of the particular scope. Accordingly, the resource lifetime may be specified in advance to have a particular scope. This helps in performing resource management as typical managed language programs can allow resources to exist indefinitely. Furthermore, because the resources have a defined finite lifetime, they might be more conveniently allocated on a stack, instead of on a heap, for much more efficient processing.

EDIT

CLAIM 1

1. A computer-implemented method for declaring that a particular reference in a software program has a finite lifetime, the method comprising:

   an act of accessing a software program under construction that includes a reference that defines a resource; and

   an act of annotating a reference of the software program to be associated with a particular scope having a finite lifetime, wherein the annotation is structured such that the compiler enforces a lifetime of the reference to be a function of the lifetime of the particular scope.

Answer 1

The D programming language has scope classes, shown here in the "Scope Classes" section. (quoted for convenience)

Scope Classes

A scope class is a class with the scope attribute, as in:

scope class Foo { ... }

The scope characteristic is inherited, so if any classes derived from a scope class are also scope.

An scope class reference can only appear as a function local variable. It must be declared as being scope:

scope class Foo { ... }

void func() {
  Foo f;    // error, reference to scope class must be scope
  scope Foo g = new Foo(); // correct
}

When an scope class reference goes out of scope, the destructor (if any) for it is automatically called. This holds true even if the scope was exited via a thrown exception.

Oldest history I can find quickly for this is in the earliest commit of the Dlang.org website on Github, dated 9 March 2008

---

Additionally, the Rust programming language has explicit lifetimes for pointer variables.

Answer 2

Prior art:

GNU's GCC cleanup extension for C, http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#GCC_.22cleanup.22_extension_for_C

Google's Go language, defer statement.

Any C++ code using RAII that is then compiled through CFront.

Any C or C++ code using a macro to limit lifetime of anything.

Any code generator in any language that generates RAII.

The time claim is spurious and satisfied by practically all RAII implementations.

There is no innovation here. The concept itself is contained within http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#CITEREFStroustrup1994.

The claims of this patent are liken to the claiming of a patent on a wooden wheel spoke in the case it is produced by a lathe rather than hand carved.

Answer 3

Prior art:

Microsoft's Stack Semantics for Reference types, first reference in VS2005 http://msdn.microsoft.com/en-us/library/ms177191(v=vs.80).aspx

When you create an instance of a reference type using stack semantics, the compiler does internally create the instance on the garbage collected heap (using gcnew).
When the signature or return type of a function includes an instance of a by-value reference type, the function will be marked in the metadata as requiring special handling (with modreq). This special handling is currently only provided by Visual C++ clients; other languages do not currently support consuming functions or data that use reference types created with stack semantics.

Answer 4

Rust uses a lifetime system based on region typing to statically verify the lifetimes of references. It prevents reference / iterator invalidation at compile-time without any overhead - no reference counting required. Most of this is dealt with by the compiler's lifetime inference, but non-trivial function signatures need to be marked with named lifetimes - as mentioned in this patent.

http://doc.rust-lang.org/guide-lifetimes.html

A lot of the answers mention destructors / smart pointers, but I think that's off the mark. Rust does have types with destructors / move semantics (affine types) too, but it's a different language feature than lifetimes. Destructors manage the lifetime of a specific owned object by tying it to a scope and don't need any of this fancy lifetime analysis.

For example, Rust's Rc<T> type has a destructor and thus has move semantics, so ownership is tied to a variable but can be transferred elsewhere. A reference count is done by calling clone to create a new owner, and there is a concept of a non-owning Weak<T> reference. None of that falls under this patent - what does is the ability to take a lightweight reference into the Rc<T> and then pass that to functions only aware of &T and not Rc - without any memory unsafety, even in cases where references deeper inside are returned.

Answer 5

I might be wrong, but I think there is prior art from Microsoft Research itself in the form of the Vault programming language

http://research.microsoft.com/en-us/downloads/ee56884c-b946-4c35-b12d-d84bd4269235/

According to the only document I can find now

In short, the benefit of giving an object a tracked type is that the Vault type checker can trace the availability and state of that object throughout the program’s text.

(the paper also cites the "Typestate" paper which was also the original inspiration for Rust, IIRC)