|
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!
|
|
|
|
|
Maximilien wrote: (except the last chapter IMO).
Don't spoil how it ends!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
it ends with a ".".
I'd rather be phishing!
|
|
|
|
|
..sigh. We had that information on how to create that for some years now, but economics is more important. We've been "hackable" also for quite some time, even on a massive scale; that's how advertising works. And no, not every corporation in the game uses algorithms.
The total surveillance system is already in place 
Anything else that's "new"?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Anything else that's "new"?
Not while you are wearing those glasses.
«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
|
|
|
|
|
Hi All,
Looking forward to the weekend! I am praying to the relevant powers that nothing I am responsible for blows up! 
|
|
|
|
|
for mine weekends start early on Friday afternoons.
anything blows up I'll take a look at the crater / ashes on Monday when I get there.
here less than 2 hours of Friday left, already caught up most personal email, bills etc
bit of relaxed browsing and coffee drinking before going to bed is all that's left.
Message Signature
(Click to edit ->)
|
|
|
|
|
Quote: coffee drinking before going to bed
I bet that's black friday coffee 
|
|
|
|
|
|
On a more (or less) serious note, I have been using Visustin for years to create code graphs ('as-built' flowcharts). It does cost money, however 
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
|
|
|
|
|
That rings a bell from long gone VB days when .NET did not exist yet and we were all merry and happy in our little VB world
|
|
|
|
|
True, that. But Visustin is still alive and works with somewhere around 60 languages now I think. I still use it for 'as-built' flowcharts of C# and VB.Net Yes, I admit it: I still work with VB when the client demands it. Shoot, I am still working on conversions of Visual FoxPro to C#: much of the Florida Sheriff and Tax Collector software was (and still is) Visual FoxPro.
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
|
|
|
|
|
You are right, Visustin deserves a place in this list: code-visualization-and-analysis-tools[^]
I have worked with Visual Foxpro too, it was fine until they decided to release a Windows version 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
