What I was suggesting was a far narrower scope. I can see how go’s error
handling makes writing composable math functions more difficult (although I
would think these would panic not return an error - so then it is trivial).
If they do need to return errors then using a DSL for the equations and go
generate you don’t really care how much boilerplate code there is - you don’t
read or edit it.
> On Jun 18, 2023, at 3:10 PM, Jan Pfeifer <pfei...@gmail.com> wrote:
>
>
> A DSL + code generator is a longer discussion. But I'm not sure I'm getting
> the scope of your suggestion right:
>
> If you refer to having a full ML language DSL and a
> generator/AOT(ahead-of-time) compiler: folks have tried it before -- see the
> Swift ML effort by Chris Lattner, now leading Mojo in Modular AI. I don't
> know the detailed story there, but I thought hard about this (having a
> separate ML language and generator) before I started the GoMLX project. But
> from what I can imagine some of the shapes (and hyperparameters) that need
> checking often are only known at runtime. Also for development and debugging
> it complicates things: it's super nice to have a full language (Go) in
> parallel to constructing the graph.
>
> If you are referring to a DSL and code generator for error handling only: I'm
> not sure it would work well because it requires an extra step when developing
> ... it is just not as convenient / portable -- for instance for IDEs; also
> I'm often coding in a Jupyter Notebook using GoNB, which would also need
> modifications. Better if there was some form of support for the language. I'm
> hoping some error handling proposal would cover this use case.
>
>
> On Sun, Jun 18, 2023 at 5:11 PM Robert Engels <reng...@ix.netcom.com> wrote:
>> Seems the easiest way to address that is with a DSL and a code generator.
>>
>>> On Jun 18, 2023, at 9:47 AM, Jan Pfeifer <pfei...@gmail.com> wrote:
>>>
>>>
>>> hi Shulhan, I see your points, thanks for the reply. Let me comment on them
>>> below:
>>>
>>> On Sat, Jun 17, 2023 at 9:21 AM Shulhan <m.shul...@gmail.com> wrote:
>>>> Hi Jan, thanks for response.
>>>>
>>>> On Mon, 5 Jun 2023 01:06:37 -0700 (PDT)
>>>> Jan <pfei...@gmail.com> wrote:
>>>>
>>>> > Repeating Justin's consideration: one of my (and from colleagues I
>>>> > discuss the topic with) major issues with current error handling is
>>>> > the repetition of identical code. Your proposal still requires `when
>>>> > err handle ...` at every statement.
>>>>
>>>> Yes, correct.
>>>> The idea is not to minimise repetition on error handling statement, the
>>>> "if err != nil", but to minimise repetitive error handling body by
>>>> grouping it into single handle based on the context of error.
>>>
>>> Oh, I see. I have to say I wish one didn't need to do the `if err != nil`
>>> all the time either, when the handling is the same :) But if that is your
>>> proposal it makes sense.
>>>
>>>> > It also doesn't allow for nested
>>>> > call of functions that return errors -- e.g: `f(g(h(x)))`, where `h`,
>>>> > `g`, and `f` can return errors (all presumably handled the same way).
>>>> >
>>>>
>>>> I am not sure I understand this, but should not each function handle it
>>>> on its own?
>>>> Or should not `f` being called if `g` return an error?
>>>> If its later, yes, it does not allow for nested handling of error.
>>>
>>> Sorry I was not clear. What I mean is, with current error handling would be
>>> written like:
>>>
>>> hValue, err := h(x)
>>> if err != nil {...}
>>> gValue, err := g(hValue)
>>> if err != nil {...}
>>> fValue, err := f(gValue)
>>> if err != nil {...}
>>>
>>> Where all of the `if err` are identical.
>>>
>>> Let me provide a more concrete example: I'm working on an ML framework
>>> (github.com/gomlx/gomlx), and I'm writing computational graphs (that get
>>> just-in-time compiled for speed/GPU support) like:
>>>
>>> func EuclideanDistance(x, y *Node) *Node {
>>> return Sqrt(ReduceAllSum(Square(Sub(x, y))))
>>> }
>>>
>>> Where each of these functions could return an error (if shapes are
>>> incompatible). If an error is raised (they hold a stack trace), I want them
>>> simply propagated upwards. Error handling in the middle of these math
>>> expressions (some are larger) get in the way of the math being expressed.
>>>
>>> cheers
>>> Jan
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsUQfPLP1w0s9EN3XZSsoproEStkQHRb-s8pcdTgmpbzTw%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsVD7Nf3%2B-dtrtSPxKjstimrczis%2BEhbWYT5Wasix3zaEg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/A7FA65A3-8C10-454C-BC9D-C2C58952F96F%40ix.netcom.com.
