Patents on Maybe and Tuple

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Patents on Maybe and Tuple

Henk-Jan van Tuyl

L.S.,

I just read the article "Apple Patents Swift".[0] It says that Apple has
two patents regarding Swift: [1][2]; these patents state, amongst others,
that there are new types of variables:

"Additionally, an embodiment of the new language introduces advanced types
not found in Objective-C. These types include Tuples and Optionals. Tuples
enable a developer to create and pass groupings of values. Tuples group
multiple values into a single compound value."

and

"In one embodiment, an optional type is provided that handles the absence
of a value. Optionals are a way to say either “there is a value, and it
equals x” or “there isn't a value at all.”"

I hope we don't get arrested for using the Maybe monad or tuples in
Haskell.

Regards,
Henk-Jan van Tuyl


[0]
https://www.i-programmer.info/news/98-languages/12495-apple-patents-swift.html
[1] https://patents.google.com/patent/US9952841B2
[2] https://patents.google.com/patent/US9329844B2


--
Message from Stanford University:

Folding@home

What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://foldingathome.stanford.edu/

--
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Saurabh Nanda
Broadly speaking, when reading a patent it is the independent claims that matter most. If your work is not infringing the independent claims, then everything else can be ignored -- especially the description & background sections of the patent, which are primarily used to make sense of the completely abstract terms in which the invention is described by the claims.

The independent claims in these two patents are given below along with my understanding of what kind of inventions they're trying to cover (IANAL, but I was an Intellectual Property analyst in a previous job).

Patent US9329844B2

1. A non-transitory computer-readable medium with instructions stored therein, the instructions, when executed by a processor, cause the processor to perform operations comprising: 

Hurray! You just described a computer! Btw, I never read the "non-transitory" part when in patents earlier. Some interesting background - https://www.smithhopen.com/glossary_term/149/Non-transitory-Media
 
  • receiving a first request to compile a first set of program instructions coded in a first high-level language, the first high-level language a C language based object-oriented programming language;
Some invention containing a C, or C-like compiler....
 
  • receiving a second request to compile a second set of program instructions related to the first set of program instructions, the second set of program instructions coded in a second high-level language including object-oriented elements and procedural elements, wherein second high-level language is not compatible with the C language;
...gets interesting here. A second compiler for a non C-like language. The two compilers are being used to compile two different, but related programs... 
  • compiling the first set of program instructions and the second set of program instructions using a modular compilation system including multiple front-end compilers, the first set of program instructions compiled into a first intermediate representation of the first set of program instructions and the second set of program instructions compiled into a second intermediate representation of the second set of program instructions;
this seems to be describing typical GCC or LLVM architecture, right? (I'm not a compiler engineer!) 
  • linking the first and second intermediate representations; and
... nothing special here...
 
  • compiling the first and second intermediate representations using a back-end compiler that is specific to a target processor.

Again, standard cross compilation? 

This independent claim seems too broad to be true. There is nothing novel, apart from the presence of 2 compilers, that seems to be going on between the two programs being compiled or the two compilers. Let's narrow the scope using some dependent claims....

4. The medium of claim 1, further comprising instructions to perform additional operations including optimizing the first and second intermediate representations during a compile-time optimization.
5. The medium of claim 1, further comprising instructions to perform additional operations including optimizing the first and second intermediate representations during a link-time optimization.
7. The medium of claim 1, wherein compiling the second set of program instructions includes performing compile-time data-type overflow checking by default.
8. The medium of claim 1, wherein compiling the second set of program instructions includes performing compile-time data structure bounds checking by default.
9. The medium of claim 1, wherein compiling the second set of program instructions includes performing one or more compile-time type safety operations in conjunction with one or more type inference operations.

Aha! Something gets interesting here. There is optimisation happening between two programs written in two unrelated languages, by converting them into an IL and using both the ILs to perform optimisation. Does anyone know where Apple is using such compiler technology? After reading the description & background section of the patents my guess is that they have patented all the concepts of Swift in conjunction with existing C/Obj-C code.

Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.


10. A system comprising:
  • [...] removed clauses similar to first independent claim [...]
  • wherein the second set of program instructions are not compatible with the C language and includes a data type provided by the second high-level language to indicate absence of a value of any type.
Take a look at the last clause. This is where the concept of `Maybe` is making its way into an independent claim. However, all of this is in conjunction with with a system comprising two compilers of unrelated languages.
 
15. A computer-implemented method comprising:
  • [...] removed clauses similar to first independent claim [...]
  • linking the first and second intermediate representations, wherein linking the first and second intermediate representations includes optimizing the first and second intermediate representations in response to a compile-time request to optimize the program instructions; and
  • compiling the first and second intermediate representations using a back-end compiler that is specific to the target processor.
Not sure what's new about this claim over and above the first claim, but I'm tired now... Moving on to the next patent...
 
Patent US9952841B2

1. A non-transitory computer-readable medium with instructions stored therein, the instructions, when executed by a processor, cause the processor to perform operations comprising:

Again -- you're describing a computer, Sherlock! 
  • receiving a first request to compile a first set of program instructions coded in a first high-level language, the first high-level language a C language based object-oriented programming language; 
  • receiving a second request to compile a second set of program instructions related to the first set of program instructions, the second set of program instructions coded in a second high-level language including object-oriented elements and procedural elements, wherein the second set of program instructions includes a data type provided by the second high-level language to indicate absence of a value of any type;
  • compiling the first set of program instructions and the second set of program instructions using a modular compilation system including multiple front-end compilers, the first set of program instructions compiled into a first intermediate representation of the first set of program instructions and the second set of program instructions compiled into a second intermediate representation of the second set of program instructions;
  • linking the first and second intermediate representations; and
  • compiling the first and second intermediate representations using a back-end compiler that is specific to a target processor.
Again, talking about a similar 2-compiler system as the first patent. Let's look at some dependent claims....

17. The method as in claim 16, wherein the second set of program instructions are related to the first set of program instructions, the second set of program instructions are coded in a second high-level language that includes object-oriented and procedural elements, the second set of program instructions are not compatible with the C language, and the second set of program instructions includes an interpolated string.
18. The method as in claim 16, wherein the back-end compiler is a just-in-time compiler.
19. The method as in claim 16, wherein compiling the second set of program instructions includes performing compile-time data-type overflow checking and compile-time data structure bounds checking by default.

They seem to be patenting numerous advanced compile-time checks in a 2-compiler system. 

(there are two more independent claims in this patent, but I'm really tired now!)

-- Saurabh.

On Thu, Jan 31, 2019 at 7:27 AM Henk-Jan van Tuyl <[hidden email]> wrote:

L.S.,

I just read the article "Apple Patents Swift".[0] It says that Apple has
two patents regarding Swift: [1][2]; these patents state, amongst others,
that there are new types of variables:

"Additionally, an embodiment of the new language introduces advanced types
not found in Objective-C. These types include Tuples and Optionals. Tuples
enable a developer to create and pass groupings of values. Tuples group
multiple values into a single compound value."

and

"In one embodiment, an optional type is provided that handles the absence
of a value. Optionals are a way to say either “there is a value, and it
equals x” or “there isn't a value at all.”"

I hope we don't get arrested for using the Maybe monad or tuples in
Haskell.

Regards,
Henk-Jan van Tuyl


[0]
https://www.i-programmer.info/news/98-languages/12495-apple-patents-swift.html
[1] https://patents.google.com/patent/US9952841B2
[2] https://patents.google.com/patent/US9329844B2


--
Message from Stanford University:

Folding@home

What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://foldingathome.stanford.edu/

--
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Saurabh Nanda
Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.

Actually, the teams working on languages like Eta, Kotlin, and Scala should be really worried about these series of patents and should get infringement analysis done by an experienced IP lawyer, and/or press for invalidation of these patents.

-- Saurabh.


_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Flavio Villanustre
I'm no patent attorney either, but there is a temporal component when it comes to invalidating patents due to prior art, and Haskell is demonstrably "very prior" to these claims, even though it's not mentioned there. 

Only something that appeared after the patent was filed initially would potentially constitute infringement, as long as the claims made in the patent weren't made public by the inventors themselves prior to the filing, of course.

I guess, Haskell is safe and we live to see another day... :)

Flavio

On Wed, Jan 30, 2019, 21:51 Saurabh Nanda <[hidden email] wrote:
Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.

Actually, the teams working on languages like Eta, Kotlin, and Scala should be really worried about these series of patents and should get infringement analysis done by an experienced IP lawyer, and/or press for invalidation of these patents.

-- Saurabh.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Alfred Matthews
@Saurabh thanks. Well done.

Are the patents each not effectively processor-specific?

At the very least, the LLVM and subsidiary IRs are of interest.

On Wed, Jan 30, 2019, 10:17 PM Flavio Villanustre <[hidden email]> wrote:
I'm no patent attorney either, but there is a temporal component when it comes to invalidating patents due to prior art, and Haskell is demonstrably "very prior" to these claims, even though it's not mentioned there. 

Only something that appeared after the patent was filed initially would potentially constitute infringement, as long as the claims made in the patent weren't made public by the inventors themselves prior to the filing, of course.

I guess, Haskell is safe and we live to see another day... :)

Flavio

On Wed, Jan 30, 2019, 21:51 Saurabh Nanda <[hidden email] wrote:
Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.

Actually, the teams working on languages like Eta, Kotlin, and Scala should be really worried about these series of patents and should get infringement analysis done by an experienced IP lawyer, and/or press for invalidation of these patents.

-- Saurabh.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Alfred Matthews
Also by my reading a patent derived from LLVM does not restrict either LLVM or ( the same thing ) its IR. The patent covers (only) processor-specific instructions and such forks and their subsidiary.

At the least, not its ideas.

Uninteresting, in our context.

I am an untitled intelligent reader. Pay me if you wish.

Ymmv.

On Wed, Jan 30, 2019, 10:21 PM Alfred Matthews <[hidden email]> wrote:
@Saurabh thanks. Well done.

Are the patents each not effectively processor-specific?

At the very least, the LLVM and subsidiary IRs are of interest.


On Wed, Jan 30, 2019, 10:17 PM Flavio Villanustre <[hidden email]> wrote:
I'm no patent attorney either, but there is a temporal component when it comes to invalidating patents due to prior art, and Haskell is demonstrably "very prior" to these claims, even though it's not mentioned there. 

Only something that appeared after the patent was filed initially would potentially constitute infringement, as long as the claims made in the patent weren't made public by the inventors themselves prior to the filing, of course.

I guess, Haskell is safe and we live to see another day... :)

Flavio

On Wed, Jan 30, 2019, 21:51 Saurabh Nanda <[hidden email] wrote:
Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.

Actually, the teams working on languages like Eta, Kotlin, and Scala should be really worried about these series of patents and should get infringement analysis done by an experienced IP lawyer, and/or press for invalidation of these patents.

-- Saurabh.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Alfred Matthews
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

Sorry, this is a necessary omission by me.

On Wed, Jan 30, 2019, 10:42 PM Alfred Matthews <[hidden email]> wrote:
Also by my reading a patent derived from LLVM does not restrict either LLVM or ( the same thing ) its IR. The patent covers (only) processor-specific instructions and such forks and their subsidiary.

At the least, not its ideas.

Uninteresting, in our context.

I am an untitled intelligent reader. Pay me if you wish.

Ymmv.

On Wed, Jan 30, 2019, 10:21 PM Alfred Matthews <[hidden email]> wrote:
@Saurabh thanks. Well done.

Are the patents each not effectively processor-specific?

At the very least, the LLVM and subsidiary IRs are of interest.


On Wed, Jan 30, 2019, 10:17 PM Flavio Villanustre <[hidden email]> wrote:
I'm no patent attorney either, but there is a temporal component when it comes to invalidating patents due to prior art, and Haskell is demonstrably "very prior" to these claims, even though it's not mentioned there. 

Only something that appeared after the patent was filed initially would potentially constitute infringement, as long as the claims made in the patent weren't made public by the inventors themselves prior to the filing, of course.

I guess, Haskell is safe and we live to see another day... :)

Flavio

On Wed, Jan 30, 2019, 21:51 Saurabh Nanda <[hidden email] wrote:
Also, the wording seems to be sufficiently broad to cause some concern to Haskell & Rust compilers, but the compilation of two programs in two unrelated languages will probably prevent an infringement.

Actually, the teams working on languages like Eta, Kotlin, and Scala should be really worried about these series of patents and should get infringement analysis done by an experienced IP lawyer, and/or press for invalidation of these patents.

-- Saurabh.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Saurabh Nanda
In reply to this post by Alfred Matthews


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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Richard O'Keefe
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Jack Kelly
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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Patents on Maybe and Tuple

Richard O'Keefe
In reply to this post by Jack Kelly
The Australian system ran an experiment about 20-some years ago
where they put some pending patents on-line and invited people
to tell them about prior art.  I did this for an attempt to
patent decimal arithmetic...

On Fri, 1 Feb 2019 at 11:28, Jack Kelly <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.