Make assert/invoke require constant parameters?

[AndrewScheidecker]

I just noticed that invoke accepts arbitrary expressions as parameters. WAVM currently generates code for each assertion, but I was hoping to get rid of that and make each assertion just call some exported function with constant parameters.

It could also go the other way and allow expressions other than invoke as the left hand side of the assertion, but what's there right now seems like an awkward trade off between power and simplicity that achieves neither.

[sunfishcode]

This makes sense to me. I revised several tests to work like this already, and #104 revises float32.wast's tests this way too, which I believe is the only remaining one.

[lukewagner]

Ideally, I think, we'd not reuse wasm for the Script.command language (and thus remove Eval.eval). That might also let us have more concise syntax for specifying the constants.

[jcbeyler]

I don't really see a problem with having expressions as parameters. Is there one?

I implemented it as such and think it is a good way of being able to cascade different calls together and ensuring the end result. I see simplicity of having the constants instead but I think expressions just allow more possibilities.

[titzer]

I also think constants only makes sense. Otherwise you need to be able to
'eval wasm' to test wasm.

On Wed, Oct 7, 2015 at 4:05 PM, jcbeyler notifications@github.com wrote:

I don't really see a problem with having expressions as parameters. Is
there one?

I implemented it as such and think it is a good way of being able to
cascade different calls together and ensuring the end result. I see
simplicity of having the constants instead but I think expressions just
allow more possibilities.

—
Reply to this email directly or view it on GitHub
#109 (comment).

[jcbeyler]

Funny ☺. It kind of goes in the same conversation of Descartes: Doubt of everything except that you are doubting (otherwise how can you know that you are really doubting ;-)).

I do see the point but I don’t see it as a real problem:

Unitests that use constants for base functionality of foo

è Thus assess that foo is fine

Start using foo in the unitests for higher level testing.

I’m ok with any decisions you make, I was just curious

[lukewagner]

Eval.eval is now removed and args/results are fixed to constants.