5 ms·

> Maybe it is terrible for you... It is. I know of the examples you mention (and some of them like planning may not really involve much numerical work) but the

> Maybe it is terrible for you... It is. I know of the examples you mention (and some of them like planning may not really involve much numerical work) but the fact is that unless you're doing things by scratch (like starting from GEMM), numerical libraries are often badly documented, slow or otherwise incomplete (or a mixture thereof). You can disagree with me, but Tamas Papp who maintained a bunch CL libraries seems to have moved over to Julia entirely. > As for the "type system being weak", I meant weak in the sense that it's not very expressive, so as to allow better static type inference. I'm not saying CL should be static for "correctness" reasons, but for removing the user from having to have declarations all over the place. Let's reify. If I were to create a bunch of matrix classes (matrix-float, matrix-double, ignoring the lack of sugar), CL provides no way to declare a generic method 'mref' to be intelligent enough to know what the output will be, given the input type. Even getting the type in the compiler-macro is implementation dependent. In C++ this is extremely easy with templates, and in Haskell you do it via a type declaration (AFAIK). Yes, you can get around it via lots of macro magic, but this is so fundamental that you might as well create a new language (like Qi/Shen).

flavio81 9y ago
> Let's reify. If I were to create a bunch of matrix classes (matrix-float, matrix-double, ignoring the lack of sugar), CL provides no way to declare a generic method 'mref' to be intelligent enough to know what the output will be, given the input type. I am not sure if I follow you. If you have "matrix-float, matrix-double" you are perfectly able to define a "mref" generic method that acts smartly depending on the input type. This is one of the most basic features of the CLOS OOP system. Maybe there is something missing on your explanation?
wedesoft 9y ago
Have done exactly that using GOOPS which is Guile's equivalent of CLOS: scheme@(guile-user)> (use-modules (aiscm sequence) (aiscm element)) scheme@(guile-user)> (define a (arr (1 2 3) (4 5 6))) scheme@(guile-user)> (get a) $1 = #<sequence<sequence<int<8,unsigned>>>>: ((1 2 3) (4 5 6)) scheme@(guile-user)> (get a 1) $2 = #<sequence<int<8,unsigned>>>: (4 5 6) scheme@(guile-user)> (get a 0 1) $3 = 4 scheme@(guile-user)> (get (get a 1) 0) $4 = 4 That's the whole point of macros: To be able to create embedded domain specific (mini) languages. [1]: https://github.com/wedesoft/aiscm https://github.com/wedesoft/aiscm

flavio81 9y ago

> Let's reify. If I were to create a bunch of matrix classes (matrix-float, matrix-double, ignoring the lack of sugar), CL provides no way to declare a generic method 'mref' to be intelligent enough to know what the output will be, given the input type. I am not sure if I follow you. If you have "matrix-float, matrix-double" you are perfectly able to define a "mref" generic method that acts smartly depending on the input type. This is one of the most basic features of the CLOS OOP system. Maybe there is something missing on your explanation?

wedesoft 9y ago

Have done exactly that using GOOPS which is Guile's equivalent of CLOS: scheme@(guile-user)> (use-modules (aiscm sequence) (aiscm element)) scheme@(guile-user)> (define a (arr (1 2 3) (4 5 6))) scheme@(guile-user)> (get a) $1 = #<sequence<sequence<int<8,unsigned>>>>: ((1 2 3) (4 5 6)) scheme@(guile-user)> (get a 1) $2 = #<sequence<int<8,unsigned>>>: (4 5 6) scheme@(guile-user)> (get a 0 1) $3 = 4 scheme@(guile-user)> (get (get a 1) 0) $4 = 4 That's the whole point of macros: To be able to create embedded domain specific (mini) languages. [1]: https://github.com/wedesoft/aiscm https://github.com/wedesoft/aiscm