Fix up do-while.md

plans/do-while.md

@@ -7,7 +7,7 @@ if <condition1> do {
 }
 while <condition2> do {
 	<block2>
-}}
+}
 ```
 
 In this example, if `condition1` is true, then `block1` will be executed at least once, and will be repeated while `condition2` is true, and `block2` will be executed once, no matter whether or not `condition2` is true, or maybe more times if you have another while loop after it as well.
@@ -54,6 +54,6 @@ From what I see, there are a few ways that I can solve this.
    ```
    where you are checking the truthiness of your instance of `MyStruct`.
 3. I could just require parentheses around the condition. Honestly, though, I don't really want to, because I just like the aesthetic of not needing parentheses around conditions. So I probably won't do this.
-4. Change how struct instantiation works syntactically. I could just use `(` and `)`  instead of `{` and `}`, so `MyStruct(arg1=val1, arg2=val2, ...)`. But honestly, I don't like this for the same reason as the previous fix. However, just as I am writing this, I think I have come up with the solution. `.`. A single period would seperate the type and the open curly brace. So `MyStruct.{arg1=val1, arg2=val2, ...}`. Honestlty, I think that this will be what I go with. It also allows me to solve my problem concerning the types of array literals. I'm currently doing some very weird stuff with emtpy variable types, and using the first element to indicate the type of the rest, which isn't always ideal if the first element is a subtype of the type you want for the array, and it's just a whole ordeal, which I think that this syntax can solve. I can do something like Jai (I think it does this? I haven't checked) where you prepend the array with the type, and then a period, so `int.[0, 1, 2, 3]`. This wpill also allow you to indicate whether or not integer literals should be interpreted as floats for example. I think that if you tried to create an array of floats using integer literals, it wouldn't work, and you would have to do something like putting a `.0` at the end of all the integers. Back on the topic of the period, this syntax is basically already being used for Enums, where you have to specify the type and then the member, and I had always been planning on allowing the type to be not provided, if the context was enough to deduce what enum type was being returned, for example, if you are in a function the language can use the return type to deduce the type. I can now also extend this idea to structs and arrays, where you don't need to specify the type if it is determined by something like the return type of a function or something else. I guess there would just a few rinckles to iron out depending on what kind of expression is allowed to the left of the period. I will probably have to make type expressions just regular expressions (i.e. normal expressions, not RegEx), and then have it check when parsing if the expression to the left of the period is a type expression. The same check will also have to be done in type declarations in function arguments and what-not. I think out of all the paths forward, this will be what I will do, if I ever come back to this language.
+4. Change how struct instantiation works syntactically. I could just use `(` and `)`  instead of `{` and `}`, so `MyStruct(arg1=val1, arg2=val2, ...)`. But honestly, I don't like this for the same reason as the previous fix. However, just as I am writing this, I think I have come up with the solution. `.`. A single period would seperate the type and the open curly brace. So `MyStruct.{arg1=val1, arg2=val2, ...}`. Honestlty, I think that this will be what I go with. It also allows me to solve my problem concerning the types of array literals. I'm currently doing some very weird stuff with emtpy variable types, and using the first element to indicate the type of the rest, which isn't always ideal if the first element is a subtype of the type you want for the array, and it's just a whole ordeal, which I think that this syntax can solve. I can do something like Jai (I think it does this? I haven't checked) where you prepend the array with the type, and then a period, so `int.[0, 1, 2, 3]`. This wpill also allow you to indicate whether or not integer literals should be interpreted as floats for example. I think that if you tried to create an array of floats using integer literals, it wouldn't work, and you would have to do something like putting a `.0` at the end of all the integers. Back on the topic of the period, this syntax is basically already being used for Enums, where you have to specify the type and then the member, and I had always been planning on allowing the type to be not provided, if the context was enough to deduce what enum type was being returned, for example, if you are in a function the language can use the return type to deduce the type. I can now also extend this idea to structs and arrays, where you don't need to specify the type if it is determined by something like the return type of a function or something else. I guess there would just a few rinckles to iron out depending on what kind of expression is allowed to the left of the period. I will probably have to make type expressions just regular expressions (i.e. normal expressions, not RegEx), and then have it check when parsing if the expression to the left of the period is a type expression. The same check will also have to be done in type declarations in function arguments and what-not. I think out of all the paths forward, this will be what I will do, if I ever come back to this language. Ultimately, though, this is just syntax bikeshedding, and there are certainly more important things that I should be focusing on at the moment if I want to get this language into a functional state.
 
-I haven't worked on this lanaguage in like half a year or so, and I only really came back to check it out because I started learning to use emacs, and I just wanted to explore my old projects through emacs. I will probably not work on it soon, but once everything that is taking up my time has been dealt with, I plan on working on the language further. As you can probably tell from the opening of this, I wrote this without really checking whether or not what I wrote was true. This problem with `do`-`while` just came to me as a random thought, and I just decided to write this markdown file as some documentation for my future self in case I ever came back to this langauge. I think it was certainly productive, because throughout the course of writing this, I think I came across something even better for the langauge, inspired by Jai. I originally wanted this language to be at the same level as python, as this langauge came out of my frustrations with python, but on the whole I think I now want this language to be closer to where c/rust/jai are, but I will need to do a lot of work to get there. The current state of the project (which, like I said, has been untouched for half a year) is currently nowhere near that, and is, like originally planned, closer to where python is, especially with how it deals with dicts and lists. There is currently no memory management at all, and you can't even decide the size of ints. So yeah, this project has a long way to go.
+I haven't worked on this lanaguage in like half a year or so, and I only really came back to check it out because I started learning to use emacs, and I just wanted to explore my old projects through emacs. I will probably not work on it soon, but once everything that is taking up my time has been dealt with, I plan on working on the language further. As you can probably tell from the opening of this, I wrote this without really checking whether or not what I wrote was true. This problem with `do`-`while` just came to me as a random thought, and I just decided to write this markdown file as some documentation for my future self in case I ever came back to this langauge. I think it was certainly productive, because throughout the course of writing this, I think I came across something even better for the langauge, inspired by Jai. I originally wanted this language to be at the same level as python, as this langauge came out of my frustrations with python, but on the whole I think I now want to eventually make this language closer to c/rust/jai, but I will need to do a lot of work to get there. The current state of the project (which, like I said, has been untouched for half a year) is currently nowhere near that, and is, like originally planned, closer to where python is, especially with how it deals with dicts and lists. There is currently no memory management at all, and you can't even decide the size of ints. So yeah, this project has a long way to go.