The wonderful history of symbolic algebra at IBM (Scratchpad, Scratchpad II)
resulted in a third system, Axiom, that has always seemed to me a bright lesson
in types. It boldly goes into the topic with rigor, using category theory to
decide what relationships make sense and what the nature of a tensor cross
product of types truly is.
A key part of that is the notion of more general and more specific types. This
makes it possible to define a function that needs arguments supporting a less
than order relationship so it could be applied to integer and real arguments,
but not to complex numbers. This is just the mechanism that makes a generic
Max() easy to create. Imagine a definition like:
func {T type, where a,b ∈T allows a<b} Max(a, b T) T {
if a < b {
return b
}
return a
}
This is a nice way to answer the riddle and it is just what Axiom supports (but
expresses differently).
http://axiom-developer.org/axiom-website/bookvol2.pdf
<http://axiom-developer.org/axiom-website/bookvol2.pdf>
Michael Jones
michael.jo...@gmail.com
> On Jun 22, 2016, at 6:10 PM, 'Thomas Bushnell, BSG' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
>
> Really? How would you implement math.Max with generics?
>
> Thomas
>
> On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov <vkojouha...@gmail.com
> <mailto:vkojouha...@gmail.com>> wrote:
> https://golang.org/pkg/math/ <https://golang.org/pkg/math/> and
> https://golang.org/pkg/container/ <https://golang.org/pkg/container/> are
> just two stdlib packages that would greatly benefit from some kind of
> generics. I'm pretty sure there are more packages in the stdlib that would be
> greatly improved. And that's just the standard library.
>
>
> On Tuesday, June 21, 2016 at 5:29:37 PM UTC+3, Henry wrote:
> You still haven't provided any argument why generics is indispensable.
> The reason why I am no longer sure about my position in this issue is because
> -while I agree that generics is useful- I don't think that generics is
> essential. In fact, all of C++ features are useful and implemented in a very
> efficient manner, but take a look what happened when you slab that many
> features together. If you can do away with less, I think you should go for
> less. The trouble is deprecating language features is a lot harder than
> deprecating APIs in the standard library, while programming fads come and go.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
