
iPwn Studios is seeking Haskell developers for its debut title, BloodKnight. * No prior game development experience is required, but you must be very comfortable working in Haskell. * Compensation is negotiable; profit-sharing may be available in some cases. * To apply, or for more information, contact me at ryan@ipwnstudios.com. BloodKnight is an action-roleplaying game inspired by games like Diablo and Fallout. It is currently in the final stages of development, and will be released later this year on a variety of smartphone platforms, including iPhone and Android. iPwn Studios is a start-up company located in Boston, MA. We believe in giving back to the Haskell community, so we've open-sourced our ghc-iphone project, which allows GHC to produce binaries for the iPhone. Check it out at http://projects.haskell.org/ghc-iphone/. Ryan Trinkle iPwn Studios

This sounds fantastic. Now I wish I had started learning haskell a few
years earlier.
As a side note, how is this project getting around the language
restrictions apple put in the developer license agreement?
--- [http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler]
In the new version of the iPhone Developer Program License Agreement
released by Apple today (and which developers must agree to before
downloading the 4.0 SDK beta), section 3.3.1 now reads:
3.3.1 — Applications may only use Documented APIs in the manner
prescribed by Apple and must not use or call any private APIs.
Applications must be originally written in Objective-C, C, C++, or
JavaScript as executed by the iPhone OS WebKit engine, and only code
written in C, C++, and Objective-C may compile and directly link
against the Documented APIs (e.g., Applications that link to
Documented APIs through an intermediary translation or compatibility
layer or tool are prohibited).
---
On Wed, May 26, 2010 at 2:52 PM, Ryan Trinkle
iPwn Studios is seeking Haskell developers for its debut title, BloodKnight. * No prior game development experience is required, but you must be very comfortable working in Haskell. * Compensation is negotiable; profit-sharing may be available in some cases. * To apply, or for more information, contact me at ryan@ipwnstudios.com. BloodKnight is an action-roleplaying game inspired by games like Diablo and Fallout. It is currently in the final stages of development, and will be released later this year on a variety of smartphone platforms, including iPhone and Android. iPwn Studios is a start-up company located in Boston, MA. We believe in giving back to the Haskell community, so we've open-sourced our ghc-iphone project, which allows GHC to produce binaries for the iPhone. Check it out at http://projects.haskell.org/ghc-iphone/.
Ryan Trinkle iPwn Studios
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, May 26, 2010 at 9:23 AM, Lyndon Maydwell
As a side note, how is this project getting around the language restrictions apple put in the developer license agreement?
From the project page :
This version uses Apple's official iPhone SDK as its back end compiler. David.

On May 26, 2010, at 03:50 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:23 AM, Lyndon Maydwell
wrote: As a side note, how is this project getting around the language restrictions apple put in the developer license agreement?
From the project page :
This version uses Apple's official iPhone SDK as its back end compiler.
You might want to reread that license agreement. Specifically: "Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)" -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
You might want to reread that license agreement. Specifically:
"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)"
Ah, yes. Ouch, that's abusive. Can they tell the difference though ? David.

On May 26, 2010, at 04:14 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
wrote: You might want to reread that license agreement. Specifically:
Ah, yes. Ouch, that's abusive. Can they tell the difference though ?
I suspect GHC-generated code is fairly distinctive even as machine code. But they don't have to go to that extent; all they have to do is use Google to find this thread. :( -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Hi guys, I don't think this licensing issue will be a problem for us. It's not clear to me that our game violates this new term, and we certainly don't violate any of the principles Steve Jobs used to justify it. If Apple wants to reject our app, they already have a variety of excuses at their disposal, as they've demonstrated on many occasions. Frankly, it'd be their loss; Android is now the fastest-growing smartphone market, and we'll be more than happy to focus on it (and other friendlier markets) if Apple's not interested in having our product on their platform. Ryan Trinkle iPwn Studios On Wed, May 26, 2010 at 4:18 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote:
On May 26, 2010, at 04:14 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
wrote: You might want to reread that license agreement. Specifically:
Ah, yes. Ouch, that's abusive. Can they tell the difference though ?
I suspect GHC-generated code is fairly distinctive even as machine code. But they don't have to go to that extent; all they have to do is use Google to find this thread. :(
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Anyway, does the license imply that one can't compile GHC's core language and RTS into objective-c, then compile it with their "so great" software ? El 26/05/2010, a las 05:51, Ryan Trinkle escribió:
Hi guys,
I don't think this licensing issue will be a problem for us. It's not clear to me that our game violates this new term, and we certainly don't violate any of the principles Steve Jobs used to justify it. If Apple wants to reject our app, they already have a variety of excuses at their disposal, as they've demonstrated on many occasions. Frankly, it'd be their loss; Android is now the fastest-growing smartphone market, and we'll be more than happy to focus on it (and other friendlier markets) if Apple's not interested in having our product on their platform.
Ryan Trinkle iPwn Studios
On Wed, May 26, 2010 at 4:18 AM, Brandon S. Allbery KF8NH
wrote: On May 26, 2010, at 04:14 , David Virebayre wrote: On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH wrote: You might want to reread that license agreement. Specifically: Ah, yes. Ouch, that's abusive. Can they tell the difference though ?
I suspect GHC-generated code is fairly distinctive even as machine code. But they don't have to go to that extent; all they have to do is use Google to find this thread. :(
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On May 26, 2010, at 10:17 , Pierre-Etienne Meunier wrote:
Anyway, does the license imply that one can't compile GHC's core language and RTS into objective-c, then compile it with their "so great" software ?
As I read it, yes; it says that the calls to their APIs must *originate* from permitted languages, and specifically prohibits using those languages via translation layers. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Well in this case I'd be really interested in seeing how the can tell the difference, be it only from a simple complexity theoretic point of view ! I understand they may look for common patterns in their compiler code to tell the difference between GHC's generated code and theirs, but pretending they can do it in this case only shows that Apple lawyers never communicate with the engineers. El 26/05/2010, a las 15:32, Brandon S. Allbery KF8NH escribió:
On May 26, 2010, at 10:17 , Pierre-Etienne Meunier wrote:
Anyway, does the license imply that one can't compile GHC's core language and RTS into objective-c, then compile it with their "so great" software ?
As I read it, yes; it says that the calls to their APIs must *originate* from permitted languages, and specifically prohibits using those languages via translation layers.
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On May 26, 2010, at 17:22 , Pierre-Etienne Meunier wrote:
Well in this case I'd be really interested in seeing how the can tell the difference, be it only from a simple complexity theoretic point of view ! I understand they may look for common patterns in their compiler code to tell the difference between GHC's generated code and theirs, but pretending they can do it in this case only shows that Apple lawyers never communicate with the engineers.
No clue how they might be planning to enforce it, but it's not like the lawyers care; it's up to Apple to decide if they want to pursue any individual possible case of infringement, and Jobs to figure out what kind of hole he's dug himself into. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, May 26, 2010 at 5:22 PM, Pierre-Etienne Meunier < pierreetienne.meunier@gmail.com> wrote:
Well in this case I'd be really interested in seeing how the can tell the difference, be it only from a simple complexity theoretic point of view ! I understand they may look for common patterns in their compiler code to tell the difference between GHC's generated code and theirs, but pretending they can do it in this case only shows that Apple lawyers never communicate with the engineers.
I think it is more a matter of Jobs trying to find any way he could to quickly block Adobe's attempted end-run around his blockade against Flash apps. While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code, all they need is to raise the spectre of doubt, and they have practically gutted all concern of a cross platform development environment emerging, because no sound business plan can be built on "I hope my major and only possible distributor doesn't figure out what I'm doing!" -Edward Kmett

On 27/05/2010, at 9:01 AM, Edward Kmett wrote:
While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code...
Uh, desire:tmp benl$ cat Hello.hs main = putStr "Hello" desire:tmp benl$ ghc --make Hello.hs desire:tmp benl$ strings Hello | head Hello base:GHC.Arr.STArray base:GHC.Arr.STArray base:GHC.Classes.D:Eq base:GHC.Classes.D:Eq failed to read siginfo_t failed: Warning: select buildFdSets: file descriptor out of range ...

Next up, binary obfuscation! Apple already uses these extensively in their
Fairplay code. Surely it isn't against the rules (yet?) to apply them to
your program before submitting it to the store? :P
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
While we can all acknowledge the technical impossibility of identifying
On 27/05/2010, at 9:01 AM, Edward Kmett wrote: the original source language of a piece of code...
Uh,
desire:tmp benl$ cat Hello.hs main = putStr "Hello"
desire:tmp benl$ ghc --make Hello.hs
desire:tmp benl$ strings Hello | head Hello base:GHC.Arr.STArray base:GHC.Arr.STArray base:GHC.Classes.D:Eq base:GHC.Classes.D:Eq failed to read siginfo_t failed: Warning: select buildFdSets: file descriptor out of range
...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Objects in the heap also have a very regular structure. They all have code pointers as their first word, which point to info tables that also have a regular structure [1]. GHC produced code is probably one of the easiest to identify out of all compiled languages... http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects Ben. On 27/05/2010, at 1:15 PM, Daniel Peebles wrote:
Next up, binary obfuscation! Apple already uses these extensively in their Fairplay code. Surely it isn't against the rules (yet?) to apply them to your program before submitting it to the store? :P
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
wrote: On 27/05/2010, at 9:01 AM, Edward Kmett wrote:
While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code...
Uh,
desire:tmp benl$ cat Hello.hs main = putStr "Hello"
desire:tmp benl$ ghc --make Hello.hs
desire:tmp benl$ strings Hello | head Hello base:GHC.Arr.STArray base:GHC.Arr.STArray base:GHC.Classes.D:Eq base:GHC.Classes.D:Eq failed to read siginfo_t failed: Warning: select buildFdSets: file descriptor out of range
...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code...
Uh,
∀p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly false, while ∃p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly true. Natural language does a rather poor job of making quantification unambiguous. - C.

On May 26, 2010, at 23:23 , C. McCann wrote:
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
wrote: While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code...
Uh,
∀p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly false, while ∃p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly true.
Natural language does a rather poor job of making quantification unambiguous.
If you really want to get jiggy with the corner cases, ask what counts as a transformation. /bin/cat? sed 's/a/b/g'? sed 'y/abcdefghijklmnopqrstuvwxyz/zyxwvutsrqponmlkjihgfedcba/'? unlit? cpp? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On May 27, 2010, at 00:20 , Brandon S. Allbery KF8NH wrote:
On May 26, 2010, at 23:23 , C. McCann wrote:
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
wrote: While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code...
Uh,
∀p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly false, while ∃p (PieceOfCode(p) -> CanIdentifySourceLanguage(p)) is clearly true.
Natural language does a rather poor job of making quantification unambiguous.
If you really want to get jiggy with the corner cases, ask what counts as a transformation.
And the best, if obsolescent, example of all: cfront. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Edward Kmett
On Wed, May 26, 2010 at 5:22 PM, Pierre-Etienne Meunier <span dir="ltr">mailto:pierreetienne.meunier@gmail.com</span> wrote: Well in this case I'd be really interested in seeing how the can tell the difference, be it only from a simple complexity theoretic point of view ! I understand they may look for common patterns in their compiler code to tell the difference between GHC's generated code and theirs, but pretending they can do it in this case only shows that Apple lawyers never communicate with the engineers. I think it is more a matter of Jobs trying to find any way he could to quickly block Adobe's attempted end-run around his blockade against Flash apps.While we can all acknowledge the technical impossibility of identifying the original source language of a piece of code, all they need is to raise the spectre of doubt, and they have practically gutted all concern of a cross platform development environment emerging, because no sound business plan can be built on "I hope my major and only possible distributor doesn't figure out what I'm doing!"
While it may be difficult to identify the original source language of an arbitrary piece of code, it is much simpler to identify Haskell as the original source language of a GHC-compiled piece of code for most pieces of code. There are a number of interesting discussions on this issue at the sites below: [1] Daring Fireball: "New iPhone Developer Agreement Bans the Use of Adobe's Flash-to-iPhone Compiler" http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler [2] Hacker News | Getting away from the frenzied rhetoric, my opinion is that what Apple really wa... http://news.ycombinator.com/item?id=1250946 [3] Knowing .NET » Blog Archive » "The Absurdity of Apple’s New iPhone Restrictions" http://www.knowing.net/index.php/2010/04/09/using-mathematica-to-generate-th... [4] "Why does everything suck?: Steve Jobs Has Just Gone Mad" http://whydoeseverythingsuck.com/2010/04/steve-jobs-has-just-gone-mad.html [5] "Apple takes aim at Adobe... or Android?" http://arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-androi... In addition, the following article sheds some light on the historical background for the initial Apple vs. Adobe schism: [6] "Rhapsody and blues" http://arstechnica.com/staff/fatbits/2008/04/rhapsody-and-blues.ars Curiously, in the original Apple Macintosh Superbowl commercial (see http://video.google.com/videoplay?docid=-715862862672743260#), Apple (then "Apple Computer") proclaimed the following:
On January 24th, Apple Computer will introduce Macintosh. And you'll see why 1984 won't be like "1984."
George Orwell's novel, _1984_, was essentially about freedom of expression (among a number of other freedoms). Ironically, by prohibiting freedom of expression in the choice of a programming language for the iPhone and requiring that all applications be "originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS Webkit engine," Apple has now become the epitome of the very thing it had originally set out *not* to be. -- Benjamin L. Russell [1] Gruber, John. "New iPhone Developer Agreement Bans the Use of Adobe’s Flash-to-iPhone Compiler." n.p. 8 Apr. 2010. Web. 29 May 2010. http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler. [2] raganwald. n.t. _Hacker News._ Y Combinator. 9 Apr. 2010. Web. 29 May 2010. http://news.ycombinator.com/item?id=1250946. [3] O'Brien, Larry. "The Absurdity of Apple’s New iPhone Restrictions." _Knowing .NET._ n.p. 9 Apr. 2010. Web. 29 May 2010. <http://www.knowing.net/index.php/2010/04/09/using-mathematica-to-generate-th...
.
[4] Williams, Hank. "Steve Jobs Has Just Gone Mad." _Why does everything suck?: Exploring the tech marketplace from 10,000 feet._ n.p. 8 Apr. 2010. Web. 29 May 2010. http://whydoeseverythingsuck.com/2010/04/steve-jobs-has-just-gone-mad.html. [5] Bright, Peter. "Apple takes aim at Adobe... or Android?" _Ars Technica._ Condé Nast Digital. Apr. 2010. Web. 29 May 2010. http://arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-androi.... [6] Siracusa, John. "Rhapsody and blues." _Ars Technica._ Condé Nast Digital. 3 Apr. 2008. Web. 29 May 2010. http://arstechnica.com/staff/fatbits/2008/04/rhapsody-and-blues.ars.

If you guys get a nice library layer going between the Java APIs and
Android NDK Haskell, I would very much like it if you could post it up
somewhere. I think the entire community could benefit.
Cheers.
~Liam
On 26 May 2010 19:51, Ryan Trinkle
Hi guys, I don't think this licensing issue will be a problem for us. It's not clear to me that our game violates this new term, and we certainly don't violate any of the principles Steve Jobs used to justify it. If Apple wants to reject our app, they already have a variety of excuses at their disposal, as they've demonstrated on many occasions. Frankly, it'd be their loss; Android is now the fastest-growing smartphone market, and we'll be more than happy to focus on it (and other friendlier markets) if Apple's not interested in having our product on their platform.
Ryan Trinkle iPwn Studios On Wed, May 26, 2010 at 4:18 AM, Brandon S. Allbery KF8NH
wrote: On May 26, 2010, at 04:14 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
wrote: You might want to reread that license agreement. Specifically:
Ah, yes. Ouch, that's abusive. Can they tell the difference though ?
I suspect GHC-generated code is fairly distinctive even as machine code. But they don't have to go to that extent; all they have to do is use Google to find this thread. :(
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, May 26, 2010 at 5:51 AM, Ryan Trinkle
Hi guys,
I don't think this licensing issue will be a problem for us. It's not clear to me that our game violates this new term, and we certainly don't violate any of the principles Steve Jobs used to justify it. If Apple wants to reject our app, they already have a variety of excuses at their disposal, as they've demonstrated on many occasions. Frankly, it'd be their loss; Android is now the fastest-growing smartphone market, and we'll be more than happy to focus on it (and other friendlier markets) if Apple's not interested in having our product on their platform.
Steve Jobs has been quite clear that apps written in other languages, even ones that are interpreted in, compiles down to or otherwise generate objective c source code, don't comply with the changes in section 3.3.1 of their license, so I'm not sure that you have much of a case.
“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”
Read more: http://techcrunch.com/2010/04/10/steve-jobs-responds-to-iphone-sdk-complaint... Haskell definitely qualifies as an 'intermediate layer', just like MonoTouch, and just like the Flash-to-Objective-C compiler that provoked the original response from Apple. http://www.taoeffect.com/blog/2010/04/steve-jobs-response-a-brief-followup/ Heck, even libraries that may contain scripting and modeling utilities like Unity3d are in jeopardy, due to this cockamamie restriction, which threatens to send the art of level design and game programming for the iphone technologically clear back into the early 90s, though at least there they appear to be treading lightly, since Unity has been useful in providing the iphone with a lot of high end content. http://answers.unity3d.com/questions/7408/is-unity3d-banned-by-new-apple-sdk... But, there are other numerous discussions floating around in the blogosphere involving previously approved applications written in scheme (even compiled via objective c), c#, or other middleware languages having their applications removed from the app store. So, sadly, I think your chances of shipping your a title written in Haskell on the iPhone are shot to hell. -Edward Kmett

So, sadly, I think your chances of shipping your a title written in Haskell on the iPhone are shot to hell.
+1 for the android version. Disclaimer: biased google employee :P Unfortunately then you get another cockamamie restriction in the whole JVM vs. tail calls thing... but if you can get around that then lots of people will like you a lot.

wouldn't they just want to have TCO happen during the compilation into
java? why would you want to output java that has recursion?
-Dan
On Wed, May 26, 2010 at 4:17 PM, Evan Laforge
So, sadly, I think your chances of shipping your a title written in Haskell on the iPhone are shot to hell.
+1 for the android version.
Disclaimer: biased google employee
:P
Unfortunately then you get another cockamamie restriction in the whole JVM vs. tail calls thing... but if you can get around that then lots of people will like you a lot. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, May 26, 2010 at 01:17:00PM -0700, Evan Laforge wrote:
Unfortunately then you get another cockamamie restriction in the whole JVM vs. tail calls thing... but if you can get around that then lots of people will like you a lot.
Working on it... :) John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

Of course, given that they have no way of determining that short of asking for the source code (and hiring another thousand reviewers to read it) or applying static analysis tools with heuristics to the programs. I really doubt they do the latter, and the former is unrealistic. Most people seem to think the clause is there mostly to discourage large companies like Adobe from making generic tools to translate to the iPhone/iPad. It would be a lot of effort for Apple to actually enforce it strictly. On Wed, May 26, 2010 at 3:58 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote:
On May 26, 2010, at 03:50 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:23 AM, Lyndon Maydwell
wrote: As a side note, how is this project getting around the language restrictions apple put in the developer license agreement?
From the project page :
This version uses Apple's official iPhone SDK as its back end compiler.
You might want to reread that license agreement. Specifically:
"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)"
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (14)
-
Ben Lippmeier
-
Brandon S. Allbery KF8NH
-
C. McCann
-
Dan Mead
-
Daniel Peebles
-
David Virebayre
-
DekuDekuplex@Yahoo.com
-
Edward Kmett
-
Evan Laforge
-
John Meacham
-
Liam O'Connor
-
Lyndon Maydwell
-
Pierre-Etienne Meunier
-
Ryan Trinkle