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

12

1

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.

Daniel Fath

Posted 2014-08-26T18:21:26.817

Reputation: 223

Answers

11

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.

Hugo Dubé

Posted 2014-08-26T18:21:26.817

Reputation: 126

I don't understand what you're referring to by the passage of time. Rust's reference lifetimes correspond to an object's scope, and prevent the reference from outliving the live scope. The Rust compiler infers most of the lifetimes, but it is possible and sometimes necessary to annotate references with a lifetime. It's exactly what the patent's abstract is referring to, as it's nowhere near a new concept. Cyclone is a much earlier example of prior art. – strcat – 2014-08-26T23:15:59.253

1I added claim 1 and posted a comment with erroneous information. That is what strcat references above. I deleted the technically way off-base comment. – George White – 2014-08-27T00:28:22.963

Can you scope classes without the scope attribute in D? I haven't read the whole patent but it seems to me the claim can. @strcat can you post an example? I had quick look at Rust and to me it seems the programmer can be explicit about stack vs heap allocation. – Max – 2014-08-27T07:18:51.407

The patent isn't about ownership or scope-based destructors. It covers tracking the lifetimes of non-owning references to those resources / stack allocations with region typing. Just because something has the word scope in it or has to do with lifetimes doesn't mean it's the same thing as they're describing here. It doesn't have to do with being explicit about stack vs. heap allocation either. – strcat – 2014-08-27T15:41:27.430

9

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.

Brian

Posted 2014-08-26T18:21:26.817

Reputation: 91

The patent is different than just plain old destructors. It refers to tracking the lifetimes of references to those objects with destructors (or just objects on a stack frame) in order to prevent reference/iterator invalidation without a garbage collector. It's an attempt to patent the application of region typing used in Cyclone (2006) and later Rust (2010). Both of those languages arrived at a similar implementation independently, which demonstrates that it's a pretty obvious application of the underlying type theory. – strcat – 2014-08-27T06:21:18.650

1It is but a simple extension, a one step indirection, easily done via macros which are a form of language extension. All of it derives simply from the RAII concept and is conceptually no different from the relationship between fibonacci sequence N and N+1. A box in a box in a box is still a box. – Brian – 2014-08-27T06:48:43.790

@strcat: That's entirely not true. Plain old destructors implement tracking lifetimes of references to objects. See smart pointers in C++. Hell, the entire purpose of destructors is to track the lifetimes of references to things that need cleaning up. std::string is tracking the lifetime of references to a character array. Even SEH on Windows tracks the lifetime of references to exception handlers. – Puppy – 2014-08-27T11:33:39.720

@Puppy: It's not referring to smart pointers, which rely on scope-based destruction. It's referring to region typing on non-owning references to prevent reference invalidation, including references to objects on the stack without any destructor. The use of scope-based destructors is a side issue, not part of the claims in the patent. – strcat – 2014-08-27T15:39:43.967

@strcat except it is, this is basically a patent for a macro for using smart pointers. Something Microsoft already did in WinRT

– Mgetz – 2014-08-27T17:03:16.363

@Mgetz: No, it's not a patent for smart pointers. They are not talking about managing the lifetime of a resource via smart pointers, they are talking about performing static analysis (region typing) to verify the lifetime of references at compile-time without runtime instrumentation. Accusing them of trying to patent smart pointers is misdirection from the real issue, which is that they're trying to patent using region typing on lightweight references (again, not smart pointers). – strcat – 2014-08-27T20:31:08.977

C++ has to rely on destructors exactly because the compiler doesn't track the lifetime and you have to do it at runtime. And this can get very expensive, think about interlocked reference counting. So no, destructors are not real solution. Not even saying, that C++ allows to return dangling pointers just fine. – user42295 – 2014-08-28T07:47:03.070

1Er, the compiler definitely tracks the lifetime of all stack-allocated objects. Destructors tie the lifetime of heap-allocated objects to the lifetime of stack-allocated objects- which are often references, as in the case of smart pointers, containers, whatever- so effectively, the compiler tracks the lifetime of heap-allocated objects. – Puppy – 2014-08-28T13:38:39.507

This patent is about tracking / verifying the lifetimes of lightweight references to objects. It doesn't have anything to do with objects tied to scopes, but rather figuring out the intersection of reference lifetimes and preventing them from outliving any object they may point at. There is prior art for that in Cyclone / Rust, but not C++ / D. For example, a function may take several iterator and return one of them - the patent covers having a way to annotate that the lifetime of the returned iterator is bounded by the intersection of the input lifetimes. All without any reference counting. – strcat – 2014-08-29T02:29:14.467

4

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.

Mgetz

Posted 2014-08-26T18:21:26.817

Reputation: 141

3

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.

strcat

Posted 2014-08-26T18:21:26.817

Reputation: 131

2

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)

riffraff

Posted 2014-08-26T18:21:26.817

Reputation: 121

Rust doesn't actually use typestate anymore but rather relies on affine types (destructors / move semantics) and region typing for static verification of reference lifetimes. The usage of region typing in Rust is exactly like this patent - including the ability to annotate named lifetimes when it can't be inferred or just for clarity. – strcat – 2014-08-29T02:32:33.057

thanks, that is what I meant with "original inspiration", but I guess it was poorly worded. – riffraff – 2014-08-29T14:59:20.387