[RFC] Unify alias and @parameter under a single keyword

[augb]

Picking up the discussion from #171 as suggested by @Mogball.

To summarize my view at this point in the discussion, I offer the following:

I started this as a replacement for the keyword alias; however, I'm seeing the benefit of aligning @parameter and alias under a single keyword such as const, compexp or comptime.

While I understand the choice of alias and @parameter, respectively, I feel these are too overloaded with meaning from other languages and common usage of these terms in programming.

If possible, having a single keyword, as opposed to a mix of a keyword and a decorator, would be preferable.

[nmsmith]

Thank you for migrating this discussion @augb. Here is a summary of my thoughts on this topic.

My viewpoint

I believe that alias shouldn't be a special concept. Instead, it should be the same thing as a let binding that executes at compile-time. Having a single semantics for variable binding—irrespective of whether the binding occurs at compile-time or run-time—would reduce the number of concepts that people need to learn to do metaprogramming. Additionally, it leaves open the possibility of unifying the compile-time language with the run-time language over time. The alternative would be to have a "sister language" for metaprogramming, that requires users to learn a whole new set of language constructs. In my opinion, that would be a design mistake.

Update: Below, @Mogball confirms that Mojo already supports the execution of arbitrary Mojo code at compile-time—with a caveat that the code cannot allocate memory yet. This is great to hear! Given this fact, the rest of my post should be understood as a proposal to have a syntax for mixing arbitrary pieces of run-time code and compile-time code within a function body. As I will demonstrate, such a syntax would make the alias and @parameter constructs obsolete, thereby bringing Mojo's metaprogramming language closer to its run-time language.

Possible syntaxes

The goal is to have a syntax for indicating the time at which an arbitrary piece of code is executed.

We will need to introduce a new keyword. I will use comptime as a placeholder. (We can bikeshed about the keyword separately.)

One of the syntaxes I have proposed is a comptime block, whose statements are all executed at compile-time:

fn foo[flag: boolean](x: int):
    comptime:
        let y: int
        if flag:
            y = foo(...)
        else:
            y = bar(...)
    return x + y

In this light, a comptime variable declaration (currently known as an alias) can be understood as shorthand for a comptime block that contains a single line of code:

comptime:
    let y = 2

comptime let y = 2

And maybe the let keyword is allowed to be implicit for such one-liners:

comptime y = 2

This brings us full-circle with the original topic of discussion: the alias keyword. The above line of code is a syntax for aliases, but it is a principled one: it is simply a let binding that is bound at compile-time. As I stated earlier, I believe it is worth avoiding having special kinds of variables that operate at compile-time. After all, we already have let, var, inout, borrowed, and owned. We don't need an alias as well 😳.

Now, what about the @parameter keyword that is currently used to indicate a compile-time if statement? Let's look at a concrete example:

struct SIMD[type: DType, size: Int]:
    ...
    fn reduce_add(self) -> SIMD[type, 1]:
        @parameter
        if size == 1:                  # compile-time
            return self[0]             # run-time
        elif size == 2:                # compile-time
            return self[0] + self[1]   # run-time

This is a (truncated) example from the Mojo docs. How could we describe the same computation using our comptime syntax? Notably, using a comptime block doesn't work here, because the lines of code alternate between compile-time and run-time (see the code comments). Thus, it seems we will have to mark each line of code that runs at compile-time individually:

struct SIMD[type: DType, size: Int]:
    ...
    fn reduce_add(self) -> SIMD[type, 1]:
        comptime if size == 1:
            return self[0]
        comptime elif size == 2:
            return self[0] + self[1]

In my opinion, annotating both branches is better than just annotating the if branch, because it makes it explicit that the elif is also evaluated at compile-time.

Conclusion

My core concern is not about the particular choice of keyword, it is about the model of compile-time execution that Mojo presents to its users. My assertion is that it would be conceptually simpler to offer a single set of constructs that can be used at both compile-time and run-time. Users shouldn't need to learn any additional concepts (like alias) to do metaprogramming. They just need a way to specify the time of execution. This is what the comptime keyword achieves in the above examples.

Addendum 1: Compile-time expressions

In the previous discussion thread, @Janrupf proposed allowing individual expressions—including arbitrary function calls—to be annotated with comptime, to request that they be executed at compile-time. I think it is definitely worth considering this use-case as well. It fits naturally with the rest of what I have proposed.

If Mojo were to allow arbitrary functions to be executed at compile-time, they would likely need to obey certain restrictions, such as not being able to do I/O. Thankfully, this doesn't require any support from Mojo's type system: if an I/O call is made at compile time, it would be sufficient to just abort compilation. But this is a "stretch goal". It would be perfectly reasonable (as an MVP) to forbid the execution of arbitrary functions at compile-time, and only allow basic operations such as arithmetic.

Update: I have been informed that Mojo already supports the execution of arbitrary functions. Nice!

Addendum 2: Type aliases

Currently, Mojo's alias keyword is also used to declare type aliases. This is obviously a useful feature. We could continue to use the alias keyword (or the type keyword) for this purpose. No comptime modifier is required when declaring type aliases, because types only exist at compile-time.

[Mogball]

If Mojo were to allow arbitrary functions to be executed at compile-time

Mojo already allows arbitrary code to be executed at compile time, with the exception of anything that makes external calls or uses dynamic memory (that one is a TODO).

As stated above, my proposal is for the metaprogramming language to reuse the same set of constructs as the base language

See the programming manual, which states "parameter expressions are just Mojo code". Mojo doesn't have a second metaprogramming language.

Currently, Mojo's alias keyword is also used to declare type aliases. This is obviously a useful feature. We can continue to use the alias keyword (or the type keyword) to declare these. No comptime modifier is required when declaring type aliases, because types only exist at compile-time.

-1 on having two different keywords. Type aliases are not a special concept in Mojo. They are treated as compile time expressions like any other. E.g. you can define a function that returns a type, but it will only be executable at compile time because there is no runtime representation of a type (yet...).

[nmsmith]

Mojo already allows arbitrary code to be executed at compile time

Oh! That's fantastic! I swear I had tested this in the past. I must have triggered a memory allocation. Indeed—testing this again—it seems that its not possible to work with strings at compile-time, but integers work fine!

See the programming manual, which states "parameter expressions are just Mojo code".

I read the whole programming manual when Mojo was announced, but it did not give me the impression that Mojo allows arbitrary code to be executed at compile-time. Perhaps this point needs to be emphasised more explicitly?

"Parameter expressions are just Mojo code" does not imply that "any Mojo code can be used as a parameter expression". The closest the docs come to making the latter statement is the sentence:

Parameters are quite powerful, supporting the use of expressions with operators, function calls at compile-time, and more.

It's possibly worth elaborating this sentence into a full paragraph, fully enumerating what can and cannot be done at compile-time. 😇

-1 on having two different keywords. Type aliases are not a special concept in Mojo. They are treated as compile time expressions like any other. E.g. you can define a function that returns a type, but it will only be executable at compile time because there is no runtime representation of a type (yet...).

Fair enough. I suppose types can be stored in let bindings as well (situated within a comptime context, as discussed). It would be nice to have a syntactic distinction between variables that hold values vs. variables that hold types though. That's why I thought the alias or type keyword would be appropriate. But... I suppose capitalization of the variable name is sufficient for that purpose. (And syntax highlighting!)

[Janrupf]

Allowed operations

My hope for comptime is that it can use an MLIR interpreter to run whatever code is supplied. Partially this already works, othertimes MLIR seems to fail to expand causing a compilation error.

But as @nmsmith already said, that brings up the question of allowed operations. In case MLIR can fully be evaluated at compile time, that would allow for dynamically capturing data - something you usually need a complex build system for. For example, parsing some text format and translating it into binary, along with other similar tasks. Concrete (theoretical) example:

from myprog.meta import CompiledMetadata, MetadataParser
from myprog.cmdline import parse_cmdline

fn parse_metadata(file: StringRef) -> CompiledMetadata:
    with open(file) as f:
        let parser = MetadataParser(f)
        parser.validate()

        return parser.compile()


comptime BUILTIN_METADATA = parse_metadata("resources/meta.dat")

let cmdline = parse_cmdline()

let metadata
if cmdline.data_override is not None:
    metadata = parse_metadata(cmdline.data_override)
else:
    metadata = BUILTIN_METADATA
    # If we don't want to use the compiletime variable from above, this could also be written
    # metadata = comptime(parse_metadata("resources/meta.dat"))

This could even call into C libraries and so on and so on...

Compiletime conditions

The reason I personally prefer relying on the optimizer or guaranteeing that an if statement with only compiletime condition expression is evaluated at compiletime, is that it introduces less different constructs in the language.

A comptime if syntax would form a different construct from a runtime if. Also, forcing the prefix comptime for the entire if means you could not have something like if comptime(run_now()) and run_later(). So if it can be made possible to wrap arbitrary expressions in comptime, I think there should be no special case for if statements.

I would assume that an optimizer which can perform some static analysis and control flow tracking would also be capable of catching an if which has compiletime only expressions. Additionally, if wanted, the compiler could explicitly guarantee that if statements with only comptime expression always evaluate at compiletime.

Reasonably you could also expect that the following if statement is evaluated at compiletime (though no explicit guarantee is given):

let a = 5
let b = 5

if a + b == 10:
    print("Math works!")
else:
    print("The compiler needs to go back to school!")

If such an optimizer/analyzer feature is in place, comptime would only yield a strong guarantee but not really impact anything else.

[nmsmith]

On the topic of:
comptime if condition:
versus
if comptime(condition):

It would be nice to be able to unroll/eliminate for-loops at compile-time using the comptime keyword, in cases where the collection is known at compile-time, but the variables in the body of the loop are not known. (This is the equivalent of comptime if, for for-loops.) In my opinion, only the first syntax gives the strong suggestion that the for-loop is going to be eliminated:

comptime for x in list:
    # Do stuff at runtime

In contrast, the second syntax merely suggests that the collection will be computed at compile-time:

for x in comptime(computeList()):
    # Do stuff at runtime

The programmer needs to have a clear understanding of whether the loop is going to be unrolled. Because if the list is large, unrolling will have a (potentially enormous) negative effect on the code size, and the instruction cache! So, it seems that for-loops impose a design constraint on the placement of the comptime keyword.

comptime for is clear because it modifies the for keyword, and thus it implies that something will happen to the whole for-statement, not just the collection. This is not to say that we must go with the comptime if/for syntax. But if we don't, we will need to come up with another syntax.

I suppose another possible syntax is:
for comptime x in list:

This seems like it would compose well:

var total = foo()         # Evaluated at run-time
for comptime x in list:   # Unrolled  at compile-time
    comptime y = x * x    # Evaluated at compile-time
    total += bar(y)       # Evaluated at run-time

[Janrupf]

Hmm, thats indeed an interesting point - one route would be to go with the explicit guarantee that if a loop has a comptime condition that it is always unrolled. But that possibly might not be wanted, since, as you mentioned the list might be huge. I'm actually not sure how to solve this syntactically, but maybe a prefix is the right way to go then.

I suppose comptime for x in y() would imply comptime(y()), the same way comptime if y() would imply comptime(y()). So a possible legal (although not required syntax) would be comptime if comptime(func()).

[nmsmith]

To go a bit further, we could consider requiring comptime to be the very first token appearing on each line of compile-time code.

This approach would have a huge benefit: Mojo code would become visually divided into compile-time stuff and run-time stuff:

fn foo():
    ...
    comptime
    ...
    comptime
    comptime
    ...
    ...
    comptime

This gives readers a very clear understanding of what the code will look like after compilation: all the lines beginning with comptime will disappear. All of the remaining lines will execute at runtime (barring compiler optimizations), with any variables that were defined in a comptime context being substituted for their value.

The only exception being comptime blocks (if they are adopted). Every line of code in a comptime block would execute at compile-time.

This design prohibits comptime() expressions. Instead, you'd have to bind every expression to a comptime variable before using it. There would be no loss of expressivity — there would merely be an increase in verbosity. But perhaps it isn't worth being dogmatic about keeping comptime at the start of every line. Perhaps it's enough to just treat it as something nice-to-have as we ideate.

(Pertinent reminder: The final name for the comptime keyword is up for debate. We could optimize for a name that looks nice when placed at the start of every line.)

[augb]

@nmsmith & @Janrupf, thank you for your ideas; I think y'all both make some interesting arguments for expanding things beyond the scope of this particular RFC.

Would it make sense to continue that discussion in a separate thread?

I ask since my purpose with this RFC is more about some (hopefully) relatively minor, tactical changes to bring clarity closer to the current design and implementation. I certainly see value in the broader discussion.

[crisadamo]

This is great! I think it can be push a bit further and expand the concept to anything that happens at compile time, not only alias and @parameter.

[nmsmith]

@augb IMO the perspective that @Janrupf and I are taking encompasses everything you are looking for. We're proposing to unify the alias and @parameter constructs, just as you are. Our perspective differs from yours in that we believe it is necessary to discuss semantics, not just syntax, in order to unify them.

The principle is to have a singular construct that distinguishes compile-time from run-time, rather than an assortment of constructs such as alias and @parameter.

[augb]

@augb IMO the perspective that @Janrupf and I are taking encompasses everything you are looking for. We're proposing to unify the alias and @parameter constructs, just as you are. Our perspective differs from yours in that we believe it is necessary to discuss semantics, not just syntax, in order to unify them.

My perspective is that unifying alias and @parameter can be a foundation for the semantic changes y'all are seeking. Having said that, my intention is for simply unifying what is there already. I see y'all's approach as one that takes my proposal and dives deeper. Put another way, I see our approaches as being complimentary instead of in opposition. I hope that makes sense.

[augb]

As a reminder to everyone, this RFC is about eight words:

Unify alias and @parameter under a single keyword

While I am encouraged by the engaged response, substantive discussion about alternate approaches would be best served by creating a separate proposal.

This RFC was inspired by @lattner's comment in the original issue, specifically:

... Aligning this around "parameter" could be a good way to go, but I'm curious if there are other suggestions.

I would be curious to hear from the Mojo team and others their thoughts on these eight words.

[augb]

@augb I'm sorry, but it's simply not possible to talk about the alias and @parameter keywords without considering the larger context in which they exist — Mojo's metaprogramming system.

People don't write books by choosing words one-by-one. People aren't LLMs. Similarly, you can't design a programming language by debating its keywords one-by-one. You need to consider the language holistically. The right choice of keyword depends upon the feature it corresponds to. Consequently, we have spent some time discussing the feature, in order to better understand what keywords might be appropriate.

@nmsmith I'm not suggesting choosing words one-by-one. What I am interested in, specifically, is discussion surrounding the concept of, "unifying alias and @parameter under a single keyword". My purpose was a more 30,000 ft discussion (with some particularities, as appropriate) rather than a highly detailed break down of the meta-programming system design and possible future directions based on that break-down. I see value in this discussion as well, but feel like it might be better honored in a discussion tailored specifically for that level of detail. Due to the nature of GitHub, we can liberally link between issues, docs and other discussion topics to bring in relevant content from elsewhere.

I think my proposal is potentially a stepping stone to a much more detailed proposal along the lines of what you have discussed. I don't see them as mutually exclusive. I do see them as worthy of their own topics for discussion.

I am coming to the conclusion that what is meant by @parameter is really what is called a "typed parameter" in PEP695. Further, that this is something different than the plain vanilla term commonly used in programming called "parameter".

I mention this to say, that I think even before an in depth discussion of the nature you seem to be interested in, I feel a need to wrap my head around, and, hopefully, convey the need to clarify some pretty basic concepts.

I hope my explanation is helpful.

[augb]

@augb The Mojo devs call the following x and y arguments: fn foo(x: Int, y: Int)

And the following 3 and 4 arguments too: foo(3, 4)

As stated previously, I call x and y parameters. I call 3 and 4 arguments.

The term "parameter" is reserved for things that appear in square brackets. (Apart from when [] is used for arrays, of course.)

I understand the term "argument" to be the value that is passed into the "parameter" of a function call signature.

That is how I have used the terms in the past as well. Of course, this usage has always been a horrible butchering of the meaning of those terms in mathematics. (See here for the definition in mathematics. This definition predates the definition in computing.)

@nmsmith I think that just makes my point about conflating terms. Put another way, if a term is to be redefined (as stated in the Mojo docs; see quote below), then precision of terms becomes even more important. I feel there is work to be done in providing this precision surrounding "argument", "parameter", "alias", etc.

About “parameters”: Python developers use the words “arguments” and “parameters” fairly interchangeably for “things that are passed into functions.” We decided to reclaim “parameter” and “parameter expression” to represent a compile-time value in Mojo, and continue to use “argument” and “expression” to refer to runtime values. This allows us to align around words like “parameterized” and “parametric” for compile-time metaprogramming.

from "info" box as found in the Mojo docs emphasis added

[Mogball]

So I guess I'm trying to figure out what the benefits are to using parameter over comptime. Maybe if the Mojo team could share their thought process behind choosing to use the word "parameter", that might help guide any further discussion about keyword choice.

Mojo functions have parameters, and functions have arguments. We tried "meta-parameters" to make the distinction clear, but it doesn't really roll off the tongue. "Comptime parameters" doesn't sound much better. The term "parameter" originates from "search parameter", because Mojo functions can be multiply-instantiated based on these parameters, forking the compilation flow to search over multiple implementations of a function.

or does the concept of "parameterized" in Mojo mean something different than what "generic" usually means?

It does. Mojo functions can be parameterized, but they cannot be generic at the moment, because the language lacks other features to make that possible (traits).

The crucial difference is: it's actually possible to specialize a function to its parameters at runtime

Yeah, other systems like TVM and XLA share similar terminology.

[elliotwaite]

Thanks, all, for the discussion so far. It has helped me gain a better understanding of the word "parameter" and why it might be appropriate in this context.

We tried "meta-parameters" to make the distinction clear, but it doesn't really roll off the tongue.

This made me think that maybe meta could work 🤔, for meta-parameters and meta-programming. Also, it's short.

[nmsmith]

para is equally as short, and just like meta, it's a prefix with an appropriate meaning:

para-: beside, alongside, beyond

I can see meta working quite well though. It seems natural to talk about a meta var and a meta if.

[augb]

Thanks everyone for your contributions! The discussion has been quite helpful.

Here is a summary of where this stands from my perspective:

• Maybe a bit early to unify alias and @parameter under a single keyword.
• alias seems to be about named type parameter expressions (as opposed to common usage of the term "alias").
• Common usage of the term "alias" is about giving something another name/label.
• @parameter seems to be about type parameter expressions (as opposed to common usage of the term "parameter").
• Common usage of the term "parameter" is the part of a function or method call signature that receives in the passed in value (the "argument").
• By "common usage" I mean general accepted usage among programmers.
• Mojo docs seem to indicate that "type parameter expressions" are always compile-time. Given that types are typically determined at compile-time in statically compiled languages, I think this is a reasonable assumption that does not appear to go against commonly accepted understanding in programming circles.
• Conflating terms and imprecise definitions lead to confusion, especially among newbies. I would suggest that this discussion has highlighted that there can be confusion even among seasoned programmers.
• There does not seem to be a particular strong sentiment towards @parameter remaining as a decorator per se.
• There seems to be a growing consensus towards renaming alias and @parameter. There is less strength in the consensus on renaming alias than in renaming @parameter.
• Suggested options currently include (alphabetical order): compexp, comptime, const, meta and para. Of these, comptime seems to have the most votes thus far, though meta and para are very recent suggestions.

Given that it may be a bit early to unify these into a single keyword, I wonder if there would still be value in renaming alias and @parameter in the short-term? I would suggest that there is.

Given that an alias is really a named type parameter expression (I added the word "type"), I could see the following new suggestions: typealias, metaalias, and paraalias. Of these I prefer typealias.

Given that @parameter is really a type parameter expression (I added the word "type"), I could see the following new suggestions: @metaparam, @metaparameter, @paraparam, @paraparameter, @typeparam, and@typeparameter. Of these I prefer @typeparam.

I would be interested in y'all's thoughts and/or any corrections to my attempt at summarizing the state of this discussion thus far.

[DayDun]

If everything compile-time is referred to using parameter terminology, I'm sort of leaning towards alias being renamed to just param, to create a new parameter or something.

[augb]

alias is not just about types, they can contain arbitrary compile-time expressions

alias x: Int = 5 + 5
print(x)

alias: named parameter expressions

from Mojo docs

If a "parameter expression" is really a "type parameter expression" that is for compile-time use, then we can say that alias is a "named compile-time type parameter expression". If adding the word "type" here is taking it a bit too far then we can reduce it to just a "named compile-time expression" (dropping the words "type parameter").

I think the salient points about both alias and @parameter are:

• They both are compile-time,
• type-related,
• parameter expressions.

It could be argued that your example of alias x: Int = 5 + 5 is indeed a type expression. (alias is a compile-time association of a name to a type with a temporary value in this example.)

alias has the added concept of a name attached to it.

If we add the return parameter expression param_return[n] in one of your examples above, we can still say that it is a compile-time, type parameter expression used to return results.

Given that, all of the above (alias, @parameter and param_return) are all variations of compile-time expressions. Whether the words "type parameter" should be added or not could be debated, I guess. I think, technically, we can call alias a "named compile-time type parameter expression" without being incorrect. @parameter and param_return seem to fit this definition, as well, with the caveats that they are not named and param_return is related to returning results.

I think the fact that all of these "things" are compile-time is why many are leaning towards using comptime instead of @parameter or alias.

As a reminder, there could be a need for an alias keyword that is for use at runtime only.

Given the discussion thus far, I still think that the following should be changed one of two ways:

Approach 1 (where we keep the whole "parameter expression" terminology):

• alias -> typealias
• @parameter -> typeparam (make it a keyword)
• Bonus: param_return -> typeparam return (two keywords)

Approach 2 (where we go with the "compile-time" terminology as our focus):

• alias -> comptime
• @parameter -> @comptime (leave as a decorator for now to distinguish it from comptime until we can merge them into a single keyword)
• Bonus: param_return -> comptime return (two keywords)

Approach 2 is purposefully using comptime in all three instances. At a future date, @comptime would be merged into the comptime keyword.

Right now, I am leaning towards Approach 1. It keeps the alias and parameter concepts distinct as they are now. It also makes a typeparam be a typeparam with the added return keyword reinforcing that they are really the same thing logically, except one is used to return results.

[DayDun]

I don't see how they are type-related. In my example, the alias refers to the number 10, not a type. Parameters happen to also be able to store types, but that's a special case. More generally they can store any value (I believe types are technically values, just that they don't have a runtime representation). In the future, we might even be able to store types in runtime variables.

An alias keyword for runtime values is just let, is it not?

My opinion on approach 1:

• alias -> param
• @parameter I am sort of indifferent to. To me it isn't very clear what it even does, since you can call functions without the decorator in parameter expressions anyways.
• param_return I do feel is a bit weird. The reason stated in the changelog for adding it is to allow the function to throw while also returning a parameter. But couldn't that be achieved by just allowing some raise[x] Error() syntax and keeping the old return[x] y? It feels like param_return adds this unintuitive second layer of control flow to the function. What happens if you param_return twice before the real return?

Approach 2 I don't have much of an opinion on. But as @nmsmith pointed out in #218 (comment), it is important to keep in mind that parameter expressions could also be evaluated at runtime in special cases. So "compile-time" might not be the best terminology.

[DayDun]

Forgot about @parameter being used on if-statements 😅. I'm sort of on the fence about whether it should be a decorator or custom keyword / operator. On the one hand, it being a decorator would be a lot more consistent if there's also a bunch of other decorators you could apply on statements, including custom decorators. But if parameter statements are expected to be very heavily used, it could become quite verbose.

It doesn't really matter for the time being though. It is a purely syntactic difference and a decorator works just fine for now.

[augb]

I don't see how they are type-related.

You're right. I fell into a "mental trap" on that one. I've been hung up on the use of the word "parameter" in the definition of alias as found here:

alias: named parameter expressions

from Mojo docs

I think a more precise and correct definition as currently implemented is as follows:

alias: named compile-time expressions

... But as @nmsmith pointed out in #218 (comment), it is important to keep in mind that parameter expressions could also be evaluated at runtime in special cases. So "compile-time" might not be the best terminology.

So, perhaps "compile-time" is not the best choice here. I guess that would be up to the Mojo team to provide clarity on whether they expect this to be a possibility and/or their thoughts on the best term to replace "compile-time".

It is a bridge too far to say an alias is just a "named expression" since I cannot create an alias on a runtime value.

let z = 4;

alias y = z + 2

print(y)

This results in:

error: Expression [8]:5:11: use of unknown declaration 'z'
alias y = z + 2
          ^

(Note: I would not expect to be able to this given my understanding of how alias works.)

This does work, as expected:

alias a = 3;
alias y = a + 2

print(y)

resulting in:

5

[DayDun]

Also note that mojo has the less documented feature referred to as "result parameters" or "parameter results" for returning compile-time values:

fn main():
    fn f[a: Int, b: Int -> x: Int, y: Int]():
        param_return[a * 2, b * 4]

    alias a: Int
    alias b: Int
    f[2, 3 -> a, b]()
    print(a, b)

main()

The terminology here, and the param_return syntax should maybe also be considered.

[Janrupf]

I think this largely plays into what @nmsmith and I are talking about. While I understand the idea of this concept, if a proper MLIR interpreter is in place this would probably be better expressed using the following way:

fn main():
    fn f(a: Int, b: Int) -> (Int, Int):
        return ((a * 2), (b * 4))

    comptime (a, b): (Int, Int) = f(2, 3) # or alias (a, b)... or whatever keyword is being decided on
    print(a, b)

main()

This would render param_return obsolete, which seems to be very obscure anyway. The only thing that would go missing by removing param_return would be as far as I can tell the ability to have the same function return runtime as well as compiletime values.

[DayDun]

Yeah it is obscure, I can't think of any obvious cases where it would be useful.

I'm still unsure what I think of it, but it's definitely quite an interesting feature and I'm curious to explore it more. Would be neat to hear from Modular staff what their motivation was for it.

The case I'm thinking of where it might be a bit useful is:

fn combine[A: Int, B: Int -> R: Int](a: Vec[A], b: Vec[B]) -> Vec[R]:
    alias n = # ... non-trivial computation with A and B
    param_return[n]
    return # ... create a new Vec with length n

But it is a bit contrived. And you could probably just rewrite it to

@parameter
fn combine_len(a: Int, b: Int) -> Int:
    # ...

fn combine[A: Int, B: Int](a: Vec[A], b: Vec[B]) -> Vec[combine_len(A, B)]:
    alias n = combine_len(A, B)
    return # ... create a new Vec with length n

[Mogball]

I'm still unsure what I think of it, but it's definitely quite an interesting feature and I'm curious to explore it more. Would be neat to hear from Modular staff what their motivation was for it.

Shape functions, but also other things like buffer sizes.

In your example, the caller would have to repeat the same function call inside the Vec parameters if the caller wanted an explicit type or perform operations on the resultant parameter. It is a lot more naturally expressed with result parameters.

[Mogball]

alias seems to be about named type parameter expressions (as opposed to common usage of the term "alias")

alias is used to declare any compile time value. Types aren't special.

[augb]

My point about alias is that it is a named (compile time type) parameter expression. In other languages an alias is often used at runtime instead of compile time.

[nmsmith]

@augb The phrase "type parameter" doesn't mean what you think it means. A type parameter is a parameter whose value is a type. Similarly, a type variable is a variable whose value is a type. When I write:
alias x = 1
I am declaring a variable whose value is an integer. Thus, this is not a type variable.

In contrast, when I write:
alias x = Int

I am declaring a variable whose value is a type. This is a type variable.

The same applies for parameters. Consider:
fn foo[T: AnyType](..)

This is a function with a parameter whose value (once bound) will be a type. Thus, this is a type parameter.

In contrast, consider:
fn foo[x: Int](..)

This is a function with a parameter whose value (once bound) will be a specific integer (e.g. 2). Thus, this is not a type parameter. (It is merely a "parameter", to use Mojo's terminology.)

[augb]

Thanks, @nmsmith ... I think I fell into a variation of the "mental trap" you mentioned elsewhere. See my reply here. :)

[Janrupf]

I have decided as @augb requested to now split parts of this to #218, as it seems it may take way more discussion on the matter of how exactly this should work. To not block and interleave the discussion about alias and @parameter, this probably makes sense to discuss in the new RFC.

[augb]

Thanks, @Janrupf.

[sa-]

For what it's worth, the keyword compiled seems more elegant/readable than comptime.
It has the same number of letters to start with.
Being a teaching assistant for Intro to Python taught me that abbreviations scare beginners.
Beginners might not know what comp means.
When things are full words they are more accessible.
So to sum up my reasoning: compiled and comptime have the same number of characters, but compiled is more accessible.

[Janrupf]

I don't think compiled is a good idea - it gives the impression that a piece of code is compiled rather than some other mode of execution. However, all Mojo code is compiled (and not interpreted), so the keyword would be misleading.

[sa-]

This is also fair, although that criticism applies to comptime as well.

[augb]

This is my current understanding of alias, @parameter and param_return:

• alias currently seems to mean a "named compile-time expression". It can accept expressions that are not type parameters.
• @parameter is really a "compile-time type parameter expression" (type parameter similar to what is in PEP695).
• param_return is a "compile-time type parameter expression" that returns results.

If all of the above are true, that suggests the following:

• alias should stay as it is since it really is a different thing than both @parameter and param_return. (I'm okay with it not supporting runtime expressions.)
• @parameter likely should be renamed to @typeparam or something similar. (The word "parameter" clashes with standard usage.)
• param_return likely should be renamed to typeparam_return or something similar. (The abbreviation "param" clashes with standard usage.)
• Probably there is work that could be done to unify @parameter and param_return. (For example make the @parameter decorator become a new keyword typeparam that allows an if or a return keyword to follow and, then, drop the param_return keyword.)

Unless there is further discussion on this topic, I'll plan on closing this current discussion as outdated in the next day or so. Any substantive discussion on @parameter and param_return likely should be in its own new discussion.

Updated: Italicized words were added to clarify original intent.

[Mogball]

@parameter is a decorator used exclusively on if statements. @parameter if is essentially if constexpr (...) in C++. param_return also has nothing to do with type parameters. It specifies the parameter results of a function.

[augb]

Can you elaborate?

If it is not a type parameter, then what is it? a compile-time parameter?

[augb]

Thanks, @Mogball, for the concise explanation.

[nmsmith]

@augb do you have much experience with statically-typed languages? It seems at this point, the concept of a “type” may be the root of your confusion.

[augb]

@nmsmith, @Mogball has cleared up things up for me.