On Fri, Jul 11, 2014 at 5:18 PM, Johann <
johann...@densedata.com> wrote:
>
> On Friday, July 11, 2014 3:54:26 PM UTC+2, back2dos wrote:
>>
>> Why would you want to access a tuple as an array? What will `(1,
>> 2)[5]` do? And what's the point of reading the length, if the type
>> already defines it at compile time?
>
> It's possible to show that the type (A,(B,C)) is not ((A,B),C) using
> whatever syntax to access the contents (or just by looking at them, but that
> obviously didn't work for you) so I used array style indexing to not
> introduce more made-up syntax into the example than necessary.
That depends entirely on how you define such a type. You're just
implicitly assuming that the tuple definitions you seem to be used to
is the only possible one.
> And I used the .length as a vehicle to point out the runtime issues that your idea of
> "tuples" would introduce in the presence of type erasure. And I'm so glad
> you're asking, giving me the opportunity to clarify this immensely relevant
> point.
I am asking because I see no practical application here. This was the
problem you were able to come up with and my answer is that it's
quixotic. If you wish to discuss more relevant points, by all means,
make them.
>> What I was interested in is treating all functions as unary with the
>> help of tuples. Tuples behaving the way I suggest would give you that
>> for free.
>
> So it turns out that what you want has nothing to do with tuples to start
> with.
Yes, tuples can be defined independently of what I would like to
achieve. The reverse however, what I want being independent of (or as
you would say "having nothing to do with") tuples, is neither
generally nor particularly true. And since I assume that you are
familiar with basic formal logic, I find your "conclusion" quite
disingenuous.
> Tuples are product types, and (A,A,A) simply doesn't unify with (A,(A,A)).
That is how you choose to define them. On the other hand formally `(A,
A, A)` is defined precisely as `(A, (A, A))`, as explained here:
http://en.wikipedia.org/wiki/Tuple#Tuples_as_nested_ordered_pairs
Which is also how they are composed in Lisp. I will concede that it's
uncommon to have `((A, A), A)` and `(A, (A, A))` be equivalent, which
is what I think you've been getting at. But that does not mean that
defining tuples with such an equivalency will make the universe
explode.
You can insist on your definition of tuples and then by circular
argumentation and repeated insistence dismiss any other ideas, but I
really don't find that helpful. In the end it doesn't matter how
academics define them, or how Haskell or Scala or Lisp or
whoever/whatever defines them. What matters is having a definition
that proves practically useful. That is what we should discuss and I
would prefer that a lot to being presented arbitrary axiomatic choices
as fact.
> I don't agree that what you have in mind would come for free.
You are free to disagree. Better yet, if you are challenging a
universal statement I have made, you're in the advantageous position
of being able to prove your counterclaim with a simple example, that I
would be very interested to see ;)
> Despite having a certain appeal, it would have quite an impact by complicating the
> implementation of calls significantly, introduce issues with interfacing
> platform native code and whatnot.
That is speculation. Now you are making universal statements and so I
shall give you a counter example. Allowing unification between n-ary
functions and unary tupled functions by means of wrapping through the
implict conversions (the same that abstracts allow for) would actually
not be hard. It would change *nothing* about the implementation of
calls. It would have no effect about interfacing with platform native
code. A runnable proof of concept can be seen here:
http://try.haxe.org/#85A97
And I am not even saying this is the best solution. It's the first one
I come up with. And I for one would like to believe that if you
gentlemen stopped mechanically talking back and put your brains into
thinking about powerful applications of tuples if we integrate them
with other language features more deeply, we could come up with
something vastly more powerful than unnamed structs, which by
themselves tend to just invite an obscure coding style.
As for different nesting: I am not convinced that allowing an
analogous implicit conversion from `((A, B), C)` to `(A, (B, C))` is a
bad idea. Yes, they can have different runtime representations, but no
real argument has yet been made why having the compiler generate the
transformation from one structure to another for you is a bad bad
thing.
Best,
Juraj