-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Macro is evaluated for type information when not necessary #201
Comments
Thanks for this. The evaluation of each of the
|
The first three evaluation of By reducing macro evaluations, we can:
I think the current approach of evaluating types at each dispatch also has its advantage. The rule of dispatching is probably simpler, and more transparent. |
This is true, but per your last comment, the current approach is used because it's simpler and more transparent. The only exception to the rule is for macros with names that are not overloaded at all (e.g. |
I am concerned that, when the macro/function overloading gets used more in a program, the compilation time cost could also be very high. Currently, such overloading is not used much in the standard library, so this issue may not be so obvious. What about this: we try our best to determine the dispatch without multiple macro evaluation, and when that fails, we abort with a compilation error. This approach is understandable to the programmer, but it is not so transparent. Whether a program compiles or not depends on the compiler implementation. This approach is extensively used by Rust, but I am not so fond of it. However, I dislike multiple macro evaluation more. Regarding the typed macros, I have just come up with a new idea. For typed macro arguments, pass the fully expanded form as the argument value, rather than the original form to be expanded again. To justify this, it seems to me that, to determine the type of argument, its semantics have to be determined first. And therefore, it seems to me that the argument should be passed in as a semantic value rather than a piece of syntax. And the closest thing we can do in Dale, is to pass the fully expanded form in. Also, With the above considerations, I think the issue of #200 is satisfactorily addressed. |
One of the problems of the typed macros also is following: Dispatching on argument length before type dispatch also seems like a good idea.
This way, the only way to evaluate a macro, which is a macro argument, multiple times is by not specifying the argument type for one field, but still just evaluate it in the macro itself. |
@porky11 Glad to see your supportive comment again :) My idea has evolved a bit, and I want to make some clarifications about my current idea. My current idea is to:
When the compiler cannot guarantee the above conditions for a set of overloaded functions/macros, the compiler aborts with a compile error. The compiler uses a potentially complicated algorithm as dispatch strategy, and the programmer would consider the algorithm as an opaque compiler implementation detail. I can try to devise a specific algorithm, if the overall direction is good. This will impose some limitations on how function/macro overload can be used in a program, but I feel that with a smart algorithm, the limitation would be small in practice. Lastly, we also return the fully expanded form from |
I can see one potential issue with my idea. It's possible that the fully expanded form of typed macro arguments to be interpreted as a different semantics in the macro output, and thus breaking the idea of passing a semantic value in. I currently think this flaw is acceptable. @tomhrr What's your opinion with this? You don't have to do the compiler implementation, and I can help with that. |
I think this is a reasonable idea. To make sure I understand properly, this is how I think it could be implemented:
Does this look OK? |
Glad to see you agree with this idea :D
There're two major exceptions that need to be handled. Typed and untyped parameter can coexist at the same position, if:
Consider the following examples:
For a systematic algorithm to check whether a given set of macro/function is dispatchable, I sketch a pseudo-code as below:
EDIT 1: improve how |
Yep, agreed for both of these. |
I have tried to implement this, and found a problem. Currently, there's absolutely no way to obtain the fully expanded form. The most sensible way to address this seems to include the fully expanded form in I have also found an unanticipated issue in the interaction between namespaces and overloaded functions, but that issue is not difficult to address with some small changes to the above pseudo-code. |
OK, thanks for looking into this. I will see about including the expansion in the |
Macro
m
is evaluated 6 times during compilation, while I expectm
to be evaluated only 3 times. If I am not mistaken, in the context+
is overloaded as follows:The text was updated successfully, but these errors were encountered: