feature request: partially evaluated graphs about plumbing

[w01fe]

Thanks for your interest in Graph.

Someone asked about this on the mailing list earlier:

https://groups.google.com/d/msg/prismatic-plumbing/VdlQF4LgIj0/LH21gJGnvxQJ

As I mentioned there, I'm hesitant to allow this because it reduces the amount of error checking we can do, and also makes nodes as constant functions ambiguous. There's also little reason I can see for constant values to be part of the Graph -- they can just as well be part of the input parameters.

That said, if you can make a compelling argument for why the benefits outweigh the downsides, we're happy to consider a change.

[0xYUANTI]

Thanks for Graph! :)

Not sure there is a compelling argument to be made - it just looks visually more appealing to have a single map literal rather than a graph and an input map in some cases (e.g. when returning a map which will be converted to a JSON object by Ring middleware from a REST API function).

As for the downsides, I think the current behavior is a fine default - what I'd like to see is an alternative constructor (`partial->graph' maybe?) which let's the user make the error-checking trade-off explicit. Could the ambiguity issue be solved by checking for meta data to determine whether something is a fnk?

[w01fe]

On Mon, Aug 12, 2013 at 11:24 AM, Jakob Sievers [email protected]:

Thanks for Graph! :)

You're welcome :)

Not sure there is a compelling argument to be made - it just looks
visually more appealing to have a single map literal rather than a graph
and an input map in some cases (e.g. when returning a map which will be
converted to a JSON object by Ring middleware from a REST API function).

As for the downsides, I think the current behavior is a fine default -
what I'd like to see is an alternative constructor (`partial->graph'
maybe?) which let's the user make the error-checking trade-off explicit.
Could the ambiguity issue be solved by checking for meta data to determine
whether something is a fnk?

Fair enough :). No matter what, there will always be an ambiguity between
a constant fnk and a node, but I see your point about allowing a choice.
Does it seem reasonable for you to put partial->graph in your own library
for now, and if after using it for awhile you still feel like it's valuable
you can submit a pull request and we'll most likely bring it in?

Thanks,
Jason

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-22514000
.

[0xYUANTI]

Absolutely!