+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Why do we need 3 Vector3 types? (/thread-2009.html)
RE: Why do we need 3 Vector3 types? - worktycho - 06-16-2015
It sounds interesting, but rather off topic. I'm just curious about what you mean by any language? Because I'm pretty sure that there are language sets that are impossible in general. For example how can Haskell call a c++ varadic template?
RE: Why do we need 3 Vector3 types? - SamJBarney - 06-16-2015
Without more experience with how Haskell works and is implemented, I cannot give you an answer.
RE: Why do we need 3 Vector3 types? - worktycho - 06-16-2015
I'm thinking more about the programmers interface, some concepts are really hard to translate. For example C++ and Haskell.
How do you translate this function:
Code:
template<class T...>
std::tuple<Baz<T>::type...> foo (T... x)
{
return std::make_tuple<Baz<T>::type...>(bar(x)...)
}Haskell has no concept of varadics, and I'm sure that working out the Haskell type constraints for this (which is required to make return type inference work) is at least equivalent to the halting problem, if not impossible.
Or another example, Haskell to C#.
Code:
class Foo a where
bar :: int -> a
instance Foo Baz where
bar = something
instance Foo Blah where
bar = somethingA different implementation for bar is invoked depending on the type of the returned value. I'm pretty sure you cannot express that in C#.
RE: Why do we need 3 Vector3 types? - SamJBarney - 06-16-2015
I'm going to write up a little bit about how UPE works so that you can have a general idea of how it works.
Templates have been something that I have been struggling with implementing without header files, due to the fact that they only exist within the compiler itself; when you output the code, there is no template function, just copies of it for the specific types used.
Haskell doesn't need to know about templates, only the compiler has to know that it is. So, when it is compiling, it locates the function and determines that it is a template. It duplicates the code, specializes it for the type coming in, and pops that code into the file that was calling it. That, of course is in an ideal setting where the type coming in fulfills the requirements for the template.
As for C# not having return type inference, the compiler handles that all, making sure that the right function/method is used, and C# doesn't have to worry about it.
One thing that I haven't even considered yet is cross-language inheritance. I'm going to have to give that some thought.
RE: Why do we need 3 Vector3 types? - worktycho - 06-16-2015
Only Haskell does need to know about templates. Otherwise what is the type of this where foo is the c++ method from my previous post?
Code:
func x f = foo $ f xRE: Why do we need 3 Vector3 types? - SamJBarney - 06-16-2015
Sorry, you're going to have to explain that line to me. I'm not familiar with Haskell syntax
I assume that is a function call where f and x are arguments to foo.
RE: Why do we need 3 Vector3 types? - worktycho - 06-16-2015
No. First it is a function call to the parameter f, with the parameter x. Then foo is called on the result.
RE: Why do we need 3 Vector3 types? - SamJBarney - 06-16-2015
At runtime (UPE is a JIT engine), we query UPE for function foo. Foo is defined as a template, so we generate a specialized function for the arguments requested, and pass back a reference to that function. So Haskell doesn't need to know that it is a template, it just needs to know that it is calling a function called foo.
Hmm... that does make it a bit difficult since we cannot determine what the return type of f is, unless all Haskell types have a base type.
RE: Why do we need 3 Vector3 types? - worktycho - 06-16-2015
Haskell, Prolog, Verilog and Common Lisp would make extremely good test cases for your system, as they are all extremely different from most mainstream languages.
RE: Why do we need 3 Vector3 types? - SamJBarney - 06-16-2015
I know that Erlang is one that I am going to have trouble with, due to it needing a VM to handle scheduling, which in turn makes it need an interpreter.
I will definitely keep those in mind while I am testing it. Thanks for pushing me to think about it
