Closed apfeffer closed 10 years ago
Hi Avi,
just a short note on that one without knowing the exact requirements: Scala Macros provide you with a way to programmatically inspect functions. Could you elaborate a little more where functions need to be transparent?
Best Martin Am 20.11.2013 23:32 schrieb "apfeffer" notifications@github.com:
Figaro allows arbitrary Scala functions to appear in Chain, Apply, and in conditions and constraints. This is both a source of great power and a weakness, because it means the internals of these functions are opaque and can't be analyzed. Furthermore, it makes it difficult to know if the same function is being called more than once with the same arguments, which is important to algorithms.
It would be desirable, in addition to general Scala functions, to have a type of Figaro function that can appear in places a Scala function currently appears. These would allow Figaro to retain its power will providing more analyzability where desired.
— Reply to this email directly or view it on GitHubhttps://github.com/p2t2/figaro/issues/56 .
Hi Martin. The example that we keep talking about is recursion. One can use Scala's recursion mechanism to create nested Chains, where the recursive call is within the function applied to the Chain. Since the recursion is occurring through Scala, Figaro has no way to know that the application of the Chain function will be creating multiple copies of the same elements, which might be nice to avoid in some cases and could enable other enhancements (something akin to tail recursion for Elements).
Hi Martin,
Thanks for the tip on Scala Macros. I’ll take a look at what they can do.
The problem we’re dealing with is this. In stochastic lambda calculus and languages based on it (e.g., IBAL), the language provides for lambda abstraction using language constructs and methods for applying such functions to arguments. This has advantages. You can expand the body of a function and reason with it or analyze it, and you can tell when the same function is applied to the same arguments, which is useful for dynamic programming. Figaro does not have lambda abstraction – it relies on Scala functions. Which is powerful and convenient, but we find ourselves wishing that we could do the same types of analysis to functions as I used to do in IBAL.
We’re looking into ways of defining an analyzable subset of Figaro to sit alongside the full language, so in case the algorithms see something analyzable, they can do something useful with it. But it’s not so simple.
Any thoughts you have on it would be welcomed!
Thanks,
Avi
From: Martin Mauch [mailto:notifications@github.com] Sent: Wednesday, November 20, 2013 8:18 PM To: p2t2/figaro Cc: Avi Pfeffer Subject: Re: [figaro] Figaro functions (#56)
Hi Avi,
just a short note on that one without knowing the exact requirements: Scala Macros provide you with a way to programmatically inspect functions. Could you elaborate a little more where functions need to be transparent?
Best Martin Am 20.11.2013 23:32 schrieb "apfeffer" notifications@github.com<mailto:notifications@github.com>:
Figaro allows arbitrary Scala functions to appear in Chain, Apply, and in conditions and constraints. This is both a source of great power and a weakness, because it means the internals of these functions are opaque and can't be analyzed. Furthermore, it makes it difficult to know if the same function is being called more than once with the same arguments, which is important to algorithms.
It would be desirable, in addition to general Scala functions, to have a type of Figaro function that can appear in places a Scala function currently appears. These would allow Figaro to retain its power will providing more analyzability where desired.
— Reply to this email directly or view it on GitHubhttps://github.com/p2t2/figaro/issues/56 .
— Reply to this email directly or view it on GitHubhttps://github.com/p2t2/figaro/issues/56#issuecomment-28949934.
I must admit I have only written a toy macro once :p I think it should be doable to detect simple recursive calls with a macro, but there might be involved cases where it's hard to reason if a call will recurse
if (Random.nextDouble < 0.5) recursiveCall() else 42
A simpler but also more restrictive option might be to make functions @tailrec
-ursive and decide on the presence of the annotation if there is recursion.
I probably understand to little about probabilistic programming to come up with more refined ideas ;)
Figaro allows arbitrary Scala functions to appear in Chain, Apply, and in conditions and constraints. This is both a source of great power and a weakness, because it means the internals of these functions are opaque and can't be analyzed. Furthermore, it makes it difficult to know if the same function is being called more than once with the same arguments, which is important to algorithms.
It would be desirable, in addition to general Scala functions, to have a type of Figaro function that can appear in places a Scala function currently appears. These would allow Figaro to retain its power will providing more analyzability where desired.