|
I agree with SuperLloyd in that discussion. Context is everything.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Message analysis complete.
Found 1 error in "I agree with SuperLloyd" on line 1 column 0.
Suggested fix: change "SuperLloyd" to "Sander".
Compilation failed.
|
|
|
|
|
I admire your self confidence. When even the compiler disagrees with you, you know you've won.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm so confident I file a bug report when the compiler refuses to compile MY code
Inspired by Chuck Norris, who doesn’t get compiler errors, the language changes itself to accommodate.
Seriously though, style is (somewhat) important and I think your question is a great example of how having consistent styling can make reading code so much more easy
You're probably wondering because you somehow need to parse/lex/tokenize it, in which case the other person was right, you write for compilers (maybe that's what he meant)
|
|
|
|
|
That's because Chuck Norris doesn't code in C++, C++ codes in Chuck Norris.
Style is important and if I had my way I'd make my little parser enforce my own naming conventions as it would be a bit easier on me.
But I'm not here for that. I'm here for you and I each being able to use this thing how we want, even while fighting with each other over how to use it properly.
I used to use hungarian notation. Now I've evolved to not bother with that, and instead focus on other things because of tools like intellisense. I always try to code in a way that works well with the tools I use and that looks at home with the tools I use.
That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions than my C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase.
Context is everything.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: That's why I adopt different naming styles and even coding guidelines depending on context. My C++ library code uses different conventions than my other C++ code which uses different conventions I could agree there if I (and my team) always used the same tools.
Which I (and formerly, we) do, so my style is adjusted to VS2012+.
If I sometimes used VS2019 and other times VS Code and they somehow had different styles then I'd still stick with one style.
honey the codewitch wrote: C# code which uses different conventions than my java code, etc. My XML naming styles are different depending on context, and json naming style tends to be camelCase That's just common sense.
Or did you think me some barbarian who uses PascalCasing in JavaScript as well!?
I've seen JavaScript written like it was C# and it really hurts the senses
|
|
|
|
|
We at least agree on that much, bracing notwithstanding
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Privates get lower-case; all others get Pascal casing,
|
|
|
|
|
Some languages do use casing to differentiate between different classes of name. Haskell requires types to start with an upper-case letter, values (and functions are just values of course) to start with a lower-case letter and if you stray away from that, a compiler error is raised. Rust has a convention with similar rules, but raises a warning not an error if you break it.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
and i otherwise love haskell but i'm not a fan of that.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It is the C# equivalent of FUBAR.
It means, just like the body bags coming from Vietnam, do not open. (the Class)
|
|
|
|
|
I have a suspicion that C++ is equally reliant (possibly more so when you get templates involved) on type information
int a(int x) { return x + 1; }
auto b = [](int y) -> int { return y + 1; };
struct C {
int operator()(int z) const { return z + 1; }
};
C c;
class D {
int d(int x) const { return x + 1; }
static int e(int x) { return x + 1; }
public:
void do_stuff(int a_number) {
a_number = a(a_number);
a_number = b(a_number);
a_number = c(a_number);
a_number = d(a_number);
a_number = e(a_number);
y = a_number;
}
int y;
};
5 'callable things', all of which meet the C++20 invocable concept, but are of different types (Yes, d can only be called as if it has one parameter from the context of a method of D or a derived class, but that's the example context I've used!).
And then if you use if constexpr , that will also impact how you interpret the program:
template<uint32_t Offset, uint32_t Size>
struct bit_field_t {
: :
: :
auto get_value(uint32_t from_field) {
if constexpr (Size == 1) {
return (field & (1<<Offset)) == (1<<Offset);
}
else {
return (field>>Offset) & ((1<<Size)-1);
}
}
};
In this case, the value of the template parameter Size (which forms part of the type of instances of bit_field_t ) determines the return type of the method get_value .
Unfortunately, that's just the way it is with strongly/statically typed languages unless you have some pretty strict rules about only using things that have already been declared, so you always have the necessary type information to tag nodes in your AST/code dom. For example, I think OCaml has a single pass parser, and it requires you to explicitly denote recursion, whether direct or indirect, a classic case where languages aren't always sure if the thing you're referring to has already been defined. (note that these functions are strongly typed, but OCaml has a sophisticated type inference engine that doesn't need (but will accept) explicit type annotations to derive types):
let rec fac (n:int): int =
match n with
| 1 -> 1
| x -> x * fac x
(* even and odd are inferred to have type int -> int *)
let rec even n =
match n with
| 0 -> true
| x -> odd (x-1)
and odd n =
match n with
| 0 -> false
| x -> even (x-1)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Action<string> fooAction ...
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
if you're suggesting my naming conventions aren't any good in the example I'd agree. The point however, is that it needs to parse regardless, or it's not C#
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
"I know C family languages require type information to parse (which is unfortunate) but C# takes it to another level. in for a penny, in for a pound I guess."
Static typing allows you to avoid runtime errors, its loads faster and much easier to find what is part of what. Sounds like you're coming from javaScript which teaches you how to think about things very wrong.
A delegate in C# is a multicast-delegate in that when it invokes, its actually invoking a generated method that invokes the first function pointer, then the next and so on. It will always use virtual dispatch and can't be inlined. Don't use delegates for everything and only use them for what they're actually meant for.
modified 2-Dec-19 15:18pm.
|
|
|
|
|
No. I have a c++ background. I'm not talking about static versus dynamic, versus duck typing. I'm talking about parsing, an entirely different thing.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
It might be my fault. Let's see if I can explain better:
Say I'm parsing C# and I encounter the following:
Console.WriteLine(Int32.MaxValue);
My parser can interpret Console as a field, property, method, variable or type. Any one of them is valid here, but we can't know which it is without having type information during the parse.
Similarly:
Also WriteLine (Int32.MaxValue) could be a delegate invoke on a field, or property reference, or it could be a method call. You can't know during the parse without type information.
That's what i mean by needing type information during the parse.
It's not that strong typing is bad. It's that requiring type information during a parse dramatically complicates parsing.
What I do, is I create multiple trees on a single parse, and then resolve which tree it is after i have the type information for it. Some other parsers (like microsoft's research C# GLR parser) do that too, but it's not easy.
The other option is to preparse, but only up to the member definitions (ignoring method bodies and such) and then parsing again once you have all that info.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Not something I've thought about much but Is this for a lesson you can't use Roslyn for?
I'm not sure how Roslyn handles using-static/type-aliases.
using static System.Console;
namespace MyNamespace
{
class Program
{
private delegate void WriteLineFunc();
private static WriteLineFunc WriteLine;
static void Main(string[] args)
{
WriteLine();
{
{
}
So if a local, field/method isn't found mark the AST node as un-resolved or add it to an un-resolved list. Then after all files are parsed go through the un-resolved nodes and try to resolve them through the aliased types. Then you don't have to parse over and over if my thinking is correct.
|
|
|
|
|
That's pretty much what I'm doing.
I'm using the codedom as my ast.
Every root member ref (like "foo" in foo.bar ) becomes a "variable reference" with "slang:unresolved" as one of it's "user-data" keys so I can find it later.
Every other member ref, like "bar" in the above is considered a field reference by default, also marked with "slang:unresolved"
later on, I revisit the AST after the parse, find each of these nodes, get the scope from where I'm at and use the type information I now have to replace these "slang:unresolved" items with the appropriate references.
It has served me well so far.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
In C#, property, method or function names usually begin with a capital letter, whereas local variables should begin with a small letter and private member names with a prefix like "_" or "m". In C#, it is particularly important to stick to these unwritten conding rules in order to make the answer to your question more obvious:
foo should be a local variable.
But still, if you see
Foo("bar"); then Foo could be a public property name. So you can never be sure.
|
|
|
|
|
I didn't mention it, but the question was asked in context of a C# parser. How would it know what to parse without type information?
It was to illustrate the complexity of the parsing of C#.
The whole thing is a bit of nightmare.
I recently wrote this - Slang Part 1: Parsing a C# Subset into the CodeDOM[^]
to parse it, and i had to do backtracking and tree resolution with type and context info after the parse. I thought C was bad with parsing casts and pointer ops vs type*'s.
Guess I didn't entirely get that point across, so my bad, but there it is.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
A strange CNN interview with Yuval Harari (Ph.D. Oxford), author of the best-selling "Sapiens: A Brief History of Humankind:" [^].
I've been reading "Sapiens," but, so far have not found it nearly as interesting as Timothy Taylor's 2010 "The Artificial Ape: How Technology Changed the Course of Human Evolution."
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
what a strange idea this evolution is.
Message Signature
(Click to edit ->)
|
|
|
|
|
And what does he says about it ? I started the book a while back and stop reading for one reason or the other (I want to get back to it).
I just finished "21 lessons for the 21st century" and it was a entertaining read (except the last chapter IMO).
I'd rather be phishing!
|
|
|
|