Should `:storedTypedExpr` be turning up in macro functions?

1

I’m porting a null checking macro to 5 and I’m getting metadata with a const attached rather than an expression.

2

That’s “by design”, yeah. Roundtripping Expr → TypedExpr → Expr is generally not safe, because for example foo.bar becomes foo.get_bar() for properties and then fails due to private field access.

So when the compiler needs to do that for whatever reason (typically static extension macros) it does what’s also exposed in Context.storeTypedExpr, which puts the TypedExpr into some lookup table under a new id and returns that, so when it gets typed again, it can just retrieve it.

What you probably wanna do is Context.typeExpr which will give you the TypedExpr and then you’ll have to operate on that, rather than untyped expressions :wink:

1 Like
3

This is my tinkering with thx.core and 5 alpha for something I want to use, and the null check macros have been failing, specifically.

Other than changing over to native lambdas, there’s not much to do, afaict.

4

Yes, I understand, but I’m not sure what you’re asking. Neither the library nor the language version are particularly relevant here ^^

If “Should :storedTypedExpr be turning up in macro functions?” is your question, then “yes” is the answer. It is a totally normal thing to encounter (since Haxe 4.3, before it was @:this this - since Haxe 3) . If you must inspect it, then you’ll have to do with the TypedExpr … otherwise you can just pass it around like any other expression.

Here’s an example how to illustrate how the compiler produces stored expressions automatically and how you can do that manually and how you can get to the TypedExpr so you can obtain it when necessary: Try Haxe!

1 Like
5

So in an expression Expr, there can be a reference to a TypedExpr by marking a regular expression via metadata :storedTypedExpr and then an expression of a constant?

I haven’t got a complete picture of how the thx macro works yet.

My other point about library is sort of relevant if you’re interested in how libraries in general, especially where authors are less active, will fare when the new version drops.

6

Yes, exactly … there are multiple use cases for this, but the main issues this avoids is:

  1. typing an expression multiple times has various implications, one of which is that any macros therein will be run multiple times as well, which is rarely desired
  2. typing is “lossy” in many ways that prevent Expr → TypedExpr → Expr → TypedExpr from working in general, e.g. if you have something benign as SomeClass.someMethod(), then typing could inline someMethod , producing code living outside SomeClass and references private fields of it (or private types from the module). It’s impossible then to restore an Expr that would pass the typer another time.

Yeah, I get that. What I meant is that what you’re observing in regards to @:storedTypedExpr is unrelated to specific libraries or major releases. The observable behavior tends to even change between minor releases, when typing order is adjusted to avoid some fringe issue or another.

1 Like
7

Franco’s null check in thx is trying to look-up the identifier for throwing error messages on null, that’s what I got snagged on.
I know lisp interpreters do De Bruijn indices for the RExprs.
thank you