Separating procedure declaration and definition about ivory HOT 5 CLOSED

Hi Chris! This is a really good question. I'm glad to see that others have run into this weird corner of the language design as well. It presented a bunch of problems throughout the design and implementation of tower.

Unfortunately, we haven't come up with a satisfactory solution for every use case. We have, in the past, solved this problem by relying on a call on an ivory function is strict only on the function identifier (string argument to proc).

So to re-use your example program

foo :: Bar -> Def ('[] :-> ())
foo bar = procImpl "some_constant_string" $ body $ do ...

The caller of foo, who may not have a bar argument available, can still generate valid code via call_ (foo undefined) or better yet call_ (foo (error "broken invariant: call to foo should not be strict in the argument")). So you can export some variant of foo from the module that gives a proper error message, and have some other way internally to apply the correct Bar where foo is incled, which is strict in that argument.

Admittedly, this is ugly, because abusing strictness often makes code hard to read and reason about. But if you do so in a a principled way, perhaps you could implement your proposed procDecl and procImpl along these same lines as a library, rather than a modification to ivory, if you were willing to wrap (or replace) Def with another dataype (perhaps ProtoDef?), and make variants of of call and incl that do the correct thing.

As far as extending the Ivory language to include this concept, I don't have any specific objections to your proposal, but I'd defer to @elliottt and others to think on it further. While I totally understand the ways this is useful (and, in terms of C programming, even idiomatic) I'm a bit wary to add anything more to the language that can be implemented as a library.

from ivory.

Pat, good to see I'm not alone in having this problem! By coincidence, I also ran into http://okmij.org/ftp/Haskell/tr-15-04.pdf and saw that my issue is probably 90% just a more specific form of the 'configurations problem'.

It looks like a library should be able to accomplish this. I can't see any reason why the AST needs some special representation of a function prototype.

I hadn't thought of relying on call being strict only on the name. Still, though, it seems like DefImport (as importProc creates) is a cleaner/safer representation, since one may examine the Def and just treat it like a procedure defined elsewhere, while DefProc adds a procBody field that must remain unevaluated.

That suggests one way - creating a function to turn a DefProc to a DefImport (and leaving body untouched), and extending this to handle functions of arbitrary arity that produce a Def by applying however many error ....

from ivory.

Sounds good! I'll close this issue, but please re-open it if you discover any issues while implementing your library functionality.

from ivory.

@Hodapp87, why can't the issue be resolved as follows to elide the configuration parameter from the constant being called (fooProxy) while ensuring that the type of fooProxy must be consistent with the type of foo, with the configuration parameter?

data Bar = Bar { aField :: Int }

defaultBar :: Bar
defaultBar = Bar 0

foo :: Bar -> Def ('[Uint8] :-> ())
foo bar = proc "foo_proc" $ \_x -> body $ do retVoid

fooProxy :: Def ('[Uint8] :-> ())
fooProxy = foo defaultBar

caller :: Def ('[] :-> ())
caller = proc "caller" $ body $ call_ fooProxy 3

from ivory.

@leepike, the way I see it, this just becomes the same thing if it's generalized to support arbitrary types. I will show you what I mean with a pull request once I've converted over what I did a few days ago and put it someplace appropriate in Ivory.

from ivory.