In this language, are you askin' how to maintain separate namespaces in symbol table, such that you can have foo(bar) and int(bar) be distinct, or do you want a parser lookahead type thing for it, or do you intend to have the function call syntax also be something different like the different casting is (assuming there's traditional things like function calls in this language) p.s. whats the dwelling name of the language in case we refer to it? im workin' on a custom shell called 'blush'
I'm a bit confused. I'm not working on any language right now. This entire article is specifically about C (Ambiguity in C). What makes you think I'm talking about another language? Furthermore, I don't know what you think I'm asking, but I only asked why some features in C were designed the way they are.
Yeah, that's just my personal preference. The main problem with that is the pointer casting syntax, which is another thing I asked if people know how to fix.
You have the situation where the compiler would need to assume you have a "name" and (NAME) in there (and it should give you a warning) however, if it is a valid type, now it shouldnt give you a warning, so i was just speaking to the multiple levels of compliance that would have to be corrected for to have it do what is effectively the opposite behavior.
i guess thats wat i was thinking then to ask, if you still would intend for there to be functions in traditional syntax, as well as casting in that same syntax.
In this hypothesis language, you would still have normal function call syntax `func(arg)` like C. You would probably change the declaration syntax to focus more on the name, and the cast syntax would be option 3 or 4. Even though I prefer option 2, I just couldn't see it working with pointer casting. In practice, the Odin programming language is closest to my preference, and it has both option 2 and 3 for casting.
thats interesting, ive not looked at the odin lang (i did once but it was like 10 years ago) ill check it out cause its prolly different than i have imagined in my head
Your not giving me a lot of room to respond... you are saying on one hand, i am making a mistake by offering opinions on this compare and contrast of what you yourself have called a hypothetical language.. im responding to your hypothetical... if youd prefer, i could just not respond and unsubscribe. im giving you thoughtful things, thuoughtful ideas, as well as pointing you in the direction of your question, and you keep saying "what makes you think im making a language" or "i think your confused", ive read everything youve said, and ive given you intelligible comments to read. Your hypothetical situation meant i wanted more information about the hypothetical landscape that you yourself have called a hypothetical language. If you didnt want any one to respond to it, such that NOTHING out of confusion could arise, you should have made an exclaimer, "DONT RESPOND", because thats the impression you are giving me, staggering me between "i think you are confused" and "im not talking about a language". Well, you are talking about a language, and im giving you my input on that language. Why do you want ppl to respond to you, if you dont think any of it is relevant? Thank you for wasting my time.
I'm not a native speaker, and I think you're reading more emotion than what I actually wrote.
What you've been saying isn't that related to this article, and that's one reason why I was confused. This article isn't really about programming languages in general. Like the name suggests, it's just about C's ambiguities and some of my hacky ways to solve them. The entire cast syntax discussion is literally just a small additional paragraph I quickly put in that isn't that meaningful or connected to the outside context. This article isn't On the Aesthetics of the Syntax of Casting.
Needless to say, this article's comment section is just not a suitable place for this discussion, partly because the article isn't about it, and partly because the comment section itself is not a good place to have an in-depth conversation. This, plus the weird way you were commenting (responding to one of my comments vs responding to the article), makes me feel like there's a disconnect between us.
With that out of the way, if you've said, let's have this discussion somewhere else, I would have agreed to have another conversation through DMs, emails, or some kind of back-and-forth articles. But getting extremely emotional, and accusing me of "wasting" your time, or expecting me to even have to reply to you at all, when I don't know you, nor owe you anything. I will conclude this here and wish you a lovely day.
I think you've misunderstood what that section meant. I was listing a couple of options and discussing the pros and cons of each. The same goes for the syntax of declaration.
(*Reading bout odin atm...*) it probably makes alot of sense in declarative languages, cause the flow of everything feels like its already encouraging that sortve reversal of everything (and then you have casting that continues into e.g, casting in function parameters) so its a paradigm that really wants to have that syntax going in that direction, though you can definitely just do whatever, and break out of that paradigm... i personally feel like, type annotation *(self contained function definitions— nd unified compilation)* vs function protoypes—though more verbose w/ LALR(1) parsing, in order to track/resolve declarations—the former is a little inferior in regards to not enforcing the upfront structure of a file (assuming its a well written file in C) alas, thats comparing it to what languages exist. but in the realm of infinite possibilities, there aint any reasons you couldnt have it *fixed* such that it behaves that way. the second option is gonna be unusual in the context of everything, but it could work... in other words, if the third option works, then the 2nd option works, since they are just staggered versions of each other (NAME int NAME) and (int NAME) w/ some parentheses thrown in
In this language, are you askin' how to maintain separate namespaces in symbol table, such that you can have foo(bar) and int(bar) be distinct, or do you want a parser lookahead type thing for it, or do you intend to have the function call syntax also be something different like the different casting is (assuming there's traditional things like function calls in this language) p.s. whats the dwelling name of the language in case we refer to it? im workin' on a custom shell called 'blush'
I'm a bit confused. I'm not working on any language right now. This entire article is specifically about C (Ambiguity in C). What makes you think I'm talking about another language? Furthermore, I don't know what you think I'm asking, but I only asked why some features in C were designed the way they are.
Oh my mistake. I saw something about wanting foo(bar) as cast syntax
Yeah, that's just my personal preference. The main problem with that is the pointer casting syntax, which is another thing I asked if people know how to fix.
Like, if u go to say:
```
green_eggs = and(ham); // This is a cast
```
You have the situation where the compiler would need to assume you have a "name" and (NAME) in there (and it should give you a warning) however, if it is a valid type, now it shouldnt give you a warning, so i was just speaking to the multiple levels of compliance that would have to be corrected for to have it do what is effectively the opposite behavior.
i guess thats wat i was thinking then to ask, if you still would intend for there to be functions in traditional syntax, as well as casting in that same syntax.
In this hypothesis language, you would still have normal function call syntax `func(arg)` like C. You would probably change the declaration syntax to focus more on the name, and the cast syntax would be option 3 or 4. Even though I prefer option 2, I just couldn't see it working with pointer casting. In practice, the Odin programming language is closest to my preference, and it has both option 2 and 3 for casting.
thats interesting, ive not looked at the odin lang (i did once but it was like 10 years ago) ill check it out cause its prolly different than i have imagined in my head
Your not giving me a lot of room to respond... you are saying on one hand, i am making a mistake by offering opinions on this compare and contrast of what you yourself have called a hypothetical language.. im responding to your hypothetical... if youd prefer, i could just not respond and unsubscribe. im giving you thoughtful things, thuoughtful ideas, as well as pointing you in the direction of your question, and you keep saying "what makes you think im making a language" or "i think your confused", ive read everything youve said, and ive given you intelligible comments to read. Your hypothetical situation meant i wanted more information about the hypothetical landscape that you yourself have called a hypothetical language. If you didnt want any one to respond to it, such that NOTHING out of confusion could arise, you should have made an exclaimer, "DONT RESPOND", because thats the impression you are giving me, staggering me between "i think you are confused" and "im not talking about a language". Well, you are talking about a language, and im giving you my input on that language. Why do you want ppl to respond to you, if you dont think any of it is relevant? Thank you for wasting my time.
I'm not a native speaker, and I think you're reading more emotion than what I actually wrote.
What you've been saying isn't that related to this article, and that's one reason why I was confused. This article isn't really about programming languages in general. Like the name suggests, it's just about C's ambiguities and some of my hacky ways to solve them. The entire cast syntax discussion is literally just a small additional paragraph I quickly put in that isn't that meaningful or connected to the outside context. This article isn't On the Aesthetics of the Syntax of Casting.
Needless to say, this article's comment section is just not a suitable place for this discussion, partly because the article isn't about it, and partly because the comment section itself is not a good place to have an in-depth conversation. This, plus the weird way you were commenting (responding to one of my comments vs responding to the article), makes me feel like there's a disconnect between us.
With that out of the way, if you've said, let's have this discussion somewhere else, I would have agreed to have another conversation through DMs, emails, or some kind of back-and-forth articles. But getting extremely emotional, and accusing me of "wasting" your time, or expecting me to even have to reply to you at all, when I don't know you, nor owe you anything. I will conclude this here and wish you a lovely day.
i read it
one more quick question; would you want to have multiple ways to cast, or do you just want ; one option out of those 3— (preferrably the 2nd)?
I think you've misunderstood what that section meant. I was listing a couple of options and discussing the pros and cons of each. The same goes for the syntax of declaration.
(*Reading bout odin atm...*) it probably makes alot of sense in declarative languages, cause the flow of everything feels like its already encouraging that sortve reversal of everything (and then you have casting that continues into e.g, casting in function parameters) so its a paradigm that really wants to have that syntax going in that direction, though you can definitely just do whatever, and break out of that paradigm... i personally feel like, type annotation *(self contained function definitions— nd unified compilation)* vs function protoypes—though more verbose w/ LALR(1) parsing, in order to track/resolve declarations—the former is a little inferior in regards to not enforcing the upfront structure of a file (assuming its a well written file in C) alas, thats comparing it to what languages exist. but in the realm of infinite possibilities, there aint any reasons you couldnt have it *fixed* such that it behaves that way. the second option is gonna be unusual in the context of everything, but it could work... in other words, if the third option works, then the 2nd option works, since they are just staggered versions of each other (NAME int NAME) and (int NAME) w/ some parentheses thrown in