Sponsored Link •
|
Summary
I want Heron control structures to be defined as macros. It should be easy for a programmer to introduce a do/while loop or a better for statement. One of the principal motivations, is that the programmer should be able to specialize these things for specific types, or meta-types.
Advertisement
|
Consider for instance a repeat (x) {...} construct within a library. There could be two versions: one which is essentially a rewritten while loop. But what if x is a constant known at compile-time? Then it would make sense for the loop to be unrolled, if x is sufficiently small. Often this is done by the compiler, but under some conditions a programmer, knows better than an optimizer and can do experiments to find specific conditions where unrolling would work better.
Compile-time constants in languages, have a special status. In C++ under some conditions, an expression involing compile-time constants is resolved at compile-time. When and if this occurs is often implementation defined, and is unreliable. What I want as a programmer is explicit control over when and how compile-time evaluations occur. Macros/Template Meta-Programming provide very clunky methods of computing compile-time expressions.
What this implies is that in the statement: int x = 3 + 5;, the value 3 and 5 do not really behave like variables of type int, but rather something different. One big difference is they occupy zero bytes. Ironically if I took the size, e.g. sizeof(3), I would get a non-zero value, but in reality, no storage is allocated. This is why I consider constant integer literals as instances of a separate type, which I call a meta-int. In Heron I plan on identifying a meta-int as #int. A meta-int would support both implicit converion to its corresponing run-time type, as well as possibly explicit conversion though the $ operator.
Anyway on to the problem of mapping a Heron statement to a macro call. Consider the statement:
if (some_bool_expression) then { do_something; } else { do_something_else; };I want to map this directly to a macro call, which is defined in a library, and can even be overloaded. So what does the macro declaration look-like? I don't really know! I have several ideas, but what gets me is the "then" and "else" keyword placeholders.
The syntax which is currently my leading favourite is:
class if { } class then { } class else { } macro (#type x0==if, ...) = ERROR "invalid if statement"; macro (#type x0==if, bool condition, #type ignore0==then, #code on_true) = COND condition on_true; macro (#type x0==if, bool condition, #type ignore0==then, #code on_true, #type ignore1==else, #code on_false) = COND condition on_true true on_false;So that might be a confusing mess, but there is a disturbed kind of logic underlying it all. A macro would have no identifying label, it would be identified solely by the types and meta-types of the parameters. You could think of a statement as an overloaded call to the ";" macro, where every term is an argument. A term would be an identifier, symbol, paranthesized expression list of terms or a curly-braced list of statements. There would be a core set of predefined macros such as COND which corresponds to the Lisp operation of the same name, or ERROR which returns a compile-time error.
Now this is purely hypothetical, and it would be some time before I could implement all of this in the Heron prototypes. I am worrying about the syntax, because it makes it easier to imagine using the language in a thought experiment and can affect other design decisions (e.g. significance of ";") as well as the implementation.
I don't want to continue working on implementations until I figure this mess out, and come up with a consistent and logical design which unifies macros and the type-system.
Have an opinion? Readers have already posted 11 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.
Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com. |
Sponsored Links
|