<endformationage>
I wish there was a way to hold onto a partially applied constructor/fun/be such that one could use it to build up the call's arguments out of order (for example from behaviors supplying an arg).
<endformationage>
In a sense to use the resulting object literal as temporary storage of the args until all are received.
<SeanTAllen>
endformationage: how does this differ from the existing partial application support?
<endformationage>
Specifically, I have in mind the supply chain pattern.
<jemc>
does partial application support named arguments? I'm not sure because I've never used it that way
<jemc>
if it does, then it would support the "out of order" requirement you're talking about
<SeanTAllen>
ah
<SeanTAllen>
that is what "out of order" meant there
<endformationage>
I think it does, but the issue is holding onto the resulting new partial application which is of a different type
<endformationage>
Yes, out of order args is supported.
<jemc>
endformationage: not sure how you could work around the "different type" issue in any strongly-typed system
<jemc>
seems like a fundamental aspect of the situation to me
<endformationage>
Yeah. I was wondering if somehow the resulting obj literal could be traited somehow, that way a resulting partial apply could re-trait itself? Perhaps I'm just making stuff up at this point.
<endformationage>
In the same way you can type an obj literal: `object is FooBuilder` ...
<jemc>
the signature is going to be different, though - especially if you're relying on named arguments
<endformationage>
right
<jemc>
I'm interested to know more about the problem you're solving, if you want to share
<endformationage>
But could it not be an empty trait?
<jemc>
I may have another idea
<jemc>
endformationage: what does an empty trait do for you? you can't call anything on it because it has no methods
<endformationage>
Could it allow you to hold onto object literals traited as such, but where each has different apply arity.
<endformationage>
foo_builder = foo_builder~apply(where x = 42)
<endformationage>
...
<endformationage>
foo_builder()
<jemc>
no, I don't think it's possible to design a `FooBuilder` trait that works that way in a strongly typed system
<jemc>
have you thought about just using an object with public `var fields`? :)
<jemc>
`let foo: Foo`
<endformationage>
This is what I've done. Basically keep a field for each parameter of the obj I'm building
<jemc>
`foo.x = 42``
<jemc>
`...`
<endformationage>
Well, these are more complexe objects that require some building from other actors, and I wished not to type them (ComplexObj | None)
<endformationage>
.. while they may fail building.
<endformationage>
Like I said, the supply chain patterns
user10032 has joined #ponylang
<jemc>
the hurdle you have to design around is that the type system has to know everything necessary to do the method call (or partial application)
<jemc>
anything that tries to hide that info away from the type system is doomed to impossibility I think
<endformationage>
OK. Probably not worth it, given it really only makes things a bit less verbose I suppose.
<endformationage>
Thanks for the consideration
<jemc>
you can hide details that aren't necessary using traits and interfaces, but if you're calling a method on a type, the type system has to have all the info it needs about that method call's signature
<jemc>
endformationage: no problem
samuell has quit [Quit: Leaving]
<endformationage>
Also, unrelated, for the second time I designed code with promises that ended up attempting to fulfill iso object. It reminded me of:
<endformationage>
.. they were originally val fulfillments, but I ended up having to change them to be iso.
<endformationage>
I just mean to mention a situation where a common promise interface would be useful, where the code design uses Promises, and the fulfilled objects refcap needs to change to iso for 'reasons' :P
<endformationage>
.. That way one could still use promises.
<SeanTAllen>
i love the "reasons"
<SeanTAllen>
most things should use "reasons" as the explanation
<endformationage>
SeanTAllen: I know, sorry not very helpful/useful :)
<SeanTAllen>
no no
<SeanTAllen>
i really do like "reasons"
<SeanTAllen>
i say that all the time
<SeanTAllen>
usually i saw, "because.... reasons"
<endformationage>
Hah, I probably got it from you then.
<endformationage>
I guess my main 'reason' is.. "I'm doing this to try and make it work."
<endformationage>
Do it enough times and it actually does work. Until you need something else to work. :)
<jemc>
I'd like to see somebody come up with a good way for `iso` and `val` promises to interoperate
<wuehlmaus>
is there a pony repl other than playground.ponylang.org? i want something which i can invoke from the shell.
samuell has joined #ponylang
<SeanTAllen>
wuehlmaus: nope
<wuehlmaus>
SeanTAllen: thanks for telling me.
<SeanTAllen>
you're welcome wuehlmaus. i never considered playground to be a REPL so you could probably get something like that working locally
<wuehlmaus>
yeah, it's not a REPL, it's just something that is a bit similar to what i want.
<jemc>
wuehlmaus: I may be missing something, but if you want something like the pony playpen that you can invoke from the shell, wouldn't that just be: `cd myproject && ponyc --debug && ./myproject`?
<wuehlmaus>
agreed, perhaps even use watch
vaninwagen has joined #ponylang
<wuehlmaus>
well, repeatedly use compilation is probably not what i want so 'watch' is probably a little much :)
<jemc>
I usually work by setting up a `run.sh` in every project directory, and configure my text editor to have a hotkey to run that script
<jemc>
and I modify that script over time as I work to do whatever repetitive task I'm currently working on
<jemc>
when working on a pony project, the contents of the script is usually something like the command I gave above
<jemc>
though sometimes I throw a `Makefile` into the mix to help with that too
<wuehlmaus>
i found hsandbox a few years ago which is a nice python script to give me REPLs for almost every language i touch
<wuehlmaus>
but it is easy in ponys case so probably not neeeded.
_andre has quit [Ping timeout: 240 seconds]
<endformationage>
How can I destructively read an iso from a field that is a union of that iso with None? As in: `var field: (Foo iso | None) = None`
<endformationage>
I want to consume it as an argument to a constructor.