
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.ht... [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 --

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
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.ht... [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.

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.

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 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.

@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
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
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.

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
@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
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
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.

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
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
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
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
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.

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'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
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.

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
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
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.

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
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
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
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.

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
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
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
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.
participants (7)
-
Alfred Matthews
-
Christopher Allen
-
Flavio Villanustre
-
Henk-Jan van Tuyl
-
Jack Kelly
-
Richard O'Keefe
-
Saurabh Nanda