Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

True Scala complexity

yz.mit.edu

Post reply on HN
Print view View original

131–140 of 152 posts

Re: True Scala complexity

#131

Post by scott_s »

lisper wrote: post #127
scott_s wrote: post #125

Earlier quoted context omitted.

The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. So, it's an issue that only comes up in a statically typed language. Of course, I don't program in Scala, so my explanation may not be accurate.

> The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. That's right. > So, it's an issue that only comes up in a statically typed language. No, that's wrong. You can do type inference in non-statically typed languages. Lisp compilers do this all…

If a compiler infers types at compile-time for a dynamically typed language, I still consider that "static typing" because it's statically inferring the types. If the term "static typing" is the problem, then I can rephrase: it only comes up when you try to determine all types before executing the program.

Re: True Scala complexity

#132

Post by soc88 »

rwallace wrote: post #121
soc88 wrote: post #80

Earlier quoted context omitted.

You pretty much point to solutions which don't solve the problem mentioned in the blog post at all and seeing how C# extension methods basically reintroduced instanceOf checks as an implementation necessity I'm pretty sure that extension methods are the wrong way to go.

I don't remember C# extension methods being particularly prone to incur instanceOf checks, but I could be missing something; can you expand on this?

Have a look at how stuff like Count is implemented. It basically does instanceOf checks for ICollection to figure out if the underlying type supports a better way to compute the result (instead of iterating trough the whole collection).

This is completely non-extensible and people have to pay the price for this syntactic sugar (e. g. extension methods not discoverable with Reflection).

Other languages have a much cleaner approach: traits (in languages like Scala) and default methods (in Java) both solve the problem in a more straightforward and correct way.

Re: True Scala complexity

#133

Post by soc88 »

chollida1 wrote: post #117
harryh wrote: post #15

Earlier quoted context omitted.

"adding an additional function to the existing collections library is something that's possible in other languages" Is it possible in other statically compiled strongly typed languages? I don't think so? The advantages/disadvantages of static vs. dynamic languages seem out of scope for the "is scala too complex?" question.

> Is it possible in other statically compiled strongly typed languages? I don't think so? Sure it is :) see C# http://msdn.microsoft.com/en-us/library/bb383977.aspx

I don't see how it solves the problem mentioned.

Re: True Scala complexity

#134

Post by awj »

nickik wrote: post #112
awj wrote: post #77

Earlier quoted context omitted.

They are, until someone makes a five parameter monster because "someday I'll want that genericity." To be honest, though, I just googled the extensions I could remember until I hit one that hinted at creating a situation where the compiler simply doesn't have enough information to compile your code. That said, yeah, UndecidableInstances look like a much better example. Especially when googling it turns up things like…

Is MultiParameterTypeClasses something like multible dispatch from CLOS?

In that both embody the concept of using the types of multiple arguments to determine which instance of a function gets called, yes.

That's where the similarity ends, though. CLOS does this at runtime during method invocation, MPTC "dispatch" is determined at compile time. Multiple dispatch will generally have some overhead that MPTC won't, but it's more flexible in that the set of function implementations can be extended without recompiling.

Also, due to limitations of type analysis or type expressivity, it's possible to write something that would work for the specific instances where you are using MPTC but can't be proven to work for all instances of the types involved. Then again this is almost always an issue with static typing. Wether the compiler is saving you from a bad decision or keeping you from doing your job is a matter of personal opinion.

Re: True Scala complexity

#135

Post by soc88 »

a_strange_guy wrote: post #113
soc88 wrote: post #101

Earlier quoted context omitted.

That has nothing to do with the issues mentioned in the original article. In fact, the thing you described is trivial in Scala. implicit def Upcase(s: String) = new { def upcase = s.toUpperCase } "abc".upcase

I thought we were talking about "adding methods" to collection-like things so that they look as if they were built-in. And this was what the article was about: That it gets complex (and impossible) if you want to solve it for the general case. It wasn't abut type-safety, just about complexity. The problems in Scala arise, because you have to extort yourself if you want to "add a method" in the privileged position aft…

This is really, still missing the point. “adding methods” is trivial.

The real complexity is when you add method M to collection C and expect that class A which does not have any relationship with C also gets the method.

It has been shown that it is possible in Scala, without all the unnecessary complexity shown in the authors post.

Still, I fail to see any statically typed language even coming close to what is requested from Scala.

Re: True Scala complexity

#136

Post by nickik »

awj wrote: post #134
nickik wrote: post #112

Earlier quoted context omitted.

Is MultiParameterTypeClasses something like multible dispatch from CLOS?

In that both embody the concept of using the types of multiple arguments to determine which instance of a function gets called, yes. That's where the similarity ends, though. CLOS does this at runtime during method invocation, MPTC "dispatch" is determined at compile time. Multiple dispatch will generally have some overhead that MPTC won't, but it's more flexible in that the set of function implementations can be ext…

Thanks very intresting.

You might be intressted in this paper I read just a couple of days ago: "Extending Dylan’s type system for better type inference and error detection". (Dylan OO is simular to CLOS) A system like that helps to get the dispatch overhead down while still beeing able to extend it at runtime and you get alot of the typesafty.

http://opendylan.org/documentation/publications.html

Re: True Scala complexity

#137

Post by lisper »

scott_s wrote: post #131
lisper wrote: post #127

Earlier quoted context omitted.

> The issue is with static typing. One can define a filterMap function in Scala much as you defined it in CL. The author's goal is to do that while also always statically knowing the most precise type of the returned collection. That's right. > So, it's an issue that only comes up in a statically typed language. No, that's wrong. You can do type inference in non-statically typed languages. Lisp compilers do this all…

If a compiler infers types at compile-time for a dynamically typed language, I still consider that "static typing" because it's statically inferring the types. If the term "static typing" is the problem, then I can rephrase: it only comes up when you try to determine all types before executing the program.

That's right.

At this point I would like to remind both you and soc88 of a parable:

Patient: Doctor, it hurts when I do this.

Doctor: Well, don't do that.

(Soc88's response, in the context of this parable, is something along the lines of, "But anyone who doesn't do this is a moron.")

Inferring types at compile time is necessarily hard. It is a corollary of the halting problem that no static type inference can be perfect. Therefore you have the following choices:

1. A simple compiler that sometimes fails to identify type errors at compile time

2. A simple compiler that sometimes produces false positives (i.e. signals a type error in a program that is in fact correct)

3. A complicated compiler. (Note that even a complicated compiler will also do 1 or 2 or both, but potentially less often than a simple compiler.)

Those are your only options. Reasonable people can disagree over which is preferable.

Re: True Scala complexity

#138

Post by soc88 »

scott_s wrote: post #124
dcsobral wrote: post #81

Earlier quoted context omitted.

Both you and jashkenas are missing the point. The examples you are giving are also pretty easy to do in Scala. The more complex method he is proposing (filterMap) cannot be done at all in the languages you mention, though he only uses it precisely to get the most complex kind of method that Scala collections offer. But it is also possible, and I just blogged about it here: http://dcsobral.blogspot.com/2012/01/adding-…

Instead of getting bogged down in his specific example (the tree), I think it's more helpful to focus on his larger points in "On Acknowledging Problems" (the forest).

I disagree. The problem here is that those claiming “it is easy in language A” haven't even understood the problem.

People should first actually understand the problem, only after that a discussion about solutions makes sense.

Re: True Scala complexity

#139

Post by soc88 »

Dn_Ab wrote: post #107
harryh wrote: post #105

Earlier quoted context omitted.

OK I read up some on this and neither Gosu enhancement nor C# extended methods come close to what the post author is trying to attempt (adding methods to Seq and having them automatically get attached to Array, String, and CharSequence) with a single method . So it doesn't really seem like they solve the problem "how do I add a filterMap function to all arrays or collections that works pretty much how I want it to" a…

Up top http://news.ycombinator.com/item?id=3444688 I gave working code that comes close. To be fair the reason why it gets closer (works with both F# and C# lists,arrays, sequences,dictionaries,maps,strings etc) is clerical. From this thread, I understand Scala and Java arrays are divorced. But the problem is: put in a string and it gives back a list of characters. So I use the term it is "topologically correct" heh.…

Returning the most precise result types (both collection _and_ element type) is a requirement. If this wouldn't be required, the problem would be much easier.

Re: True Scala complexity

#140

Post by scott_s »

lisper wrote: post #137
scott_s wrote: post #131

Earlier quoted context omitted.

If a compiler infers types at compile-time for a dynamically typed language, I still consider that "static typing" because it's statically inferring the types. If the term "static typing" is the problem, then I can rephrase: it only comes up when you try to determine all types before executing the program.

That's right. At this point I would like to remind both you and soc88 of a parable: Patient: Doctor, it hurts when I do this. Doctor: Well, don't do that. (Soc88's response, in the context of this parable, is something along the lines of, "But anyone who doesn't do this is a moron.") Inferring types at compile time is necessarily hard. It is a corollary of the halting problem that no static type inference can be perf…

I don't disagree with your points, but now that we've established that, that is why your original example does not solve the problem as presented in the post. The problem inherently has to do with statically inferring types.
Post reply on HN