| 21:33:31 | * | NimBot joined #nimrod |
| 21:36:59 | Araq | so it's basically "errors in instantiation is no compile time error"? |
| 21:37:49 | zahary | checking requirements with arbitrary code is quite powerful, because once you add dependent types or "symbol attached properties", you can test for much richer set of requirements for the type (e.g. the order in which certain operations are done, relations between associated types and so on) |
| 21:37:49 | zahary | yes, it's similar to CFINAE (compilation-failure-is-not...) |
| 21:39:36 | zahary | also, in certain situations it's important that the type class remains "open" for explicit membership (there are examples from STL in the talk) - you can overload the typedesc based proc to do that |
| 21:41:09 | Araq | well I'm not to keen on my "with" ideas |
| 21:41:23 | Araq | we should strive for type macros instead |
| 21:42:12 | Araq | and try to use less and less built-in facilities for types |
| 21:43:25 | zahary | by type macros do you mean "compile time procs for checking requirements" or "compile time procs that generate types" ? |
| 21:46:12 | Araq | both |
| 21:46:27 | Araq | "low level type API to be done with it" |
| 21:48:45 | Araq | next topic: |
| 21:48:54 | Araq | the compiler has a hard time with uint64 |
| 21:49:10 | Araq | as we can't do firstOrd(t) etc. with it properly |
| 21:50:00 | Araq | most other compilers use bignums internally for these reasons |
| 21:50:22 | Araq | and it was another reason for me to leave out unsigned types |
| 21:50:38 | zahary | ah, I was on the virge of adding a separate uintValue case in PNode to work around similar problems with the max and min values |
| 21:51:36 | Araq | yeah but uintValue is too much work |
| 21:51:51 | Araq | and the resulting if explosion is horrible |
| 21:52:36 | Araq | and we don't have a bignum library to use |
| 21:52:53 | Araq | plus I don't really like the compiler to use bignums internally everywhere |
| 21:53:03 | Araq | as I have no idea how that would affect compile times |
| 21:53:07 | Araq | or memory usage |
| 21:55:49 | zahary | there are some fixed width bignum libraries for C++ that would be cheper to use |
| 21:56:38 | zahary | but still, uintValue should be the most efficient solution |
| 21:58:39 | zahary | http://www.ttmath.org/ |
| 22:01:17 | Araq | well I'm thinking about not supporting uint64 instead :-) |
| 22:02:12 | Araq | nobody cares if the max value can be 2^63-1 or 2^64-1 |
| 22:02:59 | zahary | it certainly is a low priority, but we should fix it eventually |
| 22:04:24 | Araq | god I'm glad unsigned floats don't exist :-) |
| 22:05:04 | Araq | it's so rude to be 1-dimensional :D |
| 22:05:58 | Araq | or maybe I make lastOrd et. al. for uint64 internal errors for now |
| 22:07:07 | Araq | iirc delphi treats 64 bit integers as non ordinal types to get around these issues |
| 22:07:28 | * | Trix[a]r_za is now known as Trixar_za |
| 22:09:47 | zahary | what is float128 btw? |
| 22:09:47 | zahary | we should add some support for the SSE intrinsics (we need just another c2nim import module) |
| 22:09:47 | zahary | http://msdn.microsoft.com/en-us/library/01fth20w%28v=vs.71%29.aspx |
| 22:12:48 | zahary | this header is available in all modern compilers |
| 22:12:48 | zahary | http://clang.llvm.org/doxygen/emmintrin_8h_source.html |
| 22:13:13 | Araq | yes we need it |
| 22:13:31 | Araq | afaik x86_64 supports float128 natively? |
| 22:13:52 | Araq | we also need a {.restrict: on.} pragma |
| 22:14:05 | Araq | and then pointers will be annotated with 'restrict' |
| 22:17:25 | Araq | though the compiler could do that by itself a bit |
| 22:17:31 | Araq | with my alias analysis |
| 22:20:33 | zahary | is there anything we can do that the underlying C compiler won't be able to notice? where do we have more information? I think they are doing alias analysis too to introduce "implicit restrict" in some situations |
| 22:31:52 | Araq | nimrod's notion of real arrays should help here |
| 22:32:17 | Araq | though I don't know if it's of any practical concern |
| 22:45:06 | Araq | yeah uint64 is no ordinal type, that solves quite some bugs :-) |
| 23:01:08 | Araq | good night |