Type of some unexpected value

[hubertp]

This subject came up as part of the discussion on a PR.
It's trivial to replace that to throw a Panic but we seem to rely on that under some circumstances.
I saw at least that we check

• type of UnresolvedSymbol
• type of AtomWithHole

What should be the type of those? Any, Nothing? We probably shouldn't throw a Panic then since we rely on it in a regular flow e.g. in meta.
/cc @JaroslavTulach @kustosz @radeusgd @Akirathan

[radeusgd]

1. It does not need to be a Panic, it may be a dataflow error. It's just weird to return an error as a value as is now.
2. Other thing is what we should put for the two mentioned objects.

• AtomWithHole - shouldn't that be a normal Atom? Should it be distinguishable in any way?
• UnresolvedSymbol, as I wrote in UnresolvedSymbol is not a Function, but it should be #6277, I would suggest to treat it the same way as we treat any lambda, like x->x. I.e. the type_of an UnresolvedSymbol, IMO should be a Function, as it essentially represents a shorthand notation for a lambda (.foo behaves the same as x-> x.foo).

As for Meta.meata - currently, a function is treated as a Meta.Primitive. I guess that's OK, but while we are discussing it, I think it would make most sense to introduce a Meta.Function variant.

[hubertp]

• re AtomWithHole - It's actually HoleInAtom, my typo, a field that should be filled. So nope, Atom would be the incorrect type since we don't know what kind of value will be there.
• re the case that matches unresolved symbol - yeah, that can probably be done. Such pattern matching still relies on TypeOfNode but we can probably add a specialization for that.
• re the bug in processor - I will take a closer look

[radeusgd]

Right, if it's a HoleInAtom that's a different conversation :) IMO returning an error in that case makes most sense. It's essentially querying metadata of a yet uninitialized field. That sounds like a thing that just should not be done.

[radeusgd]

My reasoning for error - I'd like Meta.type_of x to stay stable between invocations.

Of course, for uninitialized hole which just will get initialized, something must change. But I think a change from error to a value makes sense - error before indicated that you 'asked too early'. Once initialized, the value is stable.

OTOH, a change from value to value is a bit less expected.

[JaroslavTulach]

It's essentially querying metadata of a yet uninitialized field.

Right.

That sounds like a thing that just should not be done.

No, it shouldn't be done. atom_with_hole is a powerful API that should be used by people who know what they are doing to temporarily construct an unfinished Atom.

IMO returning an error in that case makes most sense.

I'd return Any, but Error is probably also acceptable. It is a situation that shouldn't happen - I am even surprise it is checked somewhere!

[hubertp]

I'd return Any, but Error is probably also acceptable. It is a situation that shouldn't happen - I am even surprise it is checked somewhere!

I reverted to dataflow error. Don't have strong opinions about that one so if you really want I can make it Any.