<<02-07-2012>>

21:33:31*NimBot joined #nimrod
21:36:59Araqso it's basically "errors in instantiation is no compile time error"?
21:37:49zaharychecking 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:49zaharyyes, it's similar to CFINAE (compilation-failure-is-not...)
21:39:36zaharyalso, 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:09Araqwell I'm not to keen on my "with" ideas
21:41:23Araqwe should strive for type macros instead
21:42:12Araqand try to use less and less built-in facilities for types
21:43:25zaharyby type macros do you mean "compile time procs for checking requirements" or "compile time procs that generate types" ?
21:46:12Araqboth
21:46:27Araq"low level type API to be done with it"
21:48:45Araqnext topic:
21:48:54Araqthe compiler has a hard time with uint64
21:49:10Araqas we can't do firstOrd(t) etc. with it properly
21:50:00Araqmost other compilers use bignums internally for these reasons
21:50:22Araqand it was another reason for me to leave out unsigned types
21:50:38zaharyah, 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:36Araqyeah but uintValue is too much work
21:51:51Araqand the resulting if explosion is horrible
21:52:36Araqand we don't have a bignum library to use
21:52:53Araqplus I don't really like the compiler to use bignums internally everywhere
21:53:03Araqas I have no idea how that would affect compile times
21:53:07Araqor memory usage
21:55:49zaharythere are some fixed width bignum libraries for C++ that would be cheper to use
21:56:38zaharybut still, uintValue should be the most efficient solution
21:58:39zaharyhttp://www.ttmath.org/
22:01:17Araqwell I'm thinking about not supporting uint64 instead :-)
22:02:12Araqnobody cares if the max value can be 2^63-1 or 2^64-1
22:02:59zaharyit certainly is a low priority, but we should fix it eventually
22:04:24Araqgod I'm glad unsigned floats don't exist :-)
22:05:04Araqit's so rude to be 1-dimensional :D
22:05:58Araqor maybe I make lastOrd et. al. for uint64 internal errors for now
22:07:07Araqiirc 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:47zaharywhat is float128 btw?
22:09:47zaharywe should add some support for the SSE intrinsics (we need just another c2nim import module)
22:09:47zaharyhttp://msdn.microsoft.com/en-us/library/01fth20w%28v=vs.71%29.aspx
22:12:48zaharythis header is available in all modern compilers
22:12:48zaharyhttp://clang.llvm.org/doxygen/emmintrin_8h_source.html
22:13:13Araqyes we need it
22:13:31Araqafaik x86_64 supports float128 natively?
22:13:52Araqwe also need a {.restrict: on.} pragma
22:14:05Araqand then pointers will be annotated with 'restrict'
22:17:25Araqthough the compiler could do that by itself a bit
22:17:31Araqwith my alias analysis
22:20:33zaharyis 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:52Araqnimrod's notion of real arrays should help here
22:32:17Araqthough I don't know if it's of any practical concern
22:45:06Araqyeah uint64 is no ordinal type, that solves quite some bugs :-)
23:01:08Araqgood night