# Open IR Questions ###### tags: `IR` `Felix’s remains` The sections are ordered alphabetically, not by importance. ## Builtins ~~- `is_none`: do we still need it? Also related to [scans](##Scans). If we want to support an optional/maybe type, we should also introduce a `make_optional` or similar.~~ - `can_deref` vs. `can_shift` - Documentation of all builtins including the full signature should be available somewhere. - Host-language-independent ‘official’ names should be defined for all builtins (that is, avoid `if_` etc.). Dealing with language keyword clashes should be implementation specifico. - [Type casts?](##Typing) - Other additional builtins: `tuple_cat`? ## Domain Is the domain definition part of the IR? Also decides about the builtins `domain` and `named_range` available in the Python implementation. ## Order of Function Definitions The allowed dependendencies between function definitions should probably be limited to disallow recursion (as in schemes `let*` vs. `letrec`). ## Literals ~~Do we need string literals and the ‘none’ literal (related to `is_none` above)?~~ ## Overloaded `shift` Currently, we have overloads of `shift` that depend on the argument type. That is, a partial shift is applied if a connectivity is passed; a partial shift is resolved to a full shift if an integer is passed. However, the offsets are abstract in the IR, so the overloads can not be handled without additional knowledge. ## Scans ~~In Python, on the one hand, `is_none` is currently used to distinguish the first level.~~ In C++, on the other hand, an arbitrary number of ‘prologues’ and ‘epilogues’ is supported, but `is_none` is not. This approach also allows easily for different computations on an arbitrary number of levels at the beginning and end of the loop. ## Typing - Do we need explicit type casts, explicitly typed constants? - Does the IR include some basic dtypes (like `int32`, `float64`, etc.) or is the IR unaware of types? ## Sparse Field Should the IR know about sparse fields? If yes, it's only semantics of how to map fields (closure arguments) to iterators (at execution). In reduce, not having sparse fields will promote an optimization (we can check only the first argument for `can_deref`) to semantic (we must only check the first argument).