Subscribe to ...considered harmful
6 Comments
Scala has tuples. Great, I like tuples. Immutable sequences, quite handy.
Here's one:
Cool. So how do I get a value out of one of these guys? Like this:
Wait, what? 1? But 1 is the zeroth element... oh, no you didn't.
No, you ... yes, you did. Oh, that's not good. Fire up the bug factory!
But it gets better.
Here's a big tuple in Scala:
Cool, here's another one:
Oh, wait, no. I can only get tuples of length 22 or less.
It was at this point that I went on a rampage and threw cars around until I suddenly shrank down to the size of the mild-mannered not-green ordinary guy that I usually am. Apparently - and this is just speculation based on this behavior - the Tuple class is defined on the first-year-CS110 student principle of "declare classes named TupleN until you get tired and then stop". I suppose there might be a reason for this, but from where I'm sitting on day two of exploring scala, it looks like a nice language except... WTF???? One-indexed tuples that can only be length 22 or less?
I can't wait to hear the reasoning behind that.
Here's one:
scala> val triple = (1,2,3) triple: (Int, Int, Int) = (1,2,3)
Cool. So how do I get a value out of one of these guys? Like this:
scala> triple._1 res6: Int = 1
Wait, what? 1? But 1 is the zeroth element... oh, no you didn't.
No, you ... yes, you did. Oh, that's not good. Fire up the bug factory!
But it gets better.
Here's a big tuple in Scala:
scala> val largeTuple = (1,2,3,4,5,6,7,8,9,0,11,22,33,44,55,66,77,88,99,00,111,222) largeTuple: (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int) = (1,2,3,4,5,6,7,8,9,0,11,22,33,44,55,66,77,88,99,0,111,222)
Cool, here's another one:
scala> val largerTuple = (1,2,3,4,5,6,7,8,9,0,11,22,33,44,55,66,77,88,99,00,111,222,333)
<console>:7: error: object Tuple23 is not a member of package scala
val largerTuple = (1,2,3,4,5,6,7,8,9,0,11,22,33,44,55,66,77,88,99,00,111,222,333)
^Oh, wait, no. I can only get tuples of length 22 or less.
It was at this point that I went on a rampage and threw cars around until I suddenly shrank down to the size of the mild-mannered not-green ordinary guy that I usually am. Apparently - and this is just speculation based on this behavior - the Tuple class is defined on the first-year-CS110 student principle of "declare classes named TupleN until you get tired and then stop". I suppose there might be a reason for this, but from where I'm sitting on day two of exploring scala, it looks like a nice language except... WTF???? One-indexed tuples that can only be length 22 or less?
I can't wait to hear the reasoning behind that.
Categories: Uncategorized
Share This Entry:
6 Comments On This Entry
Page 1 of 1
AdamSpeight2008
18 September 2012 - 03:51 PM
Do you really need a tuple that wide?
Wouldn't a custom object or class be much matter?
Wouldn't a custom object or class be much matter?
sepp2k
18 September 2012 - 11:30 PM
I don't think tuple indices starting at 1 is a likely source of bugs, since any out-of-bounds access would lead to a compilation error. Also you're probably more likely to use pattern matching to get at a tuple's elements than explicit indices.
I totally agree that arbitrary limitations are bad (though I agree with Adam that you'll never need tuples that large, so it's more bad on a conceptual level, not a practical one), but what alternative do you suggest? Variadic generics? How would those work (without turning into C++ templates)? This isn't a trivial problem to solve.
Also note that the same limitation exists in .net's Func, Action and Tuple classes - except in .net the limit is 16 for Func/Action and 8 for Tuple.
I totally agree that arbitrary limitations are bad (though I agree with Adam that you'll never need tuples that large, so it's more bad on a conceptual level, not a practical one), but what alternative do you suggest? Variadic generics? How would those work (without turning into C++ templates)? This isn't a trivial problem to solve.
Also note that the same limitation exists in .net's Func, Action and Tuple classes - except in .net the limit is 16 for Func/Action and 8 for Tuple.
jon.kiparsky
19 September 2012 - 08:58 AMAdamSpeight2008, on 18 September 2012 - 05:51 PM, said:
Do you really need a tuple that wide?
Wouldn't a custom object or class be much matter?
Wouldn't a custom object or class be much matter?
I don't know if I'll ever need a 24-member tuple. Could happen, I don't know - maybe I'll be doing string theory some day, and modelling a 24-dimensional space or something. What weirds me out here is not the number 22, it's that there's a cliff that I can walk off of - and what this implies about the underlying design. Tuple1, Tuple2, Tuple3... doesn't this look like your first experiments in BASIC?
I'm sure there's some reason for it, but I can't see it.
jon.kiparsky
19 September 2012 - 09:11 AMsepp2k, on 19 September 2012 - 01:30 AM, said:
I don't think tuple indices starting at 1 is a likely source of bugs, since any out-of-bounds access would lead to a compilation error. Also you're probably more likely to use pattern matching to get at a tuple's elements than explicit indices.
I'm not thinking of out-of-bounds access. Think about the case of using a tuple to return multiple values from a function (a typical python usage). I call that function, and I take those values. Now suppose I'm only interested in some of the values - now I have to think about the indexing to make sure I'm getting the right value. If I get this wrong, it's a tough one to spot.
It seems weird to me that you have both 0-indexing and 1-indexing in the same language. Multiplying complexity, making me think about the details of the language at the expense of the problem I'm solving.
Hulk smash! (but only smash a little, it's not that big a deal... :) )
Quote
I totally agree that arbitrary limitations are bad (though I agree with Adam that you'll never need tuples that large, so it's more bad on a conceptual level, not a practical one), but what alternative do you suggest? Variadic generics? How would those work (without turning into C++ templates)? This isn't a trivial problem to solve.
Also note that the same limitation exists in .net's Func, Action and Tuple classes - except in .net the limit is 16 for Func/Action and 8 for Tuple.
Also note that the same limitation exists in .net's Func, Action and Tuple classes - except in .net the limit is 16 for Func/Action and 8 for Tuple.
How does Python do it? Seems to work pretty well there.
sepp2k
19 September 2012 - 09:16 AMjon.kiparsky, on 19 September 2012 - 06:11 PM, said:
I'm not thinking of out-of-bounds access. Think about the case of using a tuple to return multiple values from a function (a typical python usage). I call that function, and I take those values. Now suppose I'm only interested in some of the values - now I have to think about the indexing to make sure I'm getting the right value. If I get this wrong, it's a tough one to spot.
Okay, but as I said: pattern matching. No chance of off-by-one errors when you write
(foo, _, bar) = myMethodThatReturnsThreeValues()[/il];.
Quote
It seems weird to me that you have both 0-indexing and 1-indexing in the same language.
Agreed.
Quote
Quote
Also note that the same limitation exists in .net's Func, Action and Tuple classes - except in .net the limit is 16 for Func/Action and 8 for Tuple.
How does Python do it? Seems to work pretty well there.
Python is dynamically typed.
sepp2k
19 September 2012 - 09:24 AM
C++11 does it by adding a variable number of arguments syntax to its Turing-complete monster of a template system, but that's not something that can be easily translated to Java/Scala-style generics. Specifically variadic templates in C++11 rely on having the ability to do template specialization (because variadic templates are recursive and need specialization to handle the base case).
If we wanted to add a similar feature without making type checking undecidable, we'd probably would need a way of express variadic generics without relying on recursion. Again I think that this is a non-trivial (though certainly interesting) problem.
Implementing a sort of restricted non-turing complete meta language that has map, filter and fold primitives to process lists of type arguments, could possibly work. But I certainly haven't thought this through in detail. At the very least that would add a good deal of complexity to the language.
If we wanted to add a similar feature without making type checking undecidable, we'd probably would need a way of express variadic generics without relying on recursion. Again I think that this is a non-trivial (though certainly interesting) problem.
Implementing a sort of restricted non-turing complete meta language that has map, filter and fold primitives to process lists of type arguments, could possibly work. But I certainly haven't thought this through in detail. At the very least that would add a good deal of complexity to the language.
Page 1 of 1
Trackbacks for this entry [ Trackback URL ]
← March 2021 →
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
Tags
My Blog Links
Recent Entries
Recent Comments
Search My Blog
0 user(s) viewing
0 Guests
0 member(s)
0 anonymous member(s)
0 member(s)
0 anonymous member(s)
| 