FAQ
Hello,

I've been working in Go for a few months now and have noticed one little
hitch that is a bit odd: The inability to write generic math functions like
Abs. It's a bit odd that the standard lib doesn't actually have integer
math operations.

Is there any reason why we couldn't do something like what Python does by
allowing + to parse to Add or something like that? This would let us have a
Num interface which could be used to write well behaved math functions and
make BigNums a bit less awkward to use.

Example:

func Abs(a Num) Num {
if a < 0 {
return a * -1
}
return a}


parses to

func Abs(a Num) Num {
if a.Less(0) {
return a.Mult(-1)
}
return a}



Are there horrible repercussions for the semantics of Go if this happened?

Please don't construe this as rantish, I'm just wondering if I'm
misunderstanding something about how this would impact 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Chris dollin at Feb 5, 2013 at 7:35 pm

    On 5 February 2013 19:30, Danny Gratzer wrote:
    Hello,

    I've been working in Go for a few months now and have noticed one little
    hitch that is a bit odd: The inability to write generic math functions like
    Abs. It's a bit odd that the standard lib doesn't actually have integer math
    operations.

    Is there any reason why we couldn't do something like what Python does by
    allowing + to parse to Add or something like that? This would let us have a
    Num interface which could be used to write well behaved math functions and
    make BigNums a bit less awkward to use.
    You are opening the Pandor's box of generics, about
    which many many words have been written on this mailing
    list. Summary of the summary of the summary:
    generics are hard, and no solution adequate to the
    demands of the Go implementors has yet been
    devised.

    Chris

    --
    Chris "allusive" Dollin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Scott Lawrence at Feb 5, 2013 at 7:36 pm
    IIRC, the main objection the go devs (and others) have to this is that it
    allows (bad) developers to create a situation where 'a+b' doesn't mean what
    you'd think, by overloading .Plus().
    On Tue, 5 Feb 2013, Danny Gratzer wrote:

    Hello,

    I've been working in Go for a few months now and have noticed one little
    hitch that is a bit odd: The inability to write generic math functions like
    Abs. It's a bit odd that the standard lib doesn't actually have integer
    math operations.

    Is there any reason why we couldn't do something like what Python does by
    allowing + to parse to Add or something like that? This would let us have a
    Num interface which could be used to write well behaved math functions and
    make BigNums a bit less awkward to use.

    Example:

    func Abs(a Num) Num {
    if a < 0 {
    return a * -1
    }
    return a}


    parses to

    func Abs(a Num) Num {
    if a.Less(0) {
    return a.Mult(-1)
    }
    return a}



    Are there horrible repercussions for the semantics of Go if this happened?

    Please don't construe this as rantish, I'm just wondering if I'm
    misunderstanding something about how this would impact 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Scott Lawrence

    go version go1.0.3
    Linux baidar 3.7.5-1-ARCH #1 SMP PREEMPT Mon Jan 28 10:03:32 CET 2013 x86_64 GNU/Linux

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Danny Gratzer at Feb 5, 2013 at 7:46 pm

    IIRC, the main objection the go devs (and others) have to this is that it
    allows (bad) developers to create a situation where 'a+b' doesn't mean
    what
    you'd think, by overloading .Plus().
    That seems like an odd excuse: it's the same as any other function, if it's
    named poorly then that falls on the shoulders of the developer. I don't see
    + as carrying any more implicit meaning then a function named DoX that
    instead does Y.

    But I understand, generics are difficult.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Feb 5, 2013 at 7:56 pm

    On Tue, Feb 5, 2013 at 8:45 PM, Danny Gratzer wrote:
    That seems like an odd excuse: it's the same as any other function, if it's
    named poorly then that falls on the shoulders of the developer. I don't see
    + as carrying any more implicit meaning then a function named DoX that
    instead does Y.
    Hidden and/or surprising costs are a concern IMO.

    When you see `DoX()`, you're well aware that if you don't (yet) know
    what 'DoX' does, than you cannot estimate its cost/performance.

    When you see `a+b`, you know, that there are no hidden costs above:
    integer/float add (small constant cost) or string concatenation
    (bigger, non constant cost). Introducing operator overloading voids
    such performance assumptions even for functions so common/frequent
    that many/most programming languages allow their invocation by writing
    operators instead of function calls.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 5, 2013 at 8:09 pm
    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can mean
    anything. It could load something from disk, or make a connection to some
    remote server. Or launch ICBMs.

    For a saner approach, see typeclasses:
    http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
    interface can do "==", and a type that implements the Ord interface can do
    ">"/"<", etc., and you can then simply have functions that take arguments
    of that interface type. To get the whole benefit, you would need to be able
    to make it a constraint instead of a concrete type, so you're able to both
    take and return a variable of type "a" which satisfies e.g. Eq or Ord. In
    Go you have to return some specific type and type-assert manually.) This is
    a big thing to do and has many problems. It's been discussed many times.
    Here's a summary of the predicament: http://research.swtch.com/generic

    On Tue, Feb 5, 2013 at 8:56 PM, Jan Mercl wrote:
    On Tue, Feb 5, 2013 at 8:45 PM, Danny Gratzer wrote:
    That seems like an odd excuse: it's the same as any other function, if it's
    named poorly then that falls on the shoulders of the developer. I don't see
    + as carrying any more implicit meaning then a function named DoX that
    instead does Y.
    Hidden and/or surprising costs are a concern IMO.

    When you see `DoX()`, you're well aware that if you don't (yet) know
    what 'DoX' does, than you cannot estimate its cost/performance.

    When you see `a+b`, you know, that there are no hidden costs above:
    integer/float add (small constant cost) or string concatenation
    (bigger, non constant cost). Introducing operator overloading voids
    such performance assumptions even for functions so common/frequent
    that many/most programming languages allow their invocation by writing
    operators instead of function calls.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Danny Gratzer at Feb 5, 2013 at 9:43 pm

    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can
    mean anything. It could load something from disk, or make a connection to
    some remote server. Or launch ICBMs.
    Agreed, there's a limit to how far you should go. But on the other hand
    it's a bit odd that we have to have either 4 differently named versions of
    a function or we have to explicitly cast every argument. Not to say that
    explicit casting is bad but there's a limit to how much boiler plate a
    programmer should have to write. (And if someone's code is launching ICBMs
    using the + operator I'm not sure I want to live on this planet any more).

    I'm not suggesting general operator overloading, I've spent long enough
    hacking C++ to see some horrible uses of it. I'm merely focused on why it
    seems there's no clean way (That I know of) to write simple operations for
    all numeric types.

    For a saner approach, see typeclasses:
    http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
    interface can do "==", and a type that implements the Ord interface can do
    ">"/"<", etc., and you can then simply have functions that take arguments
    of that interface type. To get the whole benefit, you would need to be able
    to make it a constraint instead of a concrete type, so you're able to both
    take and return a variable of type "a" which satisfies e.g. Eq or Ord. In
    Go you have to return some specific type and type-assert manually.) This is
    a big thing to do and has many problems. It's been discussed many times.
    Here's a summary of the predicament: http://research.swtch.com/generic
    I work mostly in Haskell now so I'm aware of typeclasses, and go interfaces
    are similar to an extent. The main problem is that Haskell is more than a
    little generous about what form your functions take (infix, prefix) and go
    isn't. And yes without some sort of Minler-Hindley type system typeclasses
    lose a lot of steam.

    So out of curiosity, are there any generics solutions which are favored by
    the Go community?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Feb 5, 2013 at 10:08 pm

    hacking C++ to see some horrible uses of it. I'm merely focused on why it
    seems there's no clean way (That I know of) to write simple operations for
    all numeric types.
    Because this would require Go to support function type inheritance and
    polymorphism. Why ? Because you need type inheritance to implement the
    concept of 'all numeric types', and polymorphism to be able to
    distinguish between the various numeric sub types and implement proper
    behavior like float64 = float64.

    This is why I believe generics can not be added to Go without
    affecting the fundamental design choices of the language.

    Dave

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Thomas Bushnell, BSG at Feb 5, 2013 at 10:38 pm
    I think you're only having this because you want to "write generic math
    functions like Abs".

    You're quite right; writing such functions in Go is not a sensible
    operation. At the same time, it's also not terribly useful *in practice. *In
    idiomatic Go, it doesn't come up much that you *need *such a function.

    Thomas

    On Tue, Feb 5, 2013 at 1:43 PM, Danny Gratzer wrote:


    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can
    mean anything. It could load something from disk, or make a connection to
    some remote server. Or launch ICBMs.
    Agreed, there's a limit to how far you should go. But on the other hand
    it's a bit odd that we have to have either 4 differently named versions of
    a function or we have to explicitly cast every argument. Not to say that
    explicit casting is bad but there's a limit to how much boiler plate a
    programmer should have to write. (And if someone's code is launching ICBMs
    using the + operator I'm not sure I want to live on this planet any more).

    I'm not suggesting general operator overloading, I've spent long enough
    hacking C++ to see some horrible uses of it. I'm merely focused on why it
    seems there's no clean way (That I know of) to write simple operations for
    all numeric types.

    For a saner approach, see typeclasses: http://en.**
    wikipedia.org/wiki/Type_class <http://en.wikipedia.org/wiki/Type_class>(a type which implements the Eq interface can do "==", and a type that
    implements the Ord interface can do ">"/"<", etc., and you can then simply
    have functions that take arguments of that interface type. To get the whole
    benefit, you would need to be able to make it a constraint instead of a
    concrete type, so you're able to both take and return a variable of type
    "a" which satisfies e.g. Eq or Ord. In Go you have to return some specific
    type and type-assert manually.) This is a big thing to do and has many
    problems. It's been discussed many times. Here's a summary of the
    predicament: http://research.**swtch.com/generic<http://research.swtch.com/generic>
    I work mostly in Haskell now so I'm aware of typeclasses, and go
    interfaces are similar to an extent. The main problem is that Haskell is
    more than a little generous about what form your functions take (infix,
    prefix) and go isn't. And yes without some sort of Minler-Hindley type
    system typeclasses lose a lot of steam.

    So out of curiosity, are there any generics solutions which are favored by
    the Go community?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Johnstone at Feb 6, 2013 at 2:44 pm
    It is not terribly useful in *your *practice, because of the types of
    applications that you write. It is not useful in *my* practice, mostly
    because I don't use Go for anything numeric. It is obviously an issue for
    the OP.

    On Tuesday, 5 February 2013 17:30:53 UTC-5, Thomas Bushnell, BSG wrote:

    You're quite right; writing such functions in Go is not a sensible
    operation. At the same time, it's also not terribly useful *in practice. *In
    idiomatic Go, it doesn't come up much that you *need *such a function.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 5, 2013 at 11:14 pm
    Isn't that just an efficient way of expressing the following?:

    deaths += city // Launch nuke.

    Sorry, obviously feeling dark today.

    Dan
    On Tue, 2013-02-05 at 13:43 -0800, Danny Gratzer wrote:
    And if someone's code is launching ICBMs
    using the + operator I'm not sure I want to live on this planet any
    more
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Johnstone at Feb 6, 2013 at 2:46 pm
    Comments like this always leads me to wonder, do programmers have a higher
    percentage of psychopaths than other professions? :)

    On Tuesday, 5 February 2013 18:14:54 UTC-5, kortschak wrote:

    Isn't that just an efficient way of expressing the following?:

    deaths += city // Launch nuke.

    Sorry, obviously feeling dark today.

    Dan
    On Tue, 2013-02-05 at 13:43 -0800, Danny Gratzer wrote:
    And if someone's code is launching ICBMs
    using the + operator I'm not sure I want to live on this planet any
    more
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 6, 2013 at 8:23 pm
    Dark humour is a way of coping with an otherwise unmanageable world. I pity those who come from cultures that frown on its use.


    On 07/02/2013, at 1:16 AM, "Robert Johnstone" wrote:

    Comments like this always leads me to wonder, do programmers have a higher percentage of psychopaths than other professions? :)


    On Tuesday, 5 February 2013 18:14:54 UTC-5, kortschak wrote:
    Isn't that just an efficient way of expressing the following?:

    deaths += city // Launch nuke.

    Sorry, obviously feeling dark today.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 5, 2013 at 11:28 pm
    if someone's code is launching ICBMs using the + operator I'm not sure I
    want to live on this planet any more

    I'm not sure you will be able to. + is a very common operation!

    I don't think there's a generally-agreed-upon approach to generics, or it
    probably would have been implemented already. Robert Griesemer floated that
    somebody had made some reasonable suggestions a while ago, but I'm not sure
    if that turned into anything. Personally, I think typeclasses and type
    inference just feel like a natural fit with what Go already has.

    On Tue, Feb 5, 2013 at 10:43 PM, Danny Gratzer wrote:


    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can
    mean anything. It could load something from disk, or make a connection to
    some remote server. Or launch ICBMs.
    Agreed, there's a limit to how far you should go. But on the other hand
    it's a bit odd that we have to have either 4 differently named versions of
    a function or we have to explicitly cast every argument. Not to say that
    explicit casting is bad but there's a limit to how much boiler plate a
    programmer should have to write. (And if someone's code is launching ICBMs
    using the + operator I'm not sure I want to live on this planet any more).

    I'm not suggesting general operator overloading, I've spent long enough
    hacking C++ to see some horrible uses of it. I'm merely focused on why it
    seems there's no clean way (That I know of) to write simple operations for
    all numeric types.

    For a saner approach, see typeclasses: http://en.**
    wikipedia.org/wiki/Type_class <http://en.wikipedia.org/wiki/Type_class>(a type which implements the Eq interface can do "==", and a type that
    implements the Ord interface can do ">"/"<", etc., and you can then simply
    have functions that take arguments of that interface type. To get the whole
    benefit, you would need to be able to make it a constraint instead of a
    concrete type, so you're able to both take and return a variable of type
    "a" which satisfies e.g. Eq or Ord. In Go you have to return some specific
    type and type-assert manually.) This is a big thing to do and has many
    problems. It's been discussed many times. Here's a summary of the
    predicament: http://research.**swtch.com/generic<http://research.swtch.com/generic>
    I work mostly in Haskell now so I'm aware of typeclasses, and go
    interfaces are similar to an extent. The main problem is that Haskell is
    more than a little generous about what form your functions take (infix,
    prefix) and go isn't. And yes without some sort of Minler-Hindley type
    system typeclasses lose a lot of steam.

    So out of curiosity, are there any generics solutions which are favored by
    the Go community?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Feb 6, 2013 at 1:14 am

    On Wed, Feb 6, 2013 at 7:28 AM, Patrick Mylund Nielsen wrote:

    if someone's code is launching ICBMs using the + operator I'm not sure I
    want to live on this planet any more

    I'm not sure you will be able to. + is a very common operation!

    I don't think there's a generally-agreed-upon approach to generics, or it
    probably would have been implemented already. Robert Griesemer floated that
    somebody had made some reasonable suggestions a while ago, but I'm not sure
    if that turned into anything.
    I'm very interested in this, any references or links?
    Personally, I think typeclasses and type inference just feel like a
    natural fit with what Go already has.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 6, 2013 at 1:21 am
    http://channel9.msdn.com/Blogs/Charles/Erik-Meijer-and-Robert-Griesemer-Goaround
    22:27. You probably won't be too satisfied since it is quite sparse
    on details ("we have an internal proposal, an implementation, and a couple
    of test programs.") Since there hasn't been much/any discussion of it, I
    assumed that it hasn't borne much fruit.

    On Wed, Feb 6, 2013 at 2:14 AM, minux wrote:


    On Wed, Feb 6, 2013 at 7:28 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    if someone's code is launching ICBMs using the + operator I'm not sure
    I want to live on this planet any more

    I'm not sure you will be able to. + is a very common operation!

    I don't think there's a generally-agreed-upon approach to generics, or it
    probably would have been implemented already. Robert Griesemer floated that
    somebody had made some reasonable suggestions a while ago, but I'm not sure
    if that turned into anything.
    I'm very interested in this, any references or links?
    Personally, I think typeclasses and type inference just feel like a
    natural fit with what Go already has.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sean Russell at Feb 6, 2013 at 5:54 pm

    On Tuesday, February 5, 2013 6:28:49 PM UTC-5, Patrick Mylund Nielsen wrote:
    I don't think there's a generally-agreed-upon approach to generics, or it
    probably would have been implemented already. Robert Griesemer floated that
    somebody had made some reasonable suggestions a while ago, but I'm not sure
    if that turned into anything. Personally, I think typeclasses and type
    inference just feel like a natural fit with what Go already has.
    Yeah, I've also had this observation. I'm not much into compiler theory,
    so I don't understand what's so radically different about type classes that
    they're hard to support in Go, but I don't think Go has to support type
    classes to support operator overloading. It would require a redefinition
    of how the compiler treats binary operators. I'm not even sure that it'd
    have a huge performance impact, if the compiler was smart about inlining
    functions.

    Just to be clear, I'm talking specifically about: "If a type A supports
    func (a A) Plus(A) A, then A3 = A1 + A2 is legal and will be converted at
    compile time to A3 = A1.Plus(A2)". For the primatives that already support
    +, the compiler would just use whatever asm logic it uses now, and no
    run-time performance penalty. There'd probably be a small compile-time hit.

    The argument against this that IMO has the most merit is the obfuscation
    factor. I think instinctively people understand tha a.Plus(b) could map to
    "rm -rf /", but I think all of that math training we've had since we were
    wee tots means "a + a" invokes more instinctive assumptions that make
    operator overloading inherently more risky.

    --- SER

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jonathan Amsterdam at Feb 6, 2013 at 8:03 pm

    Just to be clear, I'm talking specifically about: "If a type A supports
    func (a A) Plus(A) A, then A3 = A1 + A2 is legal and will be converted at
    compile time to A3 = A1.Plus(A2)". For the primatives that already support
    +, the compiler would just use whatever asm logic it uses now, and no
    run-time performance penalty. There'd probably be a small compile-time hit.
    Here's a technical problem with this idea that comes up with == (assuming
    the corresponding method is named Equal):

    type T struct { /* whatever */ }

    func (t1 *T) Equal(t2 *T) bool { ... }

    func f() {
    a := &T{}
    b := &T{}
    if a == b {...}
    }

    This is legal Go today, and means pointer identity. With your suggested
    feature, it changes meaning.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 6, 2013 at 8:28 pm
    There has been discussion many times about this in the past, dealing most often with the use of Go in numerical computing. One of the approaches that has been suggested (I think by Michael Jones) was a numerical dsl or Go-like language to Go compiler. While this complicates the build process I think it has a lot of merit.

    Dan
    On 07/02/2013, at 4:24 AM, "Sean Russell" wrote:

    Just to be clear, I'm talking specifically about: "If a type A supports func (a A) Plus(A) A, then A3 = A1 + A2 is legal and will be converted at compile time to A3 = A1.Plus(A2)". For the primatives that already support +, the compiler would just use whatever asm logic it uses now, and no run-time performance penalty. There'd probably be a small compile-time hit.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sebastien Binet at Feb 6, 2013 at 9:03 pm

    On Wed, Feb 6, 2013 at 9:28 PM, Dan Kortschak wrote:
    There has been discussion many times about this in the past, dealing most often with the use of Go in numerical computing. One of the approaches that has been suggested (I think by Michael Jones) was a numerical dsl or Go-like language to Go compiler. While this complicates the build process I think it has a lot of merit.
    only tangentially related:
    https://github.com/remyoudompheng/go-vectops

    -s
    Dan
    On 07/02/2013, at 4:24 AM, "Sean Russell" wrote:

    Just to be clear, I'm talking specifically about: "If a type A supports func (a A) Plus(A) A, then A3 = A1 + A2 is legal and will be converted at compile time to A3 = A1.Plus(A2)". For the primatives that already support +, the compiler would just use whatever asm logic it uses now, and no run-time performance penalty. There'd probably be a small compile-time hit.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Greg Ward at Feb 6, 2013 at 2:42 am

    On 05 February 2013, Patrick Mylund Nielsen said:
    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can mean
    anything. It could load something from disk, or make a connection to some
    remote server. Or launch ICBMs.

    For a saner approach, see typeclasses:
    http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
    interface can do "==", and a type that implements the Ord interface can do
    ">"/"<", etc., and you can then simply have functions that take arguments
    of that interface type.
    Neat! (...he says, brain exploding from reading about Haskell tricks
    without really knowing Haskell...) But I don't see how that saves you
    from insane implementations. It doesn't matter if a function is called
    Equal() or __eq__() or operator==(), I can always implement it stupidly:

    func (self MyStruct) Equal(other MyStruct) bool {
    return self.a == other.b && self.b != other.a
    }

    or insanely:

    func (self MyStruct) Equal(other MyStruct) bool {
    if rand.Float64() > 0.9 {
    nuclearwar.LaunchICBMs()
    }
    }

    If a language chooses to support operator overloading, it doesn't
    really matter how "obj1 == obj2" becomes a call to that method ... the
    language can't stop me from writing a crappy implementation. I suppose
    a pure functional language could stop me from having side effects
    (like nuclear war), but that's an edge case.

    Isn't it? Or is Haskell more stupendously powerful than I thought?
    (Although it seems unlikely that Go will wake up tomorrow with the
    ability to detect and prevent side-effect-ful functions...)

    Greg
    --
    Greg Ward http://www.gerg.ca
    <greg@gerg.ca> @gergdotca

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 6, 2013 at 2:50 am
    Sorry, I should have been clearer.

    Yes, it's true that Haskell wouldn't let you perform IO in e.g. (==) unless
    you use unsafePerformIO to do something outside the IO monad, but my main
    point was that in Haskell (and Go) it's trivial to inspect how a given type
    implements the Eq type class/"interface" -- in Python it's really hard to
    know: did you inherit from a class that override _getattr_/_setattr_, is
    your "dict" based on something that inherits from a class that inherits
    from a class that overrides how values are retrieved, ...?

    I don't mean to imply that == will absolutely do an equality check, just
    like implementing a Swap(i, j int) that deletes the items at those indices
    from your slice won't actually sort the items if you use sort.Sort. If you
    let somebody define what equality means for their own type, then you can't
    avoid that. But having the ability to do so is very useful.

    On Wed, Feb 6, 2013 at 3:42 AM, Greg Ward wrote:

    On 05 February 2013, Patrick Mylund Nielsen said:
    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can mean
    anything. It could load something from disk, or make a connection to some
    remote server. Or launch ICBMs.

    For a saner approach, see typeclasses:
    http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
    interface can do "==", and a type that implements the Ord interface can do
    ">"/"<", etc., and you can then simply have functions that take arguments
    of that interface type.
    Neat! (...he says, brain exploding from reading about Haskell tricks
    without really knowing Haskell...) But I don't see how that saves you
    from insane implementations. It doesn't matter if a function is called
    Equal() or __eq__() or operator==(), I can always implement it stupidly:

    func (self MyStruct) Equal(other MyStruct) bool {
    return self.a == other.b && self.b != other.a
    }

    or insanely:

    func (self MyStruct) Equal(other MyStruct) bool {
    if rand.Float64() > 0.9 {
    nuclearwar.LaunchICBMs()
    }
    }

    If a language chooses to support operator overloading, it doesn't
    really matter how "obj1 == obj2" becomes a call to that method ... the
    language can't stop me from writing a crappy implementation. I suppose
    a pure functional language could stop me from having side effects
    (like nuclear war), but that's an edge case.

    Isn't it? Or is Haskell more stupendously powerful than I thought?
    (Although it seems unlikely that Go will wake up tomorrow with the
    ability to detect and prevent side-effect-ful functions...)

    Greg
    --
    Greg Ward http://www.gerg.ca
    <greg@gerg.ca> @gergdotca
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 6, 2013 at 2:57 am
    Actually, let me change that: I don't think being able to change == is
    necessary, but being able to make a function that takes any type that does
    equality, or ordering, and using the respective interfaces' methods, is
    very useful. Go kind of has that, but you can't pass a slice of values of
    type a (which has a Less method) and return a sorted slice of values of
    type a, or give the caller a value of type a back from a map of strings to
    values of type a.

    On Wed, Feb 6, 2013 at 3:49 AM, Patrick Mylund Nielsen wrote:

    Sorry, I should have been clearer.

    Yes, it's true that Haskell wouldn't let you perform IO in e.g. (==)
    unless you use unsafePerformIO to do something outside the IO monad, but my
    main point was that in Haskell (and Go) it's trivial to inspect how a given
    type implements the Eq type class/"interface" -- in Python it's really hard
    to know: did you inherit from a class that override _getattr_/_setattr_, is
    your "dict" based on something that inherits from a class that inherits
    from a class that overrides how values are retrieved, ...?

    I don't mean to imply that == will absolutely do an equality check, just
    like implementing a Swap(i, j int) that deletes the items at those indices
    from your slice won't actually sort the items if you use sort.Sort. If you
    let somebody define what equality means for their own type, then you can't
    avoid that. But having the ability to do so is very useful.

    On Wed, Feb 6, 2013 at 3:42 AM, Greg Ward wrote:

    On 05 February 2013, Patrick Mylund Nielsen said:
    an example.. in Python, mydict["foo"], myobj.foo and myobj.foo = 3 can mean
    anything. It could load something from disk, or make a connection to some
    remote server. Or launch ICBMs.

    For a saner approach, see typeclasses:
    http://en.wikipedia.org/wiki/Type_class (a type which implements the Eq
    interface can do "==", and a type that implements the Ord interface can do
    ">"/"<", etc., and you can then simply have functions that take arguments
    of that interface type.
    Neat! (...he says, brain exploding from reading about Haskell tricks
    without really knowing Haskell...) But I don't see how that saves you
    from insane implementations. It doesn't matter if a function is called
    Equal() or __eq__() or operator==(), I can always implement it stupidly:

    func (self MyStruct) Equal(other MyStruct) bool {
    return self.a == other.b && self.b != other.a
    }

    or insanely:

    func (self MyStruct) Equal(other MyStruct) bool {
    if rand.Float64() > 0.9 {
    nuclearwar.LaunchICBMs()
    }
    }

    If a language chooses to support operator overloading, it doesn't
    really matter how "obj1 == obj2" becomes a call to that method ... the
    language can't stop me from writing a crappy implementation. I suppose
    a pure functional language could stop me from having side effects
    (like nuclear war), but that's an edge case.

    Isn't it? Or is Haskell more stupendously powerful than I thought?
    (Although it seems unlikely that Go will wake up tomorrow with the
    ability to detect and prevent side-effect-ful functions...)

    Greg
    --
    Greg Ward http://www.gerg.ca
    <greg@gerg.ca> @gergdotca
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Johnstone at Feb 6, 2013 at 2:39 pm
    This argument depends on the operators being a single global function, but
    they are not. The operators are in fact overloaded based on their
    arguments' type. As you've already mentioned, you cannot treat the
    performance implications of adding two integers the same adding two
    strings. The proposal would not allow the redefinition of existing
    operators, and so do nothing to modify the performance (or the analysis of
    performance) of existing operators. Concerns over existing behaviour are
    unfounded.

    With respect to the custom operators, the performance analysis of
    MyCustomNum(1).Add(MyCustomNum(2)) is no different than MyCustomNum(1) +
    MyCustomNum(2). As always, you obviously need to be aware of variables'
    types when reading code, because their type affects their behaviour. The
    behaviour of even a simple expression such as v1 + v2 depends on the type
    of v1 and v2 (even in Go, without operator overloading, this is still true).

    The real issue is the trade-off between language simplicity and the
    capacity to create abstractions. Go is relatively easy to learn because it
    is relatively simple. The language is safer, but it is less sharp.


    On Tuesday, 5 February 2013 14:56:10 UTC-5, Jan Mercl wrote:
    On Tue, Feb 5, 2013 at 8:45 PM, Danny Gratzer wrote:
    That seems like an odd excuse: it's the same as any other function, if it's
    named poorly then that falls on the shoulders of the developer. I don't see
    + as carrying any more implicit meaning then a function named DoX that
    instead does Y.
    Hidden and/or surprising costs are a concern IMO.

    When you see `DoX()`, you're well aware that if you don't (yet) know
    what 'DoX' does, than you cannot estimate its cost/performance.

    When you see `a+b`, you know, that there are no hidden costs above:
    integer/float add (small constant cost) or string concatenation
    (bigger, non constant cost). Introducing operator overloading voids
    such performance assumptions even for functions so common/frequent
    that many/most programming languages allow their invocation by writing
    operators instead of function calls.

    -j
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jonathan Amsterdam at Feb 6, 2013 at 4:00 pm

    On Wednesday, February 6, 2013 9:39:37 AM UTC-5, Robert Johnstone wrote:

    This argument depends on the operators being a single global function, but
    they are not. The operators are in fact overloaded based on their
    arguments' type. As you've already mentioned, you cannot treat the
    performance implications of adding two integers the same adding two
    strings. The proposal would not allow the redefinition of existing
    operators, and so do nothing to modify the performance (or the analysis of
    performance) of existing operators. Concerns over existing behaviour are
    unfounded.

    This form of argument is often used to justify adding features to
    programming languages. But just because a feature does not change the
    meaning of existing programs does not mean that feature has no conceptual
    cost. By adding possibilities, you increase the burden of understanding
    code -- even code that was written before the feature was added. The
    fallacy is from the statement "it would not modify the performance of
    existing operators" to "it would not modify *the analysis of* performance
    of existing operators". The former is true, the latter false, because to
    determine whether the mark "+" in the program text is an existing operator
    requires more work.

    With respect to the custom operators, the performance analysis of
    MyCustomNum(1).Add(MyCustomNum(2)) is no different than MyCustomNum(1) +
    MyCustomNum(2).
    As always, you obviously need to be aware of variables' types when reading
    code, because their type affects their behaviour. The behaviour of even a
    simple expression such as v1 + v2 depends on the type of v1 and v2 (even in
    Go, without operator overloading, this is still true).
    In Go, "+" can only mean addition or string concatenation. Yes, it's
    overloaded, but there are only two possibilities, both written down in the
    spec. With operator overloading, there are an unbounded number of
    possibilities I might have to consider, until I page in the definition of +
    for the operand types. That decreases readability. Of course, the same is
    true for Add, even in Go. But in Go, at least the operators are fixed by
    the language. To coin a phrase, a program's surface of polymorphism -- the
    amount of program text whose meaning can vary unboundedly by type -- is
    much less in Go than in, say, C++, where essentially everything can vary
    except "." and ";".

    The real issue is the trade-off between language simplicity and the
    capacity to create abstractions. Go is relatively easy to learn because it
    is relatively simple. The language is safer, but it is less sharp.
    Your ability to create abstractions is not reduced by the lack of operator
    overloading. Just your ability to express those abstractions in a
    particular notation.

    On Tuesday, 5 February 2013 14:56:10 UTC-5, Jan Mercl wrote:

    On Tue, Feb 5, 2013 at 8:45 PM, Danny Gratzer <danny....@gmail.com>
    wrote:
    That seems like an odd excuse: it's the same as any other function, if it's
    named poorly then that falls on the shoulders of the developer. I don't see
    + as carrying any more implicit meaning then a function named DoX that
    instead does Y.
    Hidden and/or surprising costs are a concern IMO.

    When you see `DoX()`, you're well aware that if you don't (yet) know
    what 'DoX' does, than you cannot estimate its cost/performance.

    When you see `a+b`, you know, that there are no hidden costs above:
    integer/float add (small constant cost) or string concatenation
    (bigger, non constant cost). Introducing operator overloading voids
    such performance assumptions even for functions so common/frequent
    that many/most programming languages allow their invocation by writing
    operators instead of function calls.

    -j
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Johnstone at Feb 6, 2013 at 5:23 pm

    On Wednesday, 6 February 2013 11:00:24 UTC-5, Jonathan Amsterdam wrote:
    This form of argument is often used to justify adding features to
    programming languages. But just because a feature does not change the
    meaning of existing programs does not mean that feature has no conceptual
    cost. By adding possibilities, you increase the burden of understanding
    code -- even code that was written before the feature was added. The
    fallacy is from the statement "it would not modify the performance of
    existing operators" to "it would not modify *the analysis of* performance
    of existing operators". The former is true, the latter false, because to
    determine whether the mark "+" in the program text is an existing operator
    requires more work.
    I partially agree. The language would be more complex, and so more
    difficult to understand. However, you've ignored more point below. A + on
    two integers will always have the same behaviour. Introducing operators
    for other types does not change that. Since you must always be aware of
    the types, your burden for understanding code using ints or strings does
    not change.

    In Go, "+" can only mean addition or string concatenation. Yes, it's
    overloaded, but there are only two possibilities, both written down in the
    spec. With operator overloading, there are an unbounded number of
    possibilities I might have to consider, until I page in the definition of +
    for the operand types. That decreases readability. Of course, the same is
    true for Add, even in Go. But in Go, at least the operators are fixed by
    the language. To coin a phrase, a program's surface of polymorphism -- the
    amount of program text whose meaning can vary unboundedly by type -- is
    much less in Go than in, say, C++, where essentially everything can vary
    except "." and ";".
    Again, the operations available (i.e. method, functions, operators) for an
    expression always depends on the type. You position is similar to saying
    that only two or three types can have the method String(), because
    otherwise knowing what method will be called in any given situation is too
    confusing. In practice, this is not the case. You know which method
    String() is called because you know which type is being used. For
    operators, it would be the same.

    Your ability to create abstractions is not reduced by the lack of operator
    overloading. Just your ability to express those abstractions in a
    particular notation.
    This is a fair point. The OP was suggesting essentially syntactic sugar,
    so clearly the same architecture is possible. However, as someone who has
    written a lot of numeric code, the readability win from custome operators
    is a very big win. It can be taken to far and abused, but it can also
    improve readability immensely when used appropriately.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jonathan Amsterdam at Feb 6, 2013 at 7:03 pm

    In Go, "+" can only mean addition or string concatenation. Yes, it's
    overloaded, but there are only two possibilities, both written down in the
    spec. With operator overloading, there are an unbounded number of
    possibilities I might have to consider, until I page in the definition of +
    for the operand types. That decreases readability. Of course, the same is
    true for Add, even in Go. But in Go, at least the operators are fixed by
    the language. To coin a phrase, a program's surface of polymorphism -- the
    amount of program text whose meaning can vary unboundedly by type -- is
    much less in Go than in, say, C++, where essentially everything can vary
    except "." and ";".
    Again, the operations available (i.e. method, functions, operators) for an
    expression always depends on the type. You position is similar to saying
    that only two or three types can have the method String(), because
    otherwise knowing what method will be called in any given situation is too
    confusing. In practice, this is not the case. You know which method
    String() is called because you know which type is being used. For
    operators, it would be the same.
    My position is that I'm willing to put up with the uncertainty for
    methods, but not for operators.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Collins at Feb 5, 2013 at 8:08 pm

    On Tuesday, February 5, 2013 1:45:47 PM UTC-6, Danny Gratzer wrote:

    That seems like an odd excuse: it's the same as any other function, if
    it's named poorly then that falls on the shoulders of the developer. I
    don't see + as carrying any more implicit meaning then a function named DoX
    that instead does Y.

    But I understand, generics are difficult.
    To me, it's more than just poor naming though. It opens the door for
    unanticipated and hidden issues and adds complexity and/or inability to
    effectively reason about the performance of the code.

    It also adds impetus to map a wide range of unrelated concepts onto a
    fairly small set of symbols such as +, -, *, << etc, just to achieve infix
    notation. For a perfect example of this, consider how C++ iostream
    overloads << and >>.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stefan Nilsson at Feb 6, 2013 at 11:45 am
    Overloading of method names or operators is a WIBNI, a
    Wouldn't-It-Be-Nice-If feature. It does simplify some code, but it also
    introduces a lot of complexity. One of the main attractions of Go is that
    it is a simple language. It's possible to know it all and there are very
    few corner cases and almost no parts of the language that are best avoided.
    The language specification is about 50 pages, including examples. Compare
    this to Java or C++. There might be one or two savants who actually know
    these languages, but I have still haven't come across anyone who could tell
    what the following single line of Java code does:

    System.out.println(null);

    Hint: think about method name overloading.
    Solution: http://www.nada.kth.se/~snilsson/print-null-java/

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Peter at Feb 6, 2013 at 2:58 pm
    As others have said, designing a generic language is easier said than done.

    Consider your Abs function's interaction with integer constants:

    var thousand int8 = Abs(-1e3)

    Would this compile? Overflow? Where would it overflow? In the call:

    x := -1e3; Abs(int8(x))
    Abs(24)
    24

    Or in the result:

    x := -1e3; Abs(x)
    Abs(-1e3)
    1000
    int8(1000)
    -24

    Eugh... and don't get me started on MinInt ! :)

    I realise you were talking generically (pun intended), but whatever generic
    solution Go gets (if at all), will have to deal with the rest of the
    language.
    On Tuesday, 5 February 2013 19:30:57 UTC, Danny Gratzer wrote:

    Hello,

    I've been working in Go for a few months now and have noticed one little
    hitch that is a bit odd: The inability to write generic math functions like
    Abs. It's a bit odd that the standard lib doesn't actually have integer
    math operations.

    Is there any reason why we couldn't do something like what Python does by
    allowing + to parse to Add or something like that? This would let us have a
    Num interface which could be used to write well behaved math functions and
    make BigNums a bit less awkward to use.

    Example:

    func Abs(a Num) Num {
    if a < 0 {
    return a * -1
    }
    return a}


    parses to

    func Abs(a Num) Num {
    if a.Less(0) {
    return a.Mult(-1)
    }
    return a}



    Are there horrible repercussions for the semantics of Go if this happened?

    Please don't construe this as rantish, I'm just wondering if I'm
    misunderstanding something about how this would impact 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Feb 6, 2013 at 10:49 pm
    I feel like operator overloading, for the 'hidden costs' listed elsewhere,
    is not a good fit for go. If go were a language where all operators were
    syntactic sugar for methods, and even the builtin types implemented those
    methods (so that the implementation was solidly consistent), it might be
    another matter, but that's not the case.

    Re: overloading and generics: overloading is only a small subset of
    generics, and I don't think we should be describing generics and
    overloading as being the same thing. Overloading could perhaps be done much
    more simply alone than what most discussions about "generics" in Go have
    centered around, yet most discussions have quickly come to the conclusion
    that overloading is not a part of generics that we, as a language
    community, feel will be a strong benefit. Given then, that overloading
    could be simpler than generics, yet we haven't seen the overwhelming value
    of their inclusion, it stands as two reasons against the proposal.

    "Generic" discussions, on the other hand, seem to focus on iteration, and
    allowing methods to accept the same type as the receiver (guaranteeing
    compile-time type equivalence) while still being able to implement the same
    interface as types with same-named methods that, in concrete terms, have a
    different function type signature. Neither of those scenarios are related
    to overloading.
    On Tuesday, February 5, 2013 12:30:57 PM UTC-7, Danny Gratzer wrote:

    Hello,

    I've been working in Go for a few months now and have noticed one little
    hitch that is a bit odd: The inability to write generic math functions like
    Abs. It's a bit odd that the standard lib doesn't actually have integer
    math operations.

    Is there any reason why we couldn't do something like what Python does by
    allowing + to parse to Add or something like that? This would let us have a
    Num interface which could be used to write well behaved math functions and
    make BigNums a bit less awkward to use.

    Example:

    func Abs(a Num) Num {
    if a < 0 {
    return a * -1
    }
    return a}


    parses to

    func Abs(a Num) Num {
    if a.Less(0) {
    return a.Mult(-1)
    }
    return a}



    Are there horrible repercussions for the semantics of Go if this happened?

    Please don't construe this as rantish, I'm just wondering if I'm
    misunderstanding something about how this would impact 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Feb 7, 2013 at 7:01 pm

    On 2/5/2013 11:30 AM, Danny Gratzer wrote:
    Hello,

    I've been working in Go for a few months now and have noticed one little
    hitch that is a bit odd: The inability to write generic math functions like
    Abs. It's a bit odd that the standard lib doesn't actually have integer
    math operations.

    Is there any reason why we couldn't do something like what Python does by
    allowing + to parse to Add or something like that?
    Even in Python, operator overloading doesn't work quite right.
    Mixed-mode operations don't necessarily do what you'd expect.

    Python overloads "+" for concatenation. This works
    for any sequence type, so [1,2] + [3,4] = [1,2,3,4]. But
    the array types in the NumPy package also define "+", with
    numeric semantics:

    array([1,2]) + array([3,4]) = array([4,6])).

    Conversions are allowed:
    array([1,2]) + [3,4] = array([4,6]))

    Python, remember, has duck typing, so if you pass
    a Python list to a function that expected a numPy array,
    or vice versa, you won't get a compile error. But you
    will not get the expected answer, either.

    In C++, it's worse. C++ has function overloading,
    templates, and automatic conversions. You can have hours of
    fun with operator overloading in C++. Visit "boost.org". Lots
    of fun templates to try to understand. You'll learn more
    about C++ overload resolution rules than you ever wanted
    to know. Here's one of the better writeups on this, by
    IBM:
    http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8l.doc%2Flanguage%2Fref%2Fcplr315.htm

    I've done heavy matrix programming in C++; I used to
    do physics engines for animation and games. I've written
    C++ libraries to help. While it's convenient to be able to
    multiply vectors and matrices, it's not a huge help to
    be able to write

    a * b

    instead of

    a.matmult(b)

    Saving a few characters in the code isn't worth the time
    spent trying to figure out what went wrong when something
    unexpected happens.

    Keep Go simple.

    John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stefan Nilsson at Feb 7, 2013 at 7:46 pm

    Keep Go simple.

    John Nagle
    Amen to that. If given only one slide to describe Go that would be my first
    bullet point; closely followed by "Good directors cut", "The proof is in
    the pudding", and "The devil is in the details".

    I remember James Gosling saying that there is a very narrow window in which
    to design a programming language. Early on, you don't have enough
    experience with the language to make informed design decisions and just a
    little bit later, when a lot of people have started to use the language,
    there is very little room for change. Go had a very long and fruitful
    design period and that's one of the major reasons it's so good. But that
    was yesterday. Now is the time to use the language, not the time to
    redesign it.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tim Harig at Feb 7, 2013 at 8:39 pm

    On Thu, Feb 07, 2013 at 11:00:54AM -0800, John Nagle wrote:
    C++ libraries to help. While it's convenient to be able to
    multiply vectors and matrices, it's not a huge help to
    be able to write

    a * b
    a.matmult(b)
    Which is fine if your formula is as simple as a*b. That is quite often not
    the case with numerical computing.
    Saving a few characters in the code isn't worth the time
    spent trying to figure out what went wrong when something
    unexpected happens.
    It isn't about saving characters, it is about making the formula look more
    like its mathematical notation. That makes it much more intuitive and easy
    to follow for those who are used to seeing equations on paper.

    I do like the DSL idea. One thing that has occurred to me is that it could
    be possible for godoc to parse a DSL into LaTeX which could be displayed as
    they would be written. This would help to alleviate some of the readability
    problems. Since the notation comes from the code itself, one could look at
    the LaTeX version and be sure that the actual code is correct.

    The trick would be that the DSL needs to be compiled along with the rest of
    the Go code. Having to interpret the DSL at runtime would be an efficiency
    issue.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Scott Pakin at Feb 7, 2013 at 9:58 pm

    On Thursday, February 7, 2013 1:39:24 PM UTC-7, Tim Harig wrote:

    It isn't about saving characters, it is about making the formula look more
    like its mathematical notation. That makes it much more intuitive and
    easy
    to follow for those who are used to seeing equations on paper.
    Hey, here's a crazy compromise idea: Go could allow operators to be used as
    method names but require that they be decorated in some fashion to
    distinguish them from built-in operators, for example surrounding them with
    backquotes (à la Haskell's "treat as infix" syntax). Thus, a `+` b `*` ccould be syntactic sugar for
    a.`+`(b.`*`(c)). This should give the best of both worlds: a visual
    distinction between built-in and user-defined operators combined with the
    ability to write more readable, math-like expressions.

    Oh, and for crazy compromise idea #2, backquotes (or whatever) could more
    generally be used, Haskell-like, to invoke a method of type func(T, T) Tusing infix notation. Hence, a
    `Myfunc` b would be syntactic sugar for a.Myfunc(b). The differences with
    crazy compromise idea #1 are that (1) it adds only a calling convention
    without changing how identifiers are lexed, and (2) all such invocations
    have equal precedence so one would have to parenthesize to control the
    order of operations: a `MyAdd` (b `MyMult` c). Note that these two ideas
    are orthogonal to each other.

    What do you guys think? Have I finally found a solution to the
    operator-overloading versus no-operator-overloading debate that makes
    everyone happy?

    — Scott

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Feb 7, 2013 at 10:28 pm

    On Thu, Feb 7, 2013 at 1:58 PM, Scott Pakin wrote:
    Hey, here's a crazy compromise idea: Go could allow operators to be used as
    method names but require that they be decorated in some fashion to
    distinguish them from built-in operators, for example surrounding them with
    backquotes (à la Haskell's "treat as infix" syntax). Thus, a `+` b `*` c
    could be syntactic sugar for a.`+`(b.`*`(c)). This should give the best of
    both worlds: a visual distinction between built-in and user-defined
    operators combined with the ability to write more readable, math-like
    expressions.

    Oh, and for crazy compromise idea #2, backquotes (or whatever) could more
    generally be used, Haskell-like, to invoke a method of type func(T, T) T
    using infix notation. Hence, a `Myfunc` b would be syntactic sugar for
    a.Myfunc(b). The differences with crazy compromise idea #1 are that (1) it
    adds only a calling convention without changing how identifiers are lexed,
    and (2) all such invocations have equal precedence so one would have to
    parenthesize to control the order of operations: a `MyAdd` (b `MyMult` c).
    Note that these two ideas are orthogonal to each other.

    What do you guys think? Have I finally found a solution to the
    operator-overloading versus no-operator-overloading debate that makes
    everyone happy?
    I'm not crazy about the backquotes, but I think your first idea shows promise.

    To be clear, nothing in this area is going to change any time soon.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Glenn Brown at Feb 7, 2013 at 10:48 pm
    With Go as-is, you can print abstract functions like this: http://play.golang.org/p/tcQ6QWB_4h
    While this doesn't give WYSIWIG code, it can give WYSIWYG unit tests like this:

    // Output: ((a+b)*(c/d))
    func TestF(t *testing.T) {
    a, b, c, d := PrintVar("a"), PrintVar("b"), PrintVar("c"), PrintVar("d")
    fmt.Println(F(a, b, c, d))
    }

    FWIW,
    --Glenn

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tim Harig at Feb 8, 2013 at 2:26 am

    On Thu, Feb 07, 2013 at 01:58:19PM -0800, Scott Pakin wrote:
    On Thursday, February 7, 2013 1:39:24 PM UTC-7, Tim Harig wrote:

    It isn't about saving characters, it is about making the formula look more
    like its mathematical notation. That makes it much more intuitive and
    easy
    to follow for those who are used to seeing equations on paper.
    Hey, here's a crazy compromise idea: Go could allow operators to be used as
    method names but require that they be decorated in some fashion to
    distinguish them from built-in operators, for example surrounding them with
    So long as the decorations are chosen to be as unobtrusive as possible, I
    could see something like that.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Feb 9, 2013 at 4:50 am
    First off, I think that's the most reasonable proposal for operator
    overloading that I've seen in go, since it doesn't conflict with things
    like sort.Interface's Less method, and the overloaded cases would "stand
    out", thus somewhat mitigating the "hidden costs" counter-argument. That
    said, I probably would avoid using them on principle, even if added to the
    language, and I do see some potential problems that would need to be
    accounted for or explained away before the proposal would be consistent
    enough to be a candidate feature:

    How would order of operations be addressed? Somebody somewhere is going to
    complain that, in their particular case, + should have a higher precedence
    than *, and since anyone would be able to dispense with sanity anyway (by
    having side effects and un-math-like semantics), it'd be hard to argue that
    their desire is wrong.

    Also, some would desire for any number of consecutive, equivalent,
    applications of an operator, to result in a single invocation.

    For example, `func(T, ...T) T` instead of `func(T, T) T` -- i.e. `t1 + t2 +
    t3` being sugar for t1.`+`(t2, t3)

    (an aside: I agree with Ian about the backticks if only because it makes
    this syntax difficult to explain conventionally).

    This would be important for efficiency if anyone wanted to overload
    operators for set logic (when it is generally more efficient to iterate
    over smaller sets when performing an intersection). Conceivably people
    would also want this capability anyway, "just because", since the door
    already would've been opened to potentially insensible behavior.

    Also, how would you handle unary operators? `^` as a unary vs `^` as a
    binary operator, as well as `+`, `-`, and `<-` ? `&` (address of) and `*`
    (deference) would be a bit absurd, but there wouldn't be any consistent
    justification in preventing use of those.

    If `!` were allowed as a unary method, or `==` as a binary method, would
    they be required to return a bool, or could they return T? If they returned
    a bool, it would be argued that the mechanism should evolve beyond
    syntactic sugar, and that anything implementing `!` be allowed in any
    boolean context. For example:

    type Boolish struct {}
    func (b Boolish) `!`() bool { return true }
    if Boolish{} { /* do something */ }

    If that were allowed, then it would certainly mean that at least one
    predefined interface (the "Banger" interface?) would end up in the language
    spec itself, and it'd then be a bit hypocritical to keep out standard
    iterator interfaces (special cased by range loops), and to some extent,
    making the functionality in strings proper methods on the builtin string,
    etc.
    On Thursday, February 7, 2013 2:58:19 PM UTC-7, Scott Pakin wrote:
    On Thursday, February 7, 2013 1:39:24 PM UTC-7, Tim Harig wrote:

    It isn't about saving characters, it is about making the formula look
    more
    like its mathematical notation. That makes it much more intuitive and
    easy
    to follow for those who are used to seeing equations on paper.
    Hey, here's a crazy compromise idea: Go could allow operators to be used
    as method names but require that they be decorated in some fashion to
    distinguish them from built-in operators, for example surrounding them with
    backquotes (à la Haskell's "treat as infix" syntax). Thus, a `+` b `*` ccould be syntactic sugar for
    a.`+`(b.`*`(c)). This should give the best of both worlds: a visual
    distinction between built-in and user-defined operators combined with the
    ability to write more readable, math-like expressions.

    Oh, and for crazy compromise idea #2, backquotes (or whatever) could more
    generally be used, Haskell-like, to invoke a method of type func(T, T) Tusing infix notation. Hence, a
    `Myfunc` b would be syntactic sugar for a.Myfunc(b). The differences
    with crazy compromise idea #1 are that (1) it adds only a calling
    convention without changing how identifiers are lexed, and (2) all such
    invocations have equal precedence so one would have to parenthesize to
    control the order of operations: a `MyAdd` (b `MyMult` c). Note that
    these two ideas are orthogonal to each other.

    What do you guys think? Have I finally found a solution to the
    operator-overloading versus no-operator-overloading debate that makes
    everyone happy?

    — Scott
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Feb 8, 2013 at 9:11 am
    I don't necessarily have a problem with that proposal, so long as `+`
    converts to a normal plus for the built in types. For the stuff I do, being
    able to write code that naturally works for a float input, a complex input,
    and a custom input would be a huge win. Something that's more go like would
    be http://play.golang.org/p/AnYm0xxqx_ , where a couple of specific
    interfaces are provided that allow generics, and the built in types satisfy
    those definitions by definition. The problem is knowing what set of
    interfaces need to be provided. Would Add, Subtract, Multiply, Divide,
    Pow, CastFloat be enough? Most math functions can be defined by those
    operations. Since they would be specifically defined, for example, Add
    would take a type T and return a type T, they would be less prone to abuse
    (though not immune).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Feb 8, 2013 at 2:14 pm
    Would you really want CastFloat? and what's to then stop someone from
    proposing a more fine-grained set of special methods that include
    CastFloat32 and CastFloat64? Also, an important property that CastFloat (or
    any Cast* name) has is that, unlike the back-tick proposal, suddenly we'd
    be conferring special behavior to names that have always been valid Go
    method names.

    What benefit would come from requiring `+` to transparently work for
    builtin types? It would require the parser to be more complex (instead of
    potentially just syntactic sugar, it would now require a type determination
    and interface implementation check first), and people would waste
    keystrokes on making the code non-obvious. Because of the parse
    requirement, gofmt wouldn't be able to strip the quotes, and readers would
    be confused, looking for a `+` method implementation when none exist for
    that type. I personally believe that if the programmer cannot manage to
    write + for the non-overloaded behavior, and `+` for the overloaded
    behavior, then at the very least, they cannot be trusted to properly
    document their code since the readability of such code would be
    comparatively nil.
    On Friday, February 8, 2013 2:06:11 AM UTC-7, Brendan Tracey wrote:

    I don't necessarily have a problem with that proposal, so long as `+`
    converts to a normal plus for the built in types. For the stuff I do, being
    able to write code that naturally works for a float input, a complex input,
    and a custom input would be a huge win. Something that's more go like would
    be http://play.golang.org/p/AnYm0xxqx_ , where a couple of specific
    interfaces are provided that allow generics, and the built in types satisfy
    those definitions by definition. The problem is knowing what set of
    interfaces need to be provided. Would Add, Subtract, Multiply, Divide,
    Pow, CastFloat be enough? Most math functions can be defined by those
    operations. Since they would be specifically defined, for example, Add
    would take a type T and return a type T, they would be less prone to abuse
    (though not immune).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Feb 9, 2013 at 2:13 am
    CastFloat is probably the wrong name, maybe it's CastConstNum. Perhaps I
    haven't thought hard enough, but I don't know how you would write the
    "addOne" function in the code sample I linked if you don't have some way of
    converting numeric constants into your custom type. I don't understand your
    objections to it as far as special behavior. For any type it would still
    be a valid method. It would be a method on a type Foo that takes in a
    float64 and returns a type Foo. There is no special behavior there at all.
    The special behavior is that Foo satisfies the interface
    gennum.CastConstNumer, where normally one cannot write an interface like
    that as you can't specify a function that returns a generic type.

    The original poster was talking about the ability to write generic math
    functions like abs, presumably to work on float32, float64, complex128,
    etc. How would that work if '+' doesn't apply to built-in types? You'd
    suggest that the programmer has to write his own wrappers around all the
    basic types so they can use the abs programmed with `+`?


    On Friday, February 8, 2013 5:48:35 AM UTC-8, Kevin Gillette wrote:

    Would you really want CastFloat? and what's to then stop someone from
    proposing a more fine-grained set of special methods that include
    CastFloat32 and CastFloat64? Also, an important property that CastFloat (or
    any Cast* name) has is that, unlike the back-tick proposal, suddenly we'd
    be conferring special behavior to names that have always been valid Go
    method names.

    What benefit would come from requiring `+` to transparently work for
    builtin types? It would require the parser to be more complex (instead of
    potentially just syntactic sugar, it would now require a type determination
    and interface implementation check first), and people would waste
    keystrokes on making the code non-obvious. Because of the parse
    requirement, gofmt wouldn't be able to strip the quotes, and readers would
    be confused, looking for a `+` method implementation when none exist for
    that type. I personally believe that if the programmer cannot manage to
    write + for the non-overloaded behavior, and `+` for the overloaded
    behavior, then at the very least, they cannot be trusted to properly
    document their code since the readability of such code would be
    comparatively nil.
    On Friday, February 8, 2013 2:06:11 AM UTC-7, Brendan Tracey wrote:

    I don't necessarily have a problem with that proposal, so long as `+`
    converts to a normal plus for the built in types. For the stuff I do, being
    able to write code that naturally works for a float input, a complex input,
    and a custom input would be a huge win. Something that's more go like would
    be http://play.golang.org/p/AnYm0xxqx_ , where a couple of specific
    interfaces are provided that allow generics, and the built in types satisfy
    those definitions by definition. The problem is knowing what set of
    interfaces need to be provided. Would Add, Subtract, Multiply, Divide,
    Pow, CastFloat be enough? Most math functions can be defined by those
    operations. Since they would be specifically defined, for example, Add
    would take a type T and return a type T, they would be less prone to abuse
    (though not immune).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Feb 9, 2013 at 2:02 am
    I was actually suggesting that, for consistency sake, such casting methods
    _should_ have special names, just as Scott suggested that the name for a
    plus overloaded method actually take on a special syntax which cannot be
    used by normal method names. That way, you don't run the risk of a clash
    between existing methods/interfaces, and overloading (of which I'd consider
    conversions to be the case). Given that Go properly calls the equivalent of
    non-pointer C casts "conversions", a non-special method name would probably
    be called something like ConvFloat64. However, I actually seriously have
    had methods called ConvFloat, so I do know that there's a real possibility
    of a naming conflict unless 'special names' (which would not be
    syntactically valid in Go 1) are used.

    I don't think there's any great need to have a conversion func that
    specifically accepts a float64 parameter, since type assertions already
    cover that need -- when converting from a builtin type to T, you'd only
    need a single method, which takes interface{}, and uses type assertions or
    reflection to initialize and return a T value.

    I see what you mean with respect to generics. I'd be worried that newcomers
    to Go might read something about the generics aspect, and end up using `+`
    even in places where they should be using +. They might not correct their
    code because they can get away with it. Perhaps compiler enforcement could
    mitigate this, such that `+` could not be used in a context where the
    operands are concretely defined? I'd still rather that builtin types never,
    ever, have methods, and that some kind of code-generation is somehow used
    instead to handle the builtins (or invisible runtime functions that cannot
    be directly called without unsafe/reflect). This could be done, since
    overloaded methods would have special names anyway, and thus could be
    special cased. I'm not even convinced that we should allow these overloaded
    methods to be specified in interfaces, since doing so would add more
    runtime flexibility, thus once again making any kind of generics once again
    harder to accommodate -- the quickest way to get any kind of generics
    (especially without completely destabilizing the rest of the language)
    would be to apply them only to a small, special set of circumstances.
    On Friday, February 8, 2013 10:02:51 AM UTC-7, Brendan Tracey wrote:

    CastFloat is probably the wrong name, maybe it's CastConstNum. Perhaps I
    haven't thought hard enough, but I don't know how you would write the
    "addOne" function in the code sample I linked if you don't have some way of
    converting numeric constants into your custom type. I don't understand your
    objections to it as far as special behavior. For any type it would still
    be a valid method. It would be a method on a type Foo that takes in a
    float64 and returns a type Foo. There is no special behavior there at all.
    The special behavior is that Foo satisfies the interface
    gennum.CastConstNumer, where normally one cannot write an interface like
    that as you can't specify a function that returns a generic type.

    The original poster was talking about the ability to write generic math
    functions like abs, presumably to work on float32, float64, complex128,
    etc. How would that work if '+' doesn't apply to built-in types? You'd
    suggest that the programmer has to write his own wrappers around all the
    basic types so they can use the abs programmed with `+`?


    On Friday, February 8, 2013 5:48:35 AM UTC-8, Kevin Gillette wrote:

    Would you really want CastFloat? and what's to then stop someone from
    proposing a more fine-grained set of special methods that include
    CastFloat32 and CastFloat64? Also, an important property that CastFloat (or
    any Cast* name) has is that, unlike the back-tick proposal, suddenly we'd
    be conferring special behavior to names that have always been valid Go
    method names.

    What benefit would come from requiring `+` to transparently work for
    builtin types? It would require the parser to be more complex (instead of
    potentially just syntactic sugar, it would now require a type determination
    and interface implementation check first), and people would waste
    keystrokes on making the code non-obvious. Because of the parse
    requirement, gofmt wouldn't be able to strip the quotes, and readers would
    be confused, looking for a `+` method implementation when none exist for
    that type. I personally believe that if the programmer cannot manage to
    write + for the non-overloaded behavior, and `+` for the overloaded
    behavior, then at the very least, they cannot be trusted to properly
    document their code since the readability of such code would be
    comparatively nil.
    On Friday, February 8, 2013 2:06:11 AM UTC-7, Brendan Tracey wrote:

    I don't necessarily have a problem with that proposal, so long as `+`
    converts to a normal plus for the built in types. For the stuff I do, being
    able to write code that naturally works for a float input, a complex input,
    and a custom input would be a huge win. Something that's more go like would
    be http://play.golang.org/p/AnYm0xxqx_ , where a couple of specific
    interfaces are provided that allow generics, and the built in types satisfy
    those definitions by definition. The problem is knowing what set of
    interfaces need to be provided. Would Add, Subtract, Multiply, Divide,
    Pow, CastFloat be enough? Most math functions can be defined by those
    operations. Since they would be specifically defined, for example, Add
    would take a type T and return a type T, they would be less prone to abuse
    (though not immune).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andy Balholm at Feb 7, 2013 at 11:07 pm

    I do like the DSL idea. One thing that has occurred to me is that it
    could
    be possible for godoc to parse a DSL into LaTeX which could be displayed
    as
    they would be written. This would help to alleviate some of the
    readability
    problems. Since the notation comes from the code itself, one could look
    at
    the LaTeX version and be sure that the actual code is correct.

    The trick would be that the DSL needs to be compiled along with the rest
    of
    the Go code. Having to interpret the DSL at runtime would be an
    efficiency
    issue.
    Maybe this is something that could be implemented as an extension to GOWEB
    (the literate programming tool).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Feb 8, 2013 at 11:52 pm

    On 2/7/2013 12:39 PM, Tim Harig wrote:
    On Thu, Feb 07, 2013 at 11:00:54AM -0800, John Nagle wrote:
    C++ libraries to help. While it's convenient to be able to
    multiply vectors and matrices, it's not a huge help to
    be able to write

    a * b
    a.matmult(b)
    Which is fine if your formula is as simple as a*b. That is quite often not
    the case with numerical computing.
    Saving a few characters in the code isn't worth the time
    spent trying to figure out what went wrong when something
    unexpected happens.
    It isn't about saving characters, it is about making the formula look more
    like its mathematical notation. That makes it much more intuitive and easy
    to follow for those who are used to seeing equations on paper.
    That's not necessarily a feature. Mathematical notation in advanced
    mathematics tends to have implicit conventions which make it hard to
    parse. The machine learning community uses superscripts for both
    exponents and indices in the same equations. Mathematicians introduce
    newly defined operators without specifying their precedence. You're
    just supposed to know.

    Mathematica has a formal way of dealing with this. Their solution
    is to use a rather bulky, but unambiguous, notation. Matlab doesn't
    get fancy in this area, either.

    Sometimes it's easier to read the Matlab than the blackboard.

    John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Asmuth at Feb 9, 2013 at 12:04 am

    On Friday, February 8, 2013 2:55:57 PM UTC-5, John Nagle wrote:
    The machine learning community uses superscripts for both
    exponents and indices in the same equations.
    To be fair, it's hard to raise a vector to a power, and it's hard to index
    into a scalar :)

    (I agree with you)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Feb 9, 2013 at 1:44 am
    Have a look at BLAS or LAPACK client code. I don't think this is true - the two domains are quite different, one is trying to concisely explain the principles of the idea without reference to concrete implementation, the other focuses intimately on those details and except in trivial cases you would not want it to do otherwise.
    On 08/02/2013, at 7:09 AM, "Tim Harig" wrote:

    It isn't about saving characters, it is about making the formula look more
    like its mathematical notation. That makes it much more intuitive and easy
    to follow for those who are used to seeing equations on paper.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase