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 <https://github.com/janpfeifer/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 > <https://groups.google.com/d/msgid/golang-nuts/CAE%3D7LsUQfPLP1w0s9EN3XZSsoproEStkQHRb-s8pcdTgmpbzTw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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.
