Maybe not the best way either, but the POD part might benefit from slight
refactoring and you already in part hinted at it.
- gopher/api -- some PODs here
- gopher/model -- don't repeat gopher as in gophermodel; some PODs here
It won't ever perfect, so YMMV. But at the same time it allows
I've been using Go for almost a decade and I still don't have a library
package structure I like. I'm hoping I can post what I want here and
someone can tell me either (a) what the idiomatic way of doing this is, or
(a) how to break the dependency cycle.
Let's imagine we're building the fancy
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
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
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 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 wrote:
>> Hi Jan, thanks for
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 wrote:
> Hi Jan, thanks for response.
>
> On Mon, 5 Jun 2023 01:06:37 -0700 (PDT)
> Jan wrote:
>
> > Repeating Justin's consideration: one of my (and from colleagues I
> >
Suddenly thinking that I can actually just use type parameters but the type
argument can also created lazily by being instantiations of parametred
types..
Might actually be sufficient to have value scoped type instantiations.
On Sunday, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote:
I have exposed the following problem in a bit more details here:
https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c
Basically, I need to modify the implementation of the method of a given
type depending on the encasing scope of the value its called on. (and not
just the value
