[Haskell-cafe] Patents on Maybe and Tuple

[Christopher Allen]

IANAL, but from what I have seen said about this by IP lawyers:

The USPTO doesn’t seem consider it their job to adjudicate things like this. They let most stuff through for the courts to sort out.


> On Jan 31, 2019, at 3:28 PM, Jack Kelly <jack at jackkelly.name> wrote:
> 
> It's great that we know this, but does anyone who knows the patent
> system know that we know this?
> 
> -- Jack
> 
> On Fri, Feb 1, 2019 at 12:30 AM Richard O'Keefe <raoknz at gmail.com> wrote:
>> 
>> Haskell's "Maybe t" is essentially the same as ML's "'t option".
>> ECMA Eiffel has a distinction between "T" and "T?" types which
>> is related.  The idea of a compiler system with multiple front-
>> ends for dissimilar languages goes back to Burroughs (where
>> type checking applied cross-language) and to Univac (where several
>> languages used the same back end) and with multiple source languages sharing a common IR with multiple target-specific
>> back ends goes back at least to the Amsterdam Compiler Kit. Back
>> in 1984 the idea of retaining code in an intermediate form until
>> it was about to be executed with so far from novel that I used it
>> in a design.  JIT compiling goes back at least to Brown's "throw-
>> away compiling" for BASIC (compact IR, bulky native code compiled
>> into a smallish buffer at need and periodically thrown away) and
>> commercial Smalltalk systems.  (And there is at least one Smalltalk
>> out there with Lisp and Prolog syntax on offer as well.)  Then there
>> is the Poplog system, which incrementally compiled ML, Common Lisp
>> (CLtL1 vintage), Pop-11, and Prolog, all quite different looking
>> (and Pop-11 being arguably OO), into a common IR, with native code generation for multiple target processors.
>> 
>> There may well be innovative things in Swift, but nothing in this
>> thread would have seemed novel 30 years ago.
>> 
>> On Thu, 31 Jan 2019 at 16:54, Saurabh Nanda <saurabhnanda at gmail.com> wrote:
>>> 
>>> 
>>>> 
>>>> Are the patents each not effectively processor-specific?
>>> 
>>> 
>>> Alfred, if you're saying this because of the following clause in the independent claim...
>>> 
>>>> compiling the first and second intermediate representations using a back-end compiler that is specific to a target processor.
>>> 
>>> ...then I'm not so sure, because isn't every backend compiler specific to an architecture/processor?
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.