Computers:

Estimate the impact on Android, especially vs. iPhone, if Google's ad revenue was declining?

Observe Google's primary Achilles heel being the often unattainable simultaneous maximization of both CR and CTR, or that paid and unpaid ads are not co-mingled. Eliminating this tension derives from a fundamental epiphany.

Carl Hewitt, PhD MIT wrote:Arbiters can be constructed so they are physically symmetrical and then strongly isolated from the environment. So it is hard to imagine a source of bias.

Coase's Theorem

Any artificial barrier ultimately fails. For example, your arbiter doesn't have infinite memory and thus there is bound to how much it can buffer while waiting to confirm delivery of the data it arbitrates.

Bottom line is the data and control flow of the algorithm has to be concurrent, and no amount of STM, Actor, other hocus pocus will magically make it so.

Actors provide a low-level model of concurrency, but there still need to be high-level concurrent programming paradigms on top of that model, else the low-level model will fail.

Scala's higher-kinded types enabled the paradigm of Haskell's type classes, as Daniel did with Monad. See section 7.2 Encoding Haskell’s type classes with implicits of Generics of a Higher Kind.

Notably section 6.1 Implementation explains why it may be difficult (if not impractical) to implement higher-kinded types for languages without type erasure, such as .Net languages, e.g. C#.

Tony Morris, author of Scalaz library wrote:

First, I will get a couple of nitpicks out of the way. Martin’s L2 specifies that variance annotations will be used at this level. I (we: scalaz) propose that there is another level again, where you come to the realisation that variance annotations are not worth their use in the context of Scala’s limited type-inferencing abilities and other details. Instead, prefer a short-hand version of fmap and contramap functions.

Could that be because in Scalaz you are implementing the monad "bind" and "map" as duck typing type classes (the Haskell way), instead of as a supertype interface (trait) of the monad subtype, as I proposed here.

Or here for a more readable version.

Duck typing breaks Liskov Substitution Principle.

Of course Haskell doesn't have subtyping and uses duck typing exclusively. This of course violates SPOT and separation-of-concerns which impacts on the Expression Problem, code readability, and maintenance. Extension by duck typing can break existing code, when there are unintended collisions.

Composability is very important, but doesn't exist without referential transparency, which of course Haskell has and Scala does not enforce.

I haven't had time to study your Scalaz versus the Scala standard libraries, so I can comment on the relative merits.

Exactly as a I expected, I am looking at your code here, and instances of List[T] do not inherit from Monad[M[_]]. Instead you are using implicits to simulate inheritance using structural typing (a/k/a duck typing, “if it quakes like a duck, it must be a duck”). This is the Scala way of emulating Haskell’s type class, see section 7.2 Encoding Haskell’s type classes with implicits of Generics of a Higher Kind. The link I provided in my prior post using the similar construct, so apparently you didn’t bother to click it.

There is no distinction between ad-hoc polymorphism and structural typing w.r.t to the point I was making about extensibility issues.

You are confused and rude.

I see my rebuttal is awaiting you to release it from moderation.

Given my rebuttal, my original point remains, which is that of course you don’t get any benefit from variance annotations when you structure your inheritance using implicit to emulate Haskell’s type class, instead of the subtyping way I proposed in the link of my first comment.

You are apparently trying to do Haskell in Scala, instead of leveraging Scala’s subtyping strengths, no wonder you are so frustrated and lashing out. Scala can’t do Haskell’s strengths, because Haskell doesn’t have subtyping, thus I understand that type inference is much simpler in Haskell.

Tony is wrong of course, because he is thinking what happens low-level inside the JVM, not the semantics of the Java language.

The pointer of a reference is always passed-by-value, but this is irrelevant since it not accessible. The reference can only access the instance it points to. When the reference is passed, the instance may passed-by-reference or by-value. The primitive types pass-by-value.

Read about call-by-sharing, to get some insight:

http://stackoverflow.com/questions/4790050/can-scala-call-by-reference/5012338#5012338

No Tony, you are wrong.

Where is the pointer type in Java? Everything is an object in Java. You are dead wrong.

Java has no notion of a “pointer”, such as in C. You can’t increment a reference or do any operations on it. In Java, a reference is semantically synonymous with an object. Thus it is passing the objects by-reference. You are correct, the pointers are being passed-by-value behind the scenes, but a pointer is not a type in Java.

But you have no ground to stand on, to be attacking people on this issue. It is semantically correct to say that Java passes the objects by-reference and everything is an object in Java.

P.S. Java isn’t my language, I have never compiled a single line of Java in my life.

Can’t you use (None : Option[Int]) in place of none? Seems I read somewhere that Scala has that compile-time cast for aiding type inference.

There is a fascinating discussion about the practical utility of monads for mainstream programming. That discussion morphs from an initial hypothesis that monads vs. actors can be used to interopt imperative and functional programming, to one of recognition that monads provide abstraction of widespread programming paradigms, e.g.

http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html?showComment=1295992148701#c6727611476735111271

Perhaps an even more widely used abstraction is the Applicative, which is a supertype of a pure monad:

http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html?showComment=1295998124929#c138376235115429371
http://blog.tmorris.net/applicative-functors-in-scala
http://blog.tmorris.net/monads-do-not-compose/

It might not be easy for some to grasp Applicative from that research paper, and I have a layman's concise tutorial, but I will wait to provide a link once my implementation is complete, because the tutorial uses my syntax. I promise it won't be incomprehensible for Java laymen.

Applicative is a neat pattern, because it allows the application of a function distributed (curried) over the wrapped elements of a tuple of Applicative, and unlike Monad#bind, the function is always called and can not be short-circuited by the computation and/or state of the wrapping.

However, and the main reason I make this post here, is that an empty container is incompatible with Applicative, if the emptiness is not a type parameter of the container, because the empty container can not provide an empty element to the function application, if the function is not expecting it (i.e. does not accept an empty type). This means that Nil for an empty List type is incompatible with Applicative. Only List[T] extends Applicative[Option[T]] will suffice. In my prior comments on this page, I had mentioned I expected problems with Nil and prefer to use Option[T] return type on element access to model an empty container.

The prior linked research paper seems to conflict with my assertion, wherein it shows how to implement the Applicative#ap (apply) for monads on page 2, and the statements that every monad is an Applicative in section 5 and conclusion section 8. However, what I see is that although the Monad#ap can return the same value as the Applicative#ap, the side-effects are not the same. The Applicative#ap will always call the input function (with empty elements as necessary) and the Monad#ap will return an empty value and short-circuit calling the function. The research paper alludes to this in discussion of the differences in evaluation tree in section 5. The research paper I think is coming from the mindset of Haskell ad-hoc polymorphism (i.e. tagged structural typing) where there is no subtyping, thus Monad#ap is not expected to honor the semantic conditions of the Liskov Substitution Principle, i.e. Monad is not a subtype of Applicative in Haskell. This is real-world an example of why I am against ad-hoc polymorphism and structural typing. Of course, side-effects are not supposed to matter in a 100% pure language such as Haskell.

Any way, back to the point that Nil is incompatible with Applicative side-effects semantics (when either the container is not monad or Applicative#ap does not always input a pure function to apply), perhaps this might be one example of Tony Morris's (author of Scalaz) criticism of Scala's libraries, given that in Scalaz apparently Monad is a subtype of Applicative. I am not taking a stance yet on the general criticism, because my library implementation is not complete, so I do not yet know what I will learn.

@Horst
Correction: I have just clarified in my linked documentation translated as follows.

The semantics of Applicative[T]#ap do not allow a subtype which is non-invertible to an unwrapped T, i.e. empty container not allowed, unless there is a subtype of the subtype (or a subtype of T) that represents the null state (e.g. the subtype, or T, is an Option type).

Perhaps that is implicit in the four laws for Applicative. I will check that next.

Thus I think Applicative#ap can implemented for an empty container using Nil in Scala, by returning a (Nil : List[B]), where I assume that is the correct Scala syntax for compile-time cast of List[Nothing] (a/k/a Nil) to the expected return type B of the curried function.

Alternatively Applicative#ap could be implemented for an empty container using Option elements, by returning the wrapped curried function with (None : Option[B]). This requires every possible composition function to input Option. So now I am seeing some good justification for the Nil strategy of Scala's library.

Also studying the situation more, I realize there is no difference between the side-effects of the Applicative#ap and Monad#ap. I think I was conflating in my mind with Monad#bind.

So I no longer see any problem, nor a requirement for pure function per to solve it.

Hopefully I have helped explain Applicative and provide further insight in how to simplify the explanation of Monad.

Thus I don't yet know an example of why Morris is dissatisfied with the Scala libraries.

P.S. note in the linked docs in my prior comment, I am currently using Maybe as synonymous to Option.

I still don't like Nil (extends List[Nothing]), because unlike None (extends Option[Nothing]), a Nil can throw an exception on accessing head or tail. In general for all programming, I want to always force unboxing and make throwing an exception illegal (for the scalable composition reason explained in an early comment on this page).

So I realized there is a third way to represent an empty list (or in general a container), which never throws an exception and I think it is the optimum one compared against the two alternatives I presented in the prior comment.

trait OptionList[+T]
case class List[+T] extends OptionList[T]
case object Nil extends OptionList[Nothing]
(or case class Nil[T] extends OptionList[T])

The point is that when you have a List, then it can't be empty and no need to unbox, and when you have an OptionList, you must unbox (i.e. match-case) it before you can access any members of List, e.g. head or tail. If you get a case Nil upon unboxing, then it has no members from List that would throw an exception in Scala's current Nil, e.g. head and tail.

Now I need to discover why Scala didn't do their Nil this way? Maybe there is an important tradeoff I am not aware of yet.

I had suggested an idea for improving Haskell's handling of space "leaks", with a similar preference for paging fault load as the metric of promotion.

1. How do we make users pay? Any one distributing code from our system much use an installation program that interacts with our database. Or they must track installations and be willing to open books to 3rd party audit if we question their royalty payments. This is policed by the contributors of code to our free market system (this is why I prefer to prioritize client side applications first, not server side). The code will be copyrighted. Unlike for pirated music, there won't be much incentive to pirate our code, because the people distributing software products employing our code, will likely be giving away the software for free and making money via advertising and/or service subscriptions. The people who distribute the code (e.g. if Firefox uses some of our code one day, or Google uses it), will pay us for all their user activations. In other words, our business model is B2B (business-to-business) and we aim to employ thousands or millions of programmers. Note I think the license should state the installation program should ensure our database is incremented for each time a copy of the code is "installed" on a client computer, so for JavaScript browser apps that means setting cookie (or user signup if login is always required).
   
   Philosophical tangent: Many people have argued against copyright, but they were actually arguing against closed source. The Bible says thou shall not steal. Jason Hommel who is against patents, says you can't give away something that isn't free, for free. That would be socialism, and it ends in failure. No one wants to use the courts to enforce copyright, but the Bible says that we get the government we deserve, so those who steal end up with a government to steal from them.
   
2. How to price code contributions? The contributor must set his/her price and be able to adjust it based on market results. We should probably offer several standard pricing models to choose from, but the contributor sets the pricing within the chosen model. For example, a model that might make a lot of sense if the code is free for the first say 1000 users, then a sliding price discounted by volume. This encourages adoption of the code and wide use, and even when the price kicks in, it only applies to the 1001th user, so the price is increasing rather slowly as divided by 1001, and then the volume discounts kick in. The point is that the price paid is a no brainer for the person who wants to utilize the code in their project, as by the time they scale, the price is negligible to their own profit model.
   
3. How do we enable bug fix and refinement contributions? The contributor of the bug fix or refinement has to set a price as % or fixed $ that is added to the existing pricing of the code being fixed or refined. The market will choose whether to adopt this new code or not. The contributor of the original code will decide whether to lower his price to accommodate the new fix at the original price or not. Both contributors will be free to adjust their pricings as they observe what each other do. It is online negotiation proxy.
   
4. How do we stop duplication or theft of code? This is not users getting access to code for free, but rather stopping contributions which are basically just ripoffs of existing contributions. If such ripoff is posted outside our system, we can use copyright law to go after it, if we feel it is blatant. If the ripoff is within our system, we will have an online reporting process, and these will be judged by experts. The reporter has to pay for this upfront, but if the accused loses, then the accused is liable to pay this in our system (we can deduct from his/her earning, etc). Outside our system, we will go after excessive abuses at our discretion, but the contributor may also go fight in the courts. Within our system, we are the final judge and the contributor waves rights to go to extern court. This will all be in our Terms of Service contract on signup.
   
5. Why would anyone pay when so much free open source exists? You get what you pay for. If you want quality and well supported code, the person doing the coding needs to be earning an income. Most of that free stuff is not readily reusable as it is undocumented, virtually unsupported spaghetti.
   

Law professor Yochai Benkler explains how collaborative projects like Wikipedia and Linux represent the next stage of human organization. By disrupting traditional economic production, copyright law and established competition, they’re paving the way for a new set of economic laws, where empowered individuals are put on a level playing field with industry giants.

What this picture suggests to us is that we’ve got a radical change in the way information production and exchange is capitalized. Not that it’s become less capital intensive, that there’s less money that’s required, but that the ownership of this capital, the way the capitalization happens, is radically distributed. Each of us, in these advanced economies, has one of these (grabs nearby computer), or something rather like it — a computer. They’re not radically different from routers inside the middle of the network. And computation, storage, and communications capacity are in the hands of practically every connected person — and these are the basic physical capital means necessary for producing information, knowledge, and culture, in the hands of something like 600 million to a billion people around the planet.

What this means is that for the first time since the Industrial Revolution, the most important means — the most important components of the core economic activities — remember, we are in an information economy — of the most advanced economies, and there more than anywhere else, are in the hands of the population at large. This is completely different than what we’ve seen since the Industrial Revolution.

So we’ve got communications and computation capacity in the hands of the entire population, and we’ve got human creativity, human wisdom, human experience — the other major experience, the other major input. Which unlike simple labor -stand here turning this lever all day long — is not something that’s the same or fungible among people. Any one of you who has taken someone else’s job or tried to give yours to someone else, no matter how detailed the manual, you cannot transmit what you know, what you will intuit under a certain set of circumstances. In that, we’re unique, and each of us holds this critical input into production, as we hold this machine.

Shelby,

If I understand correctly, I think you are trying to gain royalties on programming work, and help others get that too. I think that's probably the wrong model.

If I compare programming to writing, what's the Biblical model? Hard to say. Today's model requires copywriting protections, which I see as fraudulent and anti Biblical. Writing is not property. What if the gospel writings were property? They were, but only in the sense that the actual scrolls were costly to make and produce, and copies cost a lot of money to make.

So, yes, I gain from my writings, via the internet, since my writings stand and remain as long term search engine landing pages for people who may be interested in buying bullion.

All the time we get buyers who buy because they know I'm a Christian, and because they agree with what I've written online.

So, that is a form of residual, but it's free market based. There is a "back room" upsell, via jhmint, that makes it work.

Of course, I did this for free anyway, for years, with bibleprophesy.org, but it did not produce immediate fruit. In fact, the lack of the kind of fruit that a person needs to live drove me away from prophecy, and into precious metals.

Think of ways, instead, to help the programmers get fruit quicker, and thus, the rewards will be more economically motivating for more people.

Not so many men like us can think of long term rewards as motivating factors.

In fact, I hope that the majority of my reward does not come in this lifetime, as this part of life is very short, compared to eternity.

Shelby wrote:I am not proposing to enforce copyright. I have said that up to 1000 end users (per program created), the code should be free. So people can freely copy, but if they get into business level volumes, then they need to pay. If programmers don't get paid for their independent work, then they have to go work as slaves for large corporations who take 99% of the fruit. God does not want that system, as it is retarding progress on spreading knowledge.

There is no restriction adding to existing work and incorporating it in new work. The only copyright restriction I proposed, is they must not give away in business volumes, that which is not free. In other words, the big corporations are not allowed to enslave knowledge.

No enforcement will ever be necessary. Corporations don't want to violate copyright, as they lose face in the development community.

Open Source Lowers Cost, Increases Value

Closed source can not compete with open source, because the cost of programming is nearly the entire cost for a software company. For example, if the design of a manufactured item costs 1000 times the cost to manufacture 1 unit when a million units are produced, then the design cost is an insignificant 1/1000th of the total cost. The replication and distribution costs of software are approaching zero, thus the design (programming) cost is approaching the total cost. Thus, any company that is not sharing the programming cost with other companies, is resource constrained relative to those companies which are sharing their programming costs. Tangentially, this is why patents on software retard maximum social value obtained from programming investment.

For-profit software companies gain market leverage and market-fitness by diversifying their products and/or services from the shared code at the top level of integration.

With standardized open source license on code, corporations can spontaneously share the cost of programming investment, without the friction, delay, risk, uncertainty, and complexity of multiple, multifarious, bilateral, ad hoc sharing negotiations.

Increased code reuse (sharing) lowers the programming cost for corporations, enabling them to focus capital on their market-fitness integration expertise-- where they generate profits.

Project Granularity of Code Re-use Limits Sharing, Cost Savings, and Value

Open source has reduced the total programming cost to corporations and end users, but due to project-level granularity of code reuse (i.e. sharing), this reduction is not maximized, and costs have not decreased for smaller companies and individual programmers in those cases where they can not spontaneously build derivative code incorporating only parts of projects. Although there has been a boom in diversity and market-fitness of software products, it is not maximized, which is the manifestation of the lack of cost reduction in the aforementioned cases.

The scale of open source reuse is limited by general lack of fine-grained reuse of code inherent in the lack of referential transparency in existing software languages. Instead, we primarily have reuse of entire projects, e.g. multiple companies from the exchange economy sharing programming investment on Linux, Apache server, Firefox browser, etc..It is not easy to reuse sub-modules (i.e. parts) from these projects in other projects, due to the lack of forethought and referential transparency (i.e. too much "spaghetti code" littered with hidden inextricable, interdependencies) in existing software language and design. The granularity of code reuse dictates the scale of shared investment, because for example fewer companies would find an incentive to invest in an entire project than to invest in reuseable code modules within projects, where those modules could be used in a greater diversify of derivative software. Increase the granularity of code reuse by orders-of-magnitude via referential transparency in software languages, then the sharing of programming cost will also increase by orders-of-magnitude. With orders-of-magnitude lower programming cost, then smaller companies and individual programmers will be able to move to the top of the food chain of integration, and there will be orders-of-magnitude faster rate of progress and diversity of market-fitness in software.

Increased Granularity of Re-use Will Transition from Reputation to Exchange Economy

As granularity of reuse of programming code increases via new software languages that incorporate referential transparency paradigms, the economics of contribution will need to become more fungible. Currently the economics of open source is funded by large corporations which have clear strategic paybacks for the projects they choose to invest in. At the project level of granularity, strategic ramifications are reasonable to calculate. However, as granularity of reuse increases, the diversity of scenarios of reuse will increase exponentially or greater, so thus it will become impossible to calculate a payback for a specific contribution.

Although some open source proponents have postulated that the "gift culture"[1] drives contribution, as diversity of contribution increases into smaller parts (instead of project-level contribution), the value of reputation will plummet in areas that reward free contribution. First, it will become much less necessary to gain social status in order to get other people to agree to work with you, as contribution will become disconnected from project objectives and a leader's ability to make a project succeed. Instead, contributors will need another payback incentive. Second, since the economic inputs of large corporations will diminish in significance, the value of reputation in gaining income (a job) will diminish. Instead individual programmers and smaller companies will create their own jobs, by creating more derivative software, given the lower cost of reuse of smaller modules. So the incentive to reuse increases as cost of reuse is lowered via increased granularity of referential transparency, but what will motivate contribution if the value of reputation diminishes? The answer is the value of reciprocity. Those who want to reuse, will become willing to contribute, if others who want to reuse are willing to contribute. This is an exchange economy.

Although some argue that gifting contributions is driven by the incentive to have your contribution merged into the code of the derivative software you use[3], yet with a referentially transparent programming model and automated builds from a repository, customized builds may have no ongoing maintenance. Moreover, if a bug-fix or improvement can increase the value (as defined below) of the source contribution it is fixing even if the price of the source contribution is lowered by the price requested for the fix, then existing derivatives are not discouraged from adopting the fix. Thus, the owner of the source contribution could become the gate-keeper for merging fixes into derivative works, not the owner of the derivative work, which thus decentralizes the process as compared to the gift economic model currently employed for open source.

Studying history, there are no instances where the "gift culture" scaled to an optimal free market. Gift cultures exist only where inefficient social hierarchies are subsidized by abundance, e.g. open source currently funded via large corporate contributions driven by the abundant unmet end user demand for software. However, every year in China, 1 out of 6 million college graduates can't find a job, and many more are underpaid and underutilized, the world is currently at a debt-saturation crossroads, and it is not clear how there will be sufficient abundance of jobs to employ the billions in the developing world. Exchange economies are how the free market optimally anneals best-fit and diversity in times of lack of the subsidy of abundance. Reputation is measured in fungible units, called money or in our case, more specifically the value of current active contributions.

The challenge is how to make the exchange of reusable small module contribution value fungible and efficient. The value of a module of code is determined by its exchange price and the quantity of derivative code that employs it. The price should be increased or decreased to maximize this value. The price is paid periodically in bulk by those distributing for-profit derivative software, not micro-payments. Typically the price would apply to a per installation (not per user) license, where upgrades (fixes and improvements) might be free to existing installations because the code is continually re-used in new derivative works that pay the price. Thus the proposed exchange economic model has an advantage over the gift model, in that upgrade costs are amortized over derivative software proliferation, instead of the service contract model.[4]

Copyright Codifies the Economic Model

So if for-profit derivative use of a contribution has a price, then contributing stolen code could destroy value. This is copyright, and is analgous in the gift (reputation) economy to the use of copyright in existing open source standard licenses to force that derivative works give credit the source contribution. In each economic model, copyright codifies the restrictions that make that model. Closed source is a command economy, free open source is a gift (reputation) economy, and priced open source is an exchange economy. Note since gift (reputation) economy relies on social status and abundance subsidy, it does not economically maximize spontaneous individual efforts, i.e. similarities to socialism.

Code:

Economic Model  Copyright Restriction
---------------------------------------
  Command          no derivatives, no copies
  Gift            no delisting the source
  Exchange        no selling of stolen source

Human language writing is mostly a gift (reputation) economy, because the writer gains upsell benefits as his ideas and reputation grow, even via those who re-distribute the writings without paying royalties. Programming is different from writing in a crucial aspect-- the end users never read the code and 99.9% of the population are not programmers[2] (and even amongst programmers, most do not read the code of every software they use). In the current hacker gift (reputation) economy model, programmers can gain value by building reputation amongst a smaller circle of peers who know their work well, and given the funding for contribution is coming from large corporations that have strategic interests met by the free sharing model, then prevention of theft adds no value. However, if granularity of reuse incentivizes a move towards more of an exchange economy model, then theft is parasite on value, as there is less upsell benefits when reputation is morphed from small circles of social hierarchy to wider scale exchange value, and so copyright will morph to codify that theft is not allowed. Note that value in the exchange economy is based on quantity of derivative reuse, thus it creates more value to incentivize free reuse where those derivatives will be reused in paid derivatives. Thus the differential pricing in exchange economics, i.e. free use for non-profit purposes or upstart business volumes, and volume discounts for-profit use.

There is not likely to be complete shift from reputation to exchange economics, but rather a blending of the two.

[1] Eric Raymond, Homesteading the Noosphere, The Hacker Milieu as Gift Culture, http://www.catb.org/~esr/writings/homesteading/homesteading/ar01s06.html

[2] http://stackoverflow.com/questions/453880/how-many-developers-are-there-in-the-world

[3] Eric Raymond, The Magic Cauldron, The Inverse Commons, http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cauldron/ar01s05.html

[4] Eric Raymond, The Magic Cauldron, The Manufacturing Delusion, http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cauldron/ar01s03.html

SLK currently supports the C, C++, Java and C# languages on all platforms. Note that the SLK parsers primarily consist of tables of integers as arrays and a very small parse routine that only uses the simple, and universally supported features of the language. This is in contrast to parser generators that produce recursive descent code. They must force a certain programming model on the user because the parsing code is intermixed with the user action code. SLK places no limits or requirements on the coding style of the user.

Performance comment from Fischer & LeBlanc (1991), page 120:

Since the LL(1) driver uses a stack rather than recursive procedure calls to store symbols yet to be matched, the resulting parser can be expected to be smaller and faster than a corresponding recursive descent parser.

Code:

def len( s : String ) : Int = s.length

def len( s : String ) : Int { s.length }

def len( s : String ) : Int { return s.length }

val len : String => Int = s => s.length

val len = (s: String) => s.length

val len : String => Int = _.length

object len {
  def apply( s : String ) : Int = s.length
}

Code:

def f( arg1, arg2 ) = arg1 + arg2

def f( arg1 )( arg2 ) = arg1 + arg2

Code:

Value: 5      [1,2,3]    abstract  abstract      abstract
Type:  Int    List[Int]  List[T]    Pair[U, V]    Iterable[T, Sub[_]]
Kind:  *      *          * -> *    * -> * -> *    * -> (* -> *) -> *

Code:

class Iterable[T, Sub]
{
  filter : T -> Bool -> Sub
}

class ListInt inherits Iterable[Int, ListInt] {}

Code:

class Iterable[T]
{
  filter : T -> Bool -> Iterable[T]
}

class List[T] inherits Iterable[T]
{
  filter : T -> Bool -> List[T]  // an override
}

Code:

class Iterable[T, Sub[_]]
{
  filter : T -> Bool -> Sub[T]
}

class List[T] inherits Iterable[T, List] {}