I think perhaps as Scala is academic, speed takes more of a focus for some
decisions. Although what you're describing with nested pairs works
perfectly well, the performance of grabbing item N off the Tuple is N-1
lookups on Pair. Call it what you will, but Scala tries to strike a
balance between elegance and speed. As you add these higher-level
abstractions it can be tough to keep them fast enough for "general-purpose"
(or better yet, specific purpose) computing.
Note that Scala takes the approach for sizes you outline in it's "Seq"
abstract Trait. It is recommended against calling the length method for
performance reasons. If you want fast length calculations, use a List.
It seems if you'd like to support an arbitrary number of Tuples, you
literally should return Arrays of Objects or some form of Collection, then
have javac auto-cast results for you in bytecode. The difference here
would be some form of bytecode flag that says: "This return value isn't a
list, it's actually a Tuple of these other types". Either that, or have the
JVM support tuples directly
-Josh
On Mon, Feb 9, 2009 at 10:50 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
> If you have inference, you can create TupleXes by chaining tuples.
> So a (String, Integer, Double) tuple would be:
> Pair<String, Pair<Integer, Double>>.
> Then you add a light sprinkling of syntax sugar to make it not look
> ridiculous.
> I don't understand why scala doesn't work this way. It would avoid
> littering the namespace with a tonne of these and having an arbitrary
> limit of 22.
> A 'Pair' could then support asking how big it is (it would check if
> it's second element is a Pair, and if so, return that pair's size +1,
> and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> Undefined type and don't count those either).
> On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com> wrote:
> > They're actually unifying Function arguments and Tuples so you can use
> > them interchangeably (I believe in 2.8). In java this looks
> > ridiculuous, as you don't have scala's style of type-inference. My
> > guess would be that if tuple support isn't native to the language
> > currently, it will be in the future.
> > Scala sometimes gets the syntactic-sugar wrong where you have to do
> > things like someFunction((x,y)), but in general it "just works".
> > It also supports extracting tuples using pattern matching like so:
> > val (x,y) = someFunction()
> > which may look a lot uglier in java:
> > (String x, int y) = someFunction();
> > but is still rather nice for a "pair" class.
> > Also, as a Side note, Tony Morris's project "Functional Java" has a
> > Tuple class hidden in its bowels of Monads and Theory. It's actually
> > called a "Product" (the classes are named PN where N is a number from
> > 1-8)
> > Here's the docshttp://
> functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/index...
> > On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com> wrote:
> > > Thanks David !
> > > 22... interesting...
> > > How did they do the syntactic support for ( and ) to mean Tuple? Is it
> > > special or like anything else, just defs?
> > > On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
> > > > Scala has tuple classes up to size 22 included in the base langauge
> > > > package. The (var1, var2, ...) syntax gets compiled into an
> > > > instantiation of the properly sized Tuple class.
> > > > Michael Neale wrote:
> > > > > So how would you do it in scala ;) ?
> > > > > (sorry I always find it crushing how easy everything is in scala,
> when
> > > > > I have to look at java).
> > > > > never looking into what scala *actually* does with tuples, if its
> > > > > something nasty or not... (someone else I am sure knows if it is a
> > > > > good or bad thing).
> (sorry I always find it crushing how easy everything is in scala, when
> I have to look at java).
> Of course you can just do:
> def foo() : (String, Int) = ("Hello", 42)
> never looking into what scala *actually* does with tuples, if its
> something nasty or not... (someone else I am sure knows if it is a
> good or bad thing).
> On Feb 10, 7:05 am, Viktor Klang <viktor.kl...@gmail.com> wrote:
> > I'd recommend putting a static factory method named "pair" aswell,
> > with a bit of static import magicks:
> > final Pair<String,String> values = pair("foo","bar");
> > instead of
> > final Pair<String,String> values = Pair.of("foo","bar");
> > because
> > final Pair<String,String> values = of("foo","bar"); //doesn't really make
> > sense...
> > On Mon, Feb 9, 2009 at 8:30 PM, Reinier Zwitserloot <reini...@gmail.com
> >wrote:
> > > .of instead of .create?
> > > I likey.
> > > On Feb 9, 6:26 pm, d...@happygiraffe.net (Dominic Mitchell) wrote:
> > > > On Mon, Feb 09, 2009 at 05:27:42AM -0800, Reinier Zwitserloot wrote:
> > > > > 1. By using a constructor, you don't get type inference. Use a
> static
> > > > > method, like so:
> > > > > public static <P, Q> Pair<P, Q> create(P a, P b) {
> > > > > return new Pair<P, Q>(a, b);
> > > > > }
> > > > > and then make the actual constructor private.
> > > > Hear, hear! Although, I'd call it "of" rather than create, as that's
> > > > what the google collections library does. The type inference leads
> to a
> > > > really nice API.
> > > > * Don't have setters, pairs should be immutable.
> > > > * Do you really need to get at pairs from within JavaBeans? I'd
> guess
> > > > probably not. Most of the time, the components of a pair will be
> > > > extracted within a line or two of the call site.
> > > > A nice discussion, anyways. I wish my iPod hadn't run out of juice
> half
> > > > way through. :)
> > > > -Dom
> > --
> > Viktor Klang
> > Senior Systems Analyst
> 22 is the number of partitions of 8, and 8 is the largest cube in the
> Fibonacci sequence, and the Fibonacci sequence is the most popular FP
> example.
> But my brain isn't big enough to know if its a serious answer or
> not. :)
> On Feb 10, 1:50 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > If you have inference, you can create TupleXes by chaining tuples.
> > So a (String, Integer, Double) tuple would be:
> > Pair<String, Pair<Integer, Double>>.
> > Then you add a light sprinkling of syntax sugar to make it not look
> > ridiculous.
> > I don't understand why scala doesn't work this way. It would avoid
> > littering the namespace with a tonne of these and having an arbitrary
> > limit of 22.
> > A 'Pair' could then support asking how big it is (it would check if
> > it's second element is a Pair, and if so, return that pair's size +1,
> > and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> > Undefined type and don't count those either).
> > On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com> wrote:
> > > They're actually unifying Function arguments and Tuples so you can use
> > > them interchangeably (I believe in 2.8). In java this looks
> > > ridiculuous, as you don't have scala's style of type-inference. My
> > > guess would be that if tuple support isn't native to the language
> > > currently, it will be in the future.
> > > Scala sometimes gets the syntactic-sugar wrong where you have to do
> > > things like someFunction((x,y)), but in general it "just works".
> > > It also supports extracting tuples using pattern matching like so:
> > > val (x,y) = someFunction()
> > > which may look a lot uglier in java:
> > > (String x, int y) = someFunction();
> > > but is still rather nice for a "pair" class.
> > > Also, as a Side note, Tony Morris's project "Functional Java" has a
> > > Tuple class hidden in its bowels of Monads and Theory. It's actually
> > > called a "Product" (the classes are named PN where N is a number from
> > > 1-8)
> > > Here's the docshttp://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/index...
> > > On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com> wrote:
> > > > Thanks David !
> > > > 22... interesting...
> > > > How did they do the syntactic support for ( and ) to mean Tuple? Is it
> > > > special or like anything else, just defs?
> > > > On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
> > > > > Scala has tuple classes up to size 22 included in the base langauge
> > > > > package. The (var1, var2, ...) syntax gets compiled into an
> > > > > instantiation of the properly sized Tuple class.
> > > > > Michael Neale wrote:
> > > > > > So how would you do it in scala ;) ?
> > > > > > (sorry I always find it crushing how easy everything is in scala, when
> > > > > > I have to look at java).
> > > > > > never looking into what scala *actually* does with tuples, if its
> > > > > > something nasty or not... (someone else I am sure knows if it is a
> > > > > > good or bad thing).
Even if you use a list instead of a tuple, lists don't support
heterogenous typing; you can have a tuple of type <String, Integer>,
but you can't have a list that is defined to contain alternating
String/Integer. I agree that it would be great if somehow the actual
underlying object is the same thing between a tuple and a list, and
the only difference is that a tuple has a set size and a listed type
for each element, whereas a list has a single type for all elements
and can be any size. I guess you could theoretically employ a nested
pairs structure just for the sake of the compiler, and actually do a
relatively quick list lookup + cast at runtime, using copious amounts
of unsafes. Without more sugar you can't make this work in the JVM
(You'd define a tuple as a Tuple<H, T>, so how do you extract the H of
the Tuple that is the T? Or the H of the Tuple that is the T of the
tuple that is the T of this tuple? The generics type system has the
info, there's just no syntax (in java 1.6) to liberate the right type.
Scala has higher kinded types but I'm not sure it can solve this
problem either, by the way.
I get that scala's current solution was the easiest given the
constraints, but littering the top-level namespace with 22 instances
of FoobarX, and having an arbitrary limit at all, can't be the right
answer. If java is to get arbitrary-length tuples I'd prefer a less
hacky solution.
On Feb 10, 8:40 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
> I think perhaps as Scala is academic, speed takes more of a focus for some
> decisions. Although what you're describing with nested pairs works
> perfectly well, the performance of grabbing item N off the Tuple is N-1
> lookups on Pair. Call it what you will, but Scala tries to strike a
> balance between elegance and speed. As you add these higher-level
> abstractions it can be tough to keep them fast enough for "general-purpose"
> (or better yet, specific purpose) computing.
> Note that Scala takes the approach for sizes you outline in it's "Seq"
> abstract Trait. It is recommended against calling the length method for
> performance reasons. If you want fast length calculations, use a List.
> It seems if you'd like to support an arbitrary number of Tuples, you
> literally should return Arrays of Objects or some form of Collection, then
> have javac auto-cast results for you in bytecode. The difference here
> would be some form of bytecode flag that says: "This return value isn't a
> list, it's actually a Tuple of these other types". Either that, or have the
> JVM support tuples directly
> -Josh
> On Mon, Feb 9, 2009 at 10:50 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
> > If you have inference, you can create TupleXes by chaining tuples.
> > So a (String, Integer, Double) tuple would be:
> > Pair<String, Pair<Integer, Double>>.
> > Then you add a light sprinkling of syntax sugar to make it not look
> > ridiculous.
> > I don't understand why scala doesn't work this way. It would avoid
> > littering the namespace with a tonne of these and having an arbitrary
> > limit of 22.
> > A 'Pair' could then support asking how big it is (it would check if
> > it's second element is a Pair, and if so, return that pair's size +1,
> > and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> > Undefined type and don't count those either).
> > On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com> wrote:
> > > They're actually unifying Function arguments and Tuples so you can use
> > > them interchangeably (I believe in 2.8). In java this looks
> > > ridiculuous, as you don't have scala's style of type-inference. My
> > > guess would be that if tuple support isn't native to the language
> > > currently, it will be in the future.
> > > Scala sometimes gets the syntactic-sugar wrong where you have to do
> > > things like someFunction((x,y)), but in general it "just works".
> > > It also supports extracting tuples using pattern matching like so:
> > > val (x,y) = someFunction()
> > > which may look a lot uglier in java:
> > > (String x, int y) = someFunction();
> > > but is still rather nice for a "pair" class.
> > > Also, as a Side note, Tony Morris's project "Functional Java" has a
> > > Tuple class hidden in its bowels of Monads and Theory. It's actually
> > > called a "Product" (the classes are named PN where N is a number from
> > > 1-8)
> > > Here's the docshttp://
> > functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/index...
> > > On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com> wrote:
> > > > Thanks David !
> > > > 22... interesting...
> > > > How did they do the syntactic support for ( and ) to mean Tuple? Is it
> > > > special or like anything else, just defs?
> > > > On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
> > > > > Scala has tuple classes up to size 22 included in the base langauge
> > > > > package. The (var1, var2, ...) syntax gets compiled into an
> > > > > instantiation of the properly sized Tuple class.
> > > > > Michael Neale wrote:
> > > > > > So how would you do it in scala ;) ?
> > > > > > (sorry I always find it crushing how easy everything is in scala,
> > when
> > > > > > I have to look at java).
> > > > > > never looking into what scala *actually* does with tuples, if its
> > > > > > something nasty or not... (someone else I am sure knows if it is a
> > > > > > good or bad thing).
As your third paragraph states, if you're grabbing the Nth element out of an N-tuple that way, you're doing something wrong. Probably confusing "tuple" with "list".
In some other languages, a method that takes a tuple transparently unpacks the tuple into local variables, so accessing the Nth element out of the tuple is just a local variable access. This is done on the assumption that you're asking for a tuple because you know what you're doing, and at least the majority of elements are meaningful. Similarly, the most common way to unpack returned tuples is through a case statement or multiple assignment, either of which is basically the same stunt as unpacking into local variables.
The reason Scala has 22 "Tuple" types is because they need some way to hook type information onto (1,"foo") in a way that's coherent to the Java-based generics model they've got.
Josh Suereth wrote:
> I think perhaps as Scala is academic, speed takes more of a focus for > some decisions. Although what you're describing with nested pairs works > perfectly well, the performance of grabbing item N off the Tuple is N-1 > lookups on Pair. Call it what you will, but Scala tries to strike a > balance between elegance and speed. As you add these higher-level > abstractions it can be tough to keep them fast enough for > "general-purpose" (or better yet, specific purpose) computing.
> Note that Scala takes the approach for sizes you outline in it's "Seq" > abstract Trait. It is recommended against calling the length method > for performance reasons. If you want fast length calculations, use a > List.
> It seems if you'd like to support an arbitrary number of Tuples, you > literally should return Arrays of Objects or some form of Collection, > then have javac auto-cast results for you in bytecode. The difference > here would be some form of bytecode flag that says: "This return value > isn't a list, it's actually a Tuple of these other types". Either that, > or have the JVM support tuples directly
> -Josh
> On Mon, Feb 9, 2009 at 10:50 PM, Reinier Zwitserloot <reini...@gmail.com > <mailto:reini...@gmail.com>> wrote:
> If you have inference, you can create TupleXes by chaining tuples.
> So a (String, Integer, Double) tuple would be:
> Pair<String, Pair<Integer, Double>>.
> Then you add a light sprinkling of syntax sugar to make it not look
> ridiculous.
> I don't understand why scala doesn't work this way. It would avoid
> littering the namespace with a tonne of these and having an arbitrary
> limit of 22.
> A 'Pair' could then support asking how big it is (it would check if
> it's second element is a Pair, and if so, return that pair's size +1,
> and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> Undefined type and don't count those either).
> On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com
> <mailto:Joshua.Suer...@gmail.com>> wrote:
> > They're actually unifying Function arguments and Tuples so you
> can use
> > them interchangeably (I believe in 2.8). In java this looks
> > ridiculuous, as you don't have scala's style of type-inference. My
> > guess would be that if tuple support isn't native to the language
> > currently, it will be in the future.
> > Scala sometimes gets the syntactic-sugar wrong where you have to do
> > things like someFunction((x,y)), but in general it "just works".
> > It also supports extracting tuples using pattern matching like so:
> > val (x,y) = someFunction()
> > On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com
> <mailto:michael.ne...@gmail.com>> wrote:
> > > Thanks David !
> > > 22... interesting...
> > > How did they do the syntactic support for ( and ) to mean
> Tuple? Is it
> > > special or like anything else, just defs?
> > > On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com
> <mailto:dchu...@gmail.com>> wrote:
> > > > Scala has tuple classes up to size 22 included in the base
> langauge
> > > > package. The (var1, var2, ...) syntax gets compiled into an
> > > > instantiation of the properly sized Tuple class.
> > > > Michael Neale wrote:
> > > > > So how would you do it in scala ;) ?
> > > > > (sorry I always find it crushing how easy everything is in
> scala, when
> > > > > I have to look at java).
> > > > > never looking into what scala *actually* does with tuples,
> if its
> > > > > something nasty or not... (someone else I am sure knows if
> it is a
> > > > > good or bad thing).
Reinier Zwitserloot wrote:
> Even if you use a list instead of a tuple, lists don't support
> heterogenous typing; you can have a tuple of type <String, Integer>,
> but you can't have a list that is defined to contain alternating
> String/Integer. I agree that it would be great if somehow the actual
> underlying object is the same thing between a tuple and a list, and
> the only difference is that a tuple has a set size and a listed type
> for each element, whereas a list has a single type for all elements
> and can be any size. I guess you could theoretically employ a nested
> pairs structure just for the sake of the compiler, and actually do a
> relatively quick list lookup + cast at runtime, using copious amounts
> of unsafes. Without more sugar you can't make this work in the JVM
> (You'd define a tuple as a Tuple<H, T>, so how do you extract the H of
> the Tuple that is the T? Or the H of the Tuple that is the T of the
> tuple that is the T of this tuple? The generics type system has the
> info, there's just no syntax (in java 1.6) to liberate the right type.
> Scala has higher kinded types but I'm not sure it can solve this
> problem either, by the way.
> I get that scala's current solution was the easiest given the
> constraints, but littering the top-level namespace with 22 instances
> of FoobarX, and having an arbitrary limit at all, can't be the right
> answer. If java is to get arbitrary-length tuples I'd prefer a less
> hacky solution.
> On Feb 10, 8:40 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
>> I think perhaps as Scala is academic, speed takes more of a focus for some
>> decisions. Although what you're describing with nested pairs works
>> perfectly well, the performance of grabbing item N off the Tuple is N-1
>> lookups on Pair. Call it what you will, but Scala tries to strike a
>> balance between elegance and speed. As you add these higher-level
>> abstractions it can be tough to keep them fast enough for "general-purpose"
>> (or better yet, specific purpose) computing.
>> Note that Scala takes the approach for sizes you outline in it's "Seq"
>> abstract Trait. It is recommended against calling the length method for
>> performance reasons. If you want fast length calculations, use a List.
>> It seems if you'd like to support an arbitrary number of Tuples, you
>> literally should return Arrays of Objects or some form of Collection, then
>> have javac auto-cast results for you in bytecode. The difference here
>> would be some form of bytecode flag that says: "This return value isn't a
>> list, it's actually a Tuple of these other types". Either that, or have the
>> JVM support tuples directly
>> -Josh
>> On Mon, Feb 9, 2009 at 10:50 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
>>> If you have inference, you can create TupleXes by chaining tuples.
>>> So a (String, Integer, Double) tuple would be:
>>> Pair<String, Pair<Integer, Double>>.
>>> Then you add a light sprinkling of syntax sugar to make it not look
>>> ridiculous.
>>> I don't understand why scala doesn't work this way. It would avoid
>>> littering the namespace with a tonne of these and having an arbitrary
>>> limit of 22.
>>> A 'Pair' could then support asking how big it is (it would check if
>>> it's second element is a Pair, and if so, return that pair's size +1,
>>> and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
>>> Undefined type and don't count those either).
>>> On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com> wrote:
>>>> They're actually unifying Function arguments and Tuples so you can use
>>>> them interchangeably (I believe in 2.8). In java this looks
>>>> ridiculuous, as you don't have scala's style of type-inference. My
>>>> guess would be that if tuple support isn't native to the language
>>>> currently, it will be in the future.
>>>> Scala sometimes gets the syntactic-sugar wrong where you have to do
>>>> things like someFunction((x,y)), but in general it "just works".
>>>> It also supports extracting tuples using pattern matching like so:
>>>> val (x,y) = someFunction()
>>>> which may look a lot uglier in java:
>>>> (String x, int y) = someFunction();
>>>> but is still rather nice for a "pair" class.
>>>> Also, as a Side note, Tony Morris's project "Functional Java" has a
>>>> Tuple class hidden in its bowels of Monads and Theory. It's actually
>>>> called a "Product" (the classes are named PN where N is a number from
>>>> 1-8)
>>>> Here's the docshttp://
>>> functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/index...
>>>> On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com> wrote:
>>>>> Thanks David !
>>>>> 22... interesting...
>>>>> How did they do the syntactic support for ( and ) to mean Tuple? Is it
>>>>> special or like anything else, just defs?
>>>>> On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
>>>>>> Scala has tuple classes up to size 22 included in the base langauge
>>>>>> package. The (var1, var2, ...) syntax gets compiled into an
>>>>>> instantiation of the properly sized Tuple class.
>>>>>> Michael Neale wrote:
>>>>>>> So how would you do it in scala ;) ?
>>>>>>> (sorry I always find it crushing how easy everything is in scala,
>>> when
>>>>>>> I have to look at java).
>>>>>>> Of course you can just do:
>>>>>>> def foo() : (String, Int) = ("Hello", 42)
>>>>>>> never looking into what scala *actually* does with tuples, if its
>>>>>>> something nasty or not... (someone else I am sure knows if it is a
>>>>>>> good or bad thing).
Scala doesn't work that way because Tuples have O(1) access to all
elements where what you propose would have O(n) access. Having 22
Tuple classes is definitely a code smell. Same with having 22
Function classes. But those are code smells forced by the JVM. On
"machines" with a less strict stack discipline than the JVM, e.g. the
x86, there are other ways to encode tuples that are much more
flexible.
An alternative on the JVM is to use runtime byte code generation and
classloader-fu to generate TupleN classes as needed. But Scala has
avoided that kind of magic as it tends to not play well with other
things that want to do classloader-fu.
What you've proposed is called a Heterogeneous Linked List, or HList
for short. It's exactly the kind of list you get from Lisps. Most
statically typed languages can't do them, or at least not usefully.
HLists are very tricky to type correctly and still make pleasant to
use. Scala can do it, but only just barely using a currently
experimental compiler flag. When that feature stabilizes you can
probably expect HLists to be in the standard library.
Finally, related to your last point re: BGGA, Scala does have a type
for undefined called "Nothing." BGGA's undefined type was renamed
from "Unreachable" to "Nothing" in order to follow Scala's example:
http://gafter.blogspot.com/2008/08/java-closures-prototype-feature.html.
Both names make sense in context.
The BGGA Void type means something else. Void is the type of a
closure that returns normally but doesn't return any useful data.
Scala has an equivalent (again, before BGGA did), but Scala calls it
Unit to differentiate from the non-first class nature of Java's void
and to help further distinguish it from Nothing.
On Feb 9, 7:50 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> If you have inference, you can create TupleXes by chaining tuples.
> So a (String, Integer, Double) tuple would be:
> Pair<String, Pair<Integer, Double>>.
> Then you add a light sprinkling of syntax sugar to make it not look
> ridiculous.
> I don't understand why scala doesn't work this way. It would avoid
> littering the namespace with a tonne of these and having an arbitrary
> limit of 22.
> A 'Pair' could then support asking how big it is (it would check if
> it's second element is a Pair, and if so, return that pair's size +1,
> and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> Undefined type and don't count those either).
There's 'synthetic', which is a flag on class members that indicates
that they aren't intentional (by the code author), just a side-effect
of the compiler making it all work right. A side-effect is that most
IDEs suppress them in auto-complete models, which is overkill, but
another flag that means: This is a system type thing, so, auto-
complete, sure, but definitely don't generate javadocs, or offer it
when extending classes, etcetera. I don't like structural typing in a
java closure proposal, but if it does happen, The FunctionIII stuff
can also use such a flag. Adding flags to members is backwards
compatible. Just an idea.
NB: For a closure proposal I was cooking up I'm going to need a bunch
of synthetic publics, which fortunately works as intended; javac will
refuse to compile access to synthetics in .java source, and eclipse
does not list them in auto-completes etc, but the JVM completely
ignores the synthetic flag. (allows any call to a synthetic same as a
call to a non-synthetic). Nice feature.
On Feb 10, 3:45 pm, James Iry <james...@gmail.com> wrote:
> Scala doesn't work that way because Tuples have O(1) access to all
> elements where what you propose would have O(n) access. Having 22
> Tuple classes is definitely a code smell. Same with having 22
> Function classes. But those are code smells forced by the JVM. On
> "machines" with a less strict stack discipline than the JVM, e.g. the
> x86, there are other ways to encode tuples that are much more
> flexible.
> An alternative on the JVM is to use runtime byte code generation and
> classloader-fu to generate TupleN classes as needed. But Scala has
> avoided that kind of magic as it tends to not play well with other
> things that want to do classloader-fu.
> What you've proposed is called a Heterogeneous Linked List, or HList
> for short. It's exactly the kind of list you get from Lisps. Most
> statically typed languages can't do them, or at least not usefully.
> HLists are very tricky to type correctly and still make pleasant to
> use. Scala can do it, but only just barely using a currently
> experimental compiler flag. When that feature stabilizes you can
> probably expect HLists to be in the standard library.
> Finally, related to your last point re: BGGA, Scala does have a type
> for undefined called "Nothing." BGGA's undefined type was renamed
> from "Unreachable" to "Nothing" in order to follow Scala's example:http://gafter.blogspot.com/2008/08/java-closures-prototype-feature.html.
> Both names make sense in context.
> The BGGA Void type means something else. Void is the type of a
> closure that returns normally but doesn't return any useful data.
> Scala has an equivalent (again, before BGGA did), but Scala calls it
> Unit to differentiate from the non-first class nature of Java's void
> and to help further distinguish it from Nothing.
> On Feb 9, 7:50 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > If you have inference, you can create TupleXes by chaining tuples.
> > So a (String, Integer, Double) tuple would be:
> > Pair<String, Pair<Integer, Double>>.
> > Then you add a light sprinkling of syntax sugar to make it not look
> > ridiculous.
> > I don't understand why scala doesn't work this way. It would avoid
> > littering the namespace with a tonne of these and having an arbitrary
> > limit of 22.
> > A 'Pair' could then support asking how big it is (it would check if
> > it's second element is a Pair, and if so, return that pair's size +1,
> > and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> > Undefined type and don't count those either).
Re 22: consider the empty product/tuple and suddenly you are in the
realm of conspiracy theories. With the functions you actually see the
true number -- they explicitly start with 0.
How far is it from the EPFL to Lake Totenkopf? Does either really exist?
Who's reality is this anyway?
Peter
PS: no, we are probably not doomed, it's just the type of comments
people deserve for arbitrary cut-offs :-)
On Mon, 2009-02-09 at 17:48 -0800, Michael Neale wrote:
> Thanks David !
> 22... interesting...
> How did they do the syntactic support for ( and ) to mean Tuple? Is it
> special or like anything else, just defs?
> On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
> > Scala has tuple classes up to size 22 included in the base langauge
> > package. The (var1, var2, ...) syntax gets compiled into an
> > instantiation of the properly sized Tuple class.
> > Michael Neale wrote:
> > > So how would you do it in scala ;) ?
> > > (sorry I always find it crushing how easy everything is in scala, when
> > > I have to look at java).
> > > Of course you can just do:
> > > def foo() : (String, Int) = ("Hello", 42)
> > > never looking into what scala *actually* does with tuples, if its
> > > something nasty or not... (someone else I am sure knows if it is a
> > > good or bad thing).
On Feb 9, 9:26 am, d...@happygiraffe.net (Dominic Mitchell) wrote:
> Hear, hear! Although, I'd call it "of" rather than create, as that's
> what the google collections library does. The type inference leads to a
> really nice API.
Thanks, Dominic. I used your message as an incentive to replace our
Pair constructor with an "of" factory method. And yes, it does a great
job of cleaning things up! I hit one snag. Is there a way around the
following compilation problem?
public class PairTest {
/*
* The Pair.of() call below yields the following compilation
error: Type
* mismatch: cannot convert from Pair<Class<capture#1-of ? extends
* Exception>,Class<capture#2-of ? extends Exception>> to
Pair<Class<?
* extends Exception>,Class<? extends Exception>>
*/
public static void main(String[] args) {
Class<? extends Exception> foo;
Class<? extends Exception> bar;
// Original line with constructor.
Pair<Class<? extends Exception>, Class<? extends Exception>>
compiles = new Pair<Class<? extends Exception>, Class<? extends
Exception>>(
foo, bar);
// Failed attempt at using of.
Pair<Class<? extends Exception>, Class<? extends Exception>>
doesntCompile = Pair.of(
foo, bar);
}
> On Feb 9, 9:26 am, d...@happygiraffe.net (Dominic Mitchell) wrote:
> > Hear, hear! Although, I'd call it "of" rather than create, as that's
> > what the google collections library does. The type inference leads to a
> > really nice API.
> Thanks, Dominic. I used your message as an incentive to replace our
> Pair constructor with an "of" factory method. And yes, it does a great
> job of cleaning things up! I hit one snag. Is there a way around the
> following compilation problem?
> public class PairTest {
> /*
> * The Pair.of() call below yields the following compilation
> error: Type
> * mismatch: cannot convert from Pair<Class<capture#1-of ? extends
> * Exception>,Class<capture#2-of ? extends Exception>> to
> Pair<Class<?
> * extends Exception>,Class<? extends Exception>>
> */
> public static void main(String[] args) {
> Class<? extends Exception> foo;
> Class<? extends Exception> bar;
> // Original line with constructor.
> Pair<Class<? extends Exception>, Class<? extends Exception>>
> compiles = new Pair<Class<? extends Exception>, Class<? extends
> Exception>>(
> foo, bar);
> 22 is the number of partitions of 8, and 8 is the largest cube in the
> Fibonacci sequence, and the Fibonacci sequence is the most popular FP
> example.
> But my brain isn't big enough to know if its a serious answer or
> not. :)
> On Feb 10, 1:50 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > If you have inference, you can create TupleXes by chaining tuples.
> > So a (String, Integer, Double) tuple would be:
> > Pair<String, Pair<Integer, Double>>.
> > Then you add a light sprinkling of syntax sugar to make it not look
> > ridiculous.
> > I don't understand why scala doesn't work this way. It would avoid
> > littering the namespace with a tonne of these and having an arbitrary
> > limit of 22.
> > A 'Pair' could then support asking how big it is (it would check if
> > it's second element is a Pair, and if so, return that pair's size +1,
> > and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/
> > Undefined type and don't count those either).
> > On Feb 10, 3:20 am, Josh Suereth <Joshua.Suer...@gmail.com> wrote:
> > > They're actually unifying Function arguments and Tuples so you can use
> > > them interchangeably (I believe in 2.8). In java this looks
> > > ridiculuous, as you don't have scala's style of type-inference. My
> > > guess would be that if tuple support isn't native to the language
> > > currently, it will be in the future.
> > > Scala sometimes gets the syntactic-sugar wrong where you have to do
> > > things like someFunction((x,y)), but in general it "just works".
> > > It also supports extracting tuples using pattern matching like so:
> > > val (x,y) = someFunction()
> > > which may look a lot uglier in java:
> > > (String x, int y) = someFunction();
> > > but is still rather nice for a "pair" class.
> > > Also, as a Side note, Tony Morris's project "Functional Java" has a
> > > Tuple class hidden in its bowels of Monads and Theory. It's actually
> > > called a "Product" (the classes are named PN where N is a number from
> > > 1-8)
> > > Here's the docshttp://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/index...
> > > On Feb 9, 8:48 pm, Michael Neale <michael.ne...@gmail.com> wrote:
> > > > Thanks David !
> > > > 22... interesting...
> > > > How did they do the syntactic support for ( and ) to mean Tuple? Is it
> > > > special or like anything else, just defs?
> > > > On Feb 10, 11:51 am, David Chuhay <dchu...@gmail.com> wrote:
> > > > > Scala has tuple classes up to size 22 included in the base langauge
> > > > > package. The (var1, var2, ...) syntax gets compiled into an
> > > > > instantiation of the properly sized Tuple class.
> > > > > Michael Neale wrote:
> > > > > > So how would you do it in scala ;) ?
> > > > > > (sorry I always find it crushing how easy everything is in scala, when
> > > > > > I have to look at java).
> > > > > > never looking into what scala *actually* does with tuples, if its
> > > > > > something nasty or not... (someone else I am sure knows if it is a
> > > > > > good or bad thing).
