Nick!
Nick!
PostsComments
MModular
Created by AM on 4/22/2024 in #questions
effects system?
I/O can be modelled as reading and/or mutating a data source, so IMO it falls into the “tracking mutation” bucket.
4 replies
MModular
Created by AM on 4/22/2024 in #questions
effects system?
Different people mean different things when they say “effect system”. In your mind, what does an effect system do, and how would it improve Mojo? Mojo already tracks exceptions in function signatures. It also tracks some kinds of mutation (argument mutation), and it will track additional kinds of mutation once references are finalized.
4 replies
MModular
Created by Grandimam on 4/12/2024 in #questions
Transfer operator inside constructor and moveinit
@Grandimam Actually, that's not the full story. When the ^ sigil is used in expressions of the form y = x^, it triggers the invocation of the move constructor (__moveinit__) on x. (So in the program you posted, the move constructor that is being defined calls another move constructor.) In other words, the ^ operator has two distinct purposes: - To signal that the lifetime of a variable will end. - To invoke __moveinit__, when it is used in expressions of the form y = x^.
11 replies
MModular
Created by Arvin_David on 4/16/2024 in #questions
Future of Literals. Are they going to be removed?
Strings stored in alias variables are not mutable
11 replies
MModular
Created by Arvin_David on 4/16/2024 in #questions
Future of Literals. Are they going to be removed?
@Maxim You can also have an immutable String with a static lifetime that is known at compile-time. That’s basically what alias does. I don’t think StringLiteral helps with that.
11 replies
MModular
Created by artemiogr97 on 4/14/2024 in #questions
Optional string argument
The reason your program is rejected is that multiple conversion steps are required to get from a StringLiteral to an Optional[String]. Mojo is unlikely to ever support a multi-step chain of implicit conversions, so the question is ultimately whether there is a principled way to move between the two types via a single conversation step. The constructor for Optional obviously cannot accept a StringLiteral or a Stringable because Optional isn't necessarily parameterized by the type String, but perhaps at some point there will be a principled way to add a constructor overload for Optional[String] in particular. (This can be achieved via Swift-style "extension methods".)
17 replies
MModular
Created by Stijn on 4/1/2024 in #questions
Parameters style guide
Perhaps this should be raised as a Github issue
11 replies
MModular
Created by Stijn on 4/1/2024 in #questions
Parameters style guide
I was also on the verge of starting a discussion about this. It's nice to know I'm not the only one irked by it. Another problem with using PascalCase for values is that it makes it impossible to use the naming scheme name: Name or size: Size for parameters, which is very common and useful. This is probably the biggest issue tbh, because it will force programmers to spend time coming up with clunkier or more verbose names. (It goes without saying that more descriptive names are sometimes a better choice, but this is context-dependent. Oftentimes the most descriptive name possible is merely the type name.)
11 replies
MModular
Created by Yinon Burgansky on 3/29/2024 in #questions
Returning a reference from a factory
As a side comment: the return type -> Foo doesn't imply that the return value will be stored on the stack, nor does it imply that the return value will be copied. If the type is @register_passable, then it will be returned in a register (which is not the stack). Otherwise, the function will receive a memory address (as an implicit argument) from the caller. This is the address that the return value will be written to. It could be on the stack, or on the heap. The function isn't able to tell the difference. So as I said, it's complicated 🥲. Over time, the Mojo docs will explain how all of this works.
10 replies
MModular
Created by Yinon Burgansky on 3/29/2024 in #questions
Returning a reference from a factory
@Yinon Burgansky The answer is: "it's complicated". Over time, I expect the Mojo docs will explain all of these concepts adequately. If you want to learn more about how to write programs while having detailed control over heap versus stack allocation, copying vs. reference-passing etc, I would recommend learning Rust. There are tons of high-quality tutorials on Rust, including how memory is managed. Mojo will handle memory quite similarly. (But not exactly the same.)
10 replies
MModular
Created by Yinon Burgansky on 3/29/2024 in #questions
Returning a reference from a factory
Why would you want to write such a function? You can just return a String itself; there is no need to return a reference to it.
10 replies
MModular
Created by benny on 3/15/2024 in #questions
Type independent traits
There’s also a notion of “associated types” (see Rust and Swift) which avoids the need for the trait to be parametrised.
14 replies
MModular
Created by benny on 3/15/2024 in #questions
Type independent traits
I’m not sure what distinction you’re making. Your struct can inherit from that trait multiple times with a different parameter, if you want to have multiple __contains__ functions.
14 replies
MModular
Created by benny on 3/15/2024 in #questions
Type independent traits
@benny I think what you want is a generic trait, i.e. the following: 
trait Container[T: AnyType]:
    fn __contains__(self, item: T) -> Bool:
        ...
struct List(Container[Int]):
trait Container[T: AnyType]:
    fn __contains__(self, item: T) -> Bool:
        ...
struct List(Container[Int]):
Mojo doesn't support this yet, but it's in the works.
14 replies
MModular
Created by jorge on 3/4/2024 in #questions
Mojo implementation question regarding borrow checker
The current implementation of the Reference type is just a WIP and is subject to change.
5 replies
MModular
Created by jorge on 3/4/2024 in #questions
Mojo implementation question regarding borrow checker
@jorge To directly answer your question: Mojo's borrowing system is unfinished, and there's not much you can study right now. I would check back in 3-6 months.
5 replies
MModular
Created by Henk-Jan Lebbink on 2/29/2024 in #questions
How to tell Mojo that something is intended to be constant?
@Henk-Jan Lebbink Regarding your last comments, I am always trying to challenge my beliefs and take on new persectives as I learn new languages and develop as a programmer. Up until a few years ago, I was a major proponent of immutability and whatnot, but now I am more on the fence. Sometimes general principles (e.g. "immutability is better") don't hold up in all situations, so it's worth reflecting on each particular issue and trying to gauge just how important it is for a principle to be upheld in that setting. At the end of the day, what matters is whether programmers are actually going to be negatively affected in any shape or form by not having a keyword for local variable immutability. And while I agree with most people in this thread that it feels comforting to declare a variable as immutable, it's quite possible that this comforting feeling is just a result of my prior exposure to programming cultures wherein people tended to praise immutability quite heavily. So personally, I'm going to give Modular the benefit of the doubt (they have a lot of experience with programming languages), and see what a var-only world feels like. Will I ever encounter a bug that could have been prevented via a judicious use of let? I'm not actually sure. But I will find out with experience.
71 replies
MModular
Created by Henk-Jan Lebbink on 2/29/2024 in #questions
How to tell Mojo that something is intended to be constant?
sure
71 replies
MModular
Created by Henk-Jan Lebbink on 2/29/2024 in #questions
How to tell Mojo that something is intended to be constant?
Or put another way: it is always wrong to use an uninitialized variable, but it is basically always correct to use a mutated variable
71 replies
MModular
Created by Henk-Jan Lebbink on 2/29/2024 in #questions
How to tell Mojo that something is intended to be constant?
No. The compiler needs to enforce initialization because that is required for memory safety. In contrast, immutability is not required to ensure memory safety.
71 replies