I'm experimenting with creating a semi-natural scripting language, mostly for my own learning purposes, and for fun. The catch is that it needs to be in native C#, no parsing or lexical analysis on my part, so whatever I do needs to be able to be done through normal syntactical sugar.
I want it to read somewhat like a sentence would, so that it is easy to read and learn, especially for those that aren't especially fluent with programming, but I also want the full functionality of native code available to the user.
For example, in the perfect world it would look like a natural language (English in this case):
When an enemy is within 10 units of player, the enemy attacks the player
In C#, allowing a sentence like this to actually do what the scripter intends would almost certainly require that this be a string that is run through a parser and lexical analyzer. My goal isn't that I have something this natural, and I don't want the scripter to be using strings to script. I want the scripter to have full access to C#, and have things like syntax highlighting, intellisense, debugging in IDE, etc. So what I'm trying to get it something that reads easily, but is in native C#. A couple of the major hurdles that I don't see a way to overcome is getting rid of periods ., commas ,, and parentheses for empty methods (). For example, something like this is feasible but doesn't read very cleanly:
// C#
When(Enemy.Condition(Conditions.isWithinDistance(Enemy, Player, 10))), Event(Attack(Enemy, Player))
Using a language like Scala you can actually get much closer, because periods and parentheses can be replaced by a single whitespace in many cases. For example, you could take the above statement and make it look something like this in Scala:
// Scala
When(Enemy is WithinDistance(Player, 10)) => Then(Attack From(Enemy, Player))
This above code would actually compile assuming you setup your engine to handle it, in fact you might be able to coax further parentheses and commas out of this. Without the syntactical sugar in the above example it would be more like this, in Scala:
// Scala (without syntactical sugar)
When(Enemy.is(WithinDistance(Player, 10)) => Then(Attack().From(Enemy, Player))
The bottom line is I want to get as close as possible to something like the first scala example using native C#. It may be that there is really nothing I can do, but I'm willing to try any tricks that may be possible to make it read more natural, and get the periods, parentheses, and commas out of there (except when they make sense even in natural language).
I'm not as experienced with C# as other languages, so I might not know about some syntax tricks that are available, like macros in C++. Not that macros would actually be a good solution, they would probably cause more problems then they would solve, and would be a debugging nightmare, but you get where I'm going with this, at least in C++ it would be feasible. Is what I'm wanting even possible in C#?
Here's an example, using LINQ and Lambda expressions you can sometimes get the same amount of work done with fewer lines, less symbols, and code the reads closer to English. For example, here's an example of three collisions that happen between pairs of objects with IDs, we want to gather all collisions with the object that has ID 5, then sort those collisions by the "first" ID in the pair, and then output the pairs. Here is how you would do this without LINQ and/or Lambra expressions:
struct CollisionPair : IComparable, IComparer
{
public int first;
public int second;
// Since we're sorting we'll need to write our own Comparer
int IComparer.Compare( object one, object two )
{
CollisionPair pairOne = (CollisionPair)one;
CollisionPair pairTwo = (CollisionPair)two;
if (pairOne.first < pairTwo.first)
return -1;
else if (pairTwo.first < pairOne.first)
return 1;
else
return 0;
}
// ...and our own compable
int IComparable.CompareTo( object two )
{
CollisionPair pairTwo = (CollisionPair)two;
if (this.first < pairTwo.first)
return -1;
else if (pairTwo.first < this.first)
return 1;
else
return 0;
}
}
static void Main( string[] args )
{
List<CollisionPair> collisions = new List<CollisionPair>
{
new CollisionPair { first = 1, second = 5 },
new CollisionPair { first = 2, second = 3 },
new CollisionPair { first = 5, second = 4 }
};
// In a script this would be all the code you needed, everything above
// would be part of the game engine
List<CollisionPair> sortedCollisionsWithFive = new List<CollisionPair>();
foreach (CollisionPair c in collisions)
{
if (c.first == 5 || c.second == 5)
{
sortedCollisionsWithFive.Add(c);
}
}
sortedCollisionsWithFive.Sort();
foreach (CollisionPair c in sortedCollisionsWithFive)
{
Console.WriteLine("Collision between " + c.first +
" and " + c.second);
}
}
And now the same example with LINQ and Lambda. Notice in this example we don't have to both with making CollisionPair both IComparable and IComparer, and don't have to implement to the Compare and CompareTo methods:
struct CollisionPair
{
public int first;
public int second;
}
static void Main( string[] args )
{
List<CollisionPair> collisions = new List<CollisionPair>
{
new CollisionPair { first = 1, second = 5 },
new CollisionPair { first = 2, second = 3 },
new CollisionPair { first = 5, second = 4 }
};
// In a script this would be all the code you needed, everything above
// would be part of the game engine
(from c in collisions
where ( c.first == 5 || c.second == 5 )
orderby c.first select c).ForEach(c =>
Console.WriteLine("Collision between " + c.first +
" and " + c.second));
}
In the end we're left with a LINQ and Lambda expression that read closer to natural language, and are much less code for both a game engine and for the script. These kinds of changes are really what I'm looking for, but obviously LINQ and Lambda are both limited to specific syntax, not something as generic as I would like in the end.
Another approach would be to use FluentInterface "pattern", implement something like:
When(enemy).IsWithin(10.units()).Of(player).Then(enemy).Attacks(player);
If you make the functions like When, IsWithin, Of, Then return some interfaces, then you will be able easily add new extension methods to expand your rules language.
For example let's take a look at function Then:
public IActiveActor Then(this ICondition condition, Actor actor) {
/* keep the actor, etc */
}
public void Attacks(this IActiveActor who, Actor whom) {
/* your business logic */
}
In the future it would be easy to implement another function, say RunAway() without changing anything in your code:
public void RunAway(this IActiveActor who) {
/* perform runaway logic */
}
so it with this little addition you will be able to write:
When(player).IsWithin(10.units()).Of(enemy).Then(player).RunAway();
Same for conditions, assuming When returns something like ICheckActor, you can introduce new conditions by simply defining new functions:
public ICondition IsStrongerThan(this ICheckActor me, Actor anotherGuy) {
if (CompareStrength(me, anotherGuy) > 0)
return TrueActorCondition(me);
else
return FalseActorCondition(me);
}
so now you can do:
When(player)
.IsWithin(10.units()).Of(enemy)
.And(player).IsStrongerThan(enemy)
.Then(player)
.Attacks(enemy);
or
When(player)
.IsWithin(10.units()).Of(enemy)
.And(enemy).IsStrongerThan(player)
.Then(player)
.RunAway();
The point is that you can improve your language without experiencing heavy impact on the code you already have.
Honestly I don't think this is a good direction for a language. Take a look at AppleScript sometime. They went to great pains to mimic natural language, and in trivial examples you can write AppleScript that reads like English. In real usage, it's a nightmare. It's awkward and cumbersome to use. And it's hard to learn, because people have a very hard time with "just write this incredibly limited subset of English with no deviations from the set pattern." It's easier to learn real C# syntax, which is regular and predictable.
I don't quite understand your requirement of "written in native C#". Why? Probably you want it to be written in native .NET? I can understand this as you can compile these rules written in "plain English" into .NET with no parsing etc. Then your engine (probably written in C#) will be able to use these rules, evaluate them, etc. Just because it is all .NET, doesn't really matter which language developer used.
Now, if C# is not really a requirement, then we can stop figuring out how to make "ugly-ugly" syntax look "just ugly" :)
We can look at, for example, F#. It compiles into .NET in the same way C# or VB.NET do, but it is more suitable for solving problems like yours.
You gave us 3 (ugly looking) examples in C# and Scala, here is one in F# I managed to write from the top of my head in 5 minutes:
When enemy (within 10<unit> player) (Then enemy attacks player)
I only spent 5 minutes, so probably it can be even prettier.
No parsing is involved, When, within, Then, attacks are just normal .NET functions (written in F#).
Here is all the code I had to write to make it possible:
[<Measure>] type unit
type Position = int<unit>
type Actor =
| Enemy of Position
| Player of Position
let getPosition actor =
match actor with
| Enemy x -> x
| Player x -> x
let When actor condition positiveAction =
if condition actor
then positiveAction
else ()
let Then actor action = action actor
let within distance actor1 actor2 =
let pos1 = getPosition actor1
let pos2 = getPosition actor2
abs (pos1 - pos2) <= distance
let attacks victim agressor =
printfn "%s attacks %s" (agressor.GetType().Name) (victim.GetType().Name)
This is really it, not hundreds and hundreds of lines of code you would probably write in C# :)
This is a beauty of .NET: you can use appropriate languages for appropriate tasks. And F# is a good language for DLS (just what you need here)
P.S. You can even define functions like "an", "the", "in", etc to make it look more like English (these functions will do nothing but return their first argument):
let an something = something
let the = an
let is = an
Good luck!
Related
I'm trying to implement syntax highlighting in C# on Android, using Xamarin. I'm using the ANTLR v4 library for C# to achieve this. My code, which is currently syntax highlighting Java with this grammar, does not attempt to build a parse tree and use the visitor pattern. Instead, I simply convert the input into a list of tokens:
private static IList<IToken> Tokenize(string text)
{
var inputStream = new AntlrInputStream(text);
var lexer = new JavaLexer(inputStream);
var tokenStream = new CommonTokenStream(lexer);
tokenStream.Fill();
return tokenStream.GetTokens();
}
Then I loop through all of the tokens in the highlighter and assign a color to them based on their kind.
public void HighlightAll(IList<IToken> tokens)
{
int tokenCount = tokens.Count;
for (int i = 0; i < tokenCount; i++)
{
var token = tokens[i];
var kind = GetSyntaxKind(token);
HighlightNext(token, kind);
if (kind == SyntaxKind.Annotation)
{
var nextToken = tokens[++i];
Debug.Assert(token.Text == "#" && nextToken.Type == Identifier);
HighlightNext(nextToken, SyntaxKind.Annotation);
}
}
}
public void HighlightNext(IToken token, SyntaxKind tokenKind)
{
int count = token.Text.Length;
if (token.Type != -1)
{
_text.SetSpan(_styler.GetSpan(tokenKind), _index, _index + count, SpanTypes.InclusiveExclusive);
_index += count;
}
}
Initially, I figured this was wise because syntax highlighting is largely context-independent. However, I have already found myself needing to special-case identifiers in front of #, since I want those to get highlighted as annotations just as on GitHub (example). GitHub has further examples of coloring identifiers in certain contexts: here, List and ArrayList are colored, while mItems is not. I will likely have to add further code to highlight identifiers in those scenarios.
My question is, is it a good idea to examine tokens rather than a parse tree here? On one hand, I'm worried that I might have to end up doing a lot of special-casing for when a token's neighbors alter how it should be highlighted. On the other, parsing will add additional overhead for memory-constrained mobile devices, and make it more complicated to implement efficient syntax highlighting (e.g. not re-tokenizing/parsing everything) when the user edits text in the code editor. I also found it significantly less complicated to handle all of the token types rather than the parser rule types, because you just switch on token.Type rather than overriding a bunch of Visit* methods.
For reference, the full code of the syntax highlighter is available here.
It depends on what you are syntax highlighting.
If you use a naive parser, then any syntax error in the text will cause highlighting to fail. That makes it quite a fragile solution since a lot of the texts you might want to syntax highlight are not guaranteed to be correct (particularly user input, which at best will not be correct until it is fully typed). Since syntax highlighting can help make syntax errors visible and is often used for that purpose, failing completely on syntax errors is counter-productive.
Text with errors does not readily fit into a syntax tree. But it does have more structure than a stream of tokens. Probably the most accurate representation would be a forest of subtree fragments, but that is an even more awkward data structure to work with than a tree.
Whatever the solution you choose, you will end up negotiating between conflicting goals: complexity vs. accuracy vs. speed vs. usability. A parser may be part of the solution, but so may ad hoc pattern matching.
Your approach is totally fine and pretty much what everybody's using. And it's totally normal to fine tune type matching by looking around (and it's cheap since the token types are cached). So you can always just look back or ahead in the token stream if you need to adjust actually used SyntaxKind. Don't start parsing your input. It won't help you.
I ended up choosing to use a parser because there were too many ad hoc rules. For example, although I wanted to color regular identifiers white, I wanted types in type declarations (e.g. C in class C) to be green. There ended up being about 20 of these special rules in total. Also, the added overhead of parsing turned out to be miniscule compared to other bottlenecks in my app.
For those interested, you can view my code here: https://github.com/jamesqo/Repository/blob/e5d5653093861bc35f4c0ac71ad6e27265e656f3/Repository.EditorServices/Internal/Java/Highlighting/JavaSyntaxHighlighter.VisitMethods.cs#L19-L76. I've highlighted all of the ~20 special rules I've had to make.
I want to check If my OCR result (a string) is either "No Edge" or "No Signal".
Problem is sometimes I would get N0 Edge, No Signa1, N0 signa1, No 5ignal, etc. The letter o, S, i and l can sometimes become digits or something else. Unfortunately there is nothing else I can do regarding the OCR.
Currently I am doing this:
ocrResult = ocrResult.ToLower();
if (ocrResult.Contains("edg") || ocrResult.Contains("gna"))
{
//no edge or no signal
}
else
{
//Not no edge or no signal
}
Can any of you please suggest a smarter approach?
There's a library called Simila which is designed for such scenarios:
In Simila you can have this:
// A similarity engine which accepts similar if similarity is more than 70%
var simila = new Simila() { Treshold = 0.7 };
if (simila.AreSimilar(ocrResult, "No Edge") || simila.AreSimilar(ocrResult, "No Signal"))
{
// ...
}
A simple documentation of Simila is available here:
https://github.com/mehrandvd/Simila/wiki
FYI, I'm working on it and it is still in beta version. Let me know if an early release helps you, so I can create an early beta release for you.
If what you are doing works just keep doing it, it's simple, easy to understand and scanning a 9 letter string twice isn't likely to cause performance issues unless you have really big data sets.
Just add a comment so that someone who looks at this code years from now know why you are looking for seemingly random substrings.
If this isn't working then what you are looking for is a "classification algorithm" (Wikipedia list's 79 of them) - but they can get complex and choosing the right one can be tricky so they truly an overkill if simple string comparison does the job.
Well the .lower is slower then a comparison that ignores the case. Certainly if u use it in a loop. So at first i recommend you do a comparison that ignores the case. For readability and maintainability i advice u refactor the comparison. And finally u should check if the string is empty or null, then u do not have to compare the string.
Example:
if (IsThereNoEdgeOrNoSignal(ocrResult))
{
//no edge or no signal
}
else
{
//Not no edge or no signal
}
private static bool IsThereNoEdgeOrNoSignal(string ocrResult)
{
if (string.IsNullOrEmpty(ocrResult))
return false;
return ocrResult.IndexOf("edg", StringComparison.CurrentCultureIgnoreCase) >= 0 || ocrResult.IndexOf("gna", StringComparison.CurrentCultureIgnoreCase) >= 0;
}
if it only stays to these two strings, then you should keep it this way, does it grows with more possibilities you should check it with a regular expression.
I hope this helps u.
For all you compiler gurus, I wanna write a recursive descent parser and I wanna do it with just code. No generating lexers and parsers from some other grammar and don't tell me to read the dragon book, i'll come around to that eventually.
I wanna get into the gritty details about implementing a lexer and parser for a reasonable simple language, say CSS. And I wanna do this right.
This will probably end up being a series of questions but right now I'm starting with a lexer. Tokenization rules for CSS can be found here.
I find my self writing code like this (hopefully you can infer the rest from this snippet):
public CssToken ReadNext()
{
int val;
while ((val = _reader.Read()) != -1)
{
var c = (char)val;
switch (_stack.Top)
{
case ParserState.Init:
if (c == ' ')
{
continue; // ignore
}
else if (c == '.')
{
_stack.Transition(ParserState.SubIdent, ParserState.Init);
}
break;
case ParserState.SubIdent:
if (c == '-')
{
_token.Append(c);
}
_stack.Transition(ParserState.SubNMBegin);
break;
What is this called? and how far off am I from something reasonable well understood? I'm trying to balance something which is fair in terms of efficiency and easy to work with, using a stack to implement some kind of state machine is working quite well, but I'm unsure how to continue like this.
What I have is an input stream, from which I can read 1 character at a time. I don't do any look a head right now, I just read the character then depending on the current state try to do something with that.
I'd really like to get into the mind set of writing reusable snippets of code. This Transition method is currently means to do that, it will pop the current state of the stack and then push the arguments in reverse order. That way, when I write Transition(ParserState.SubIdent, ParserState.Init) it will "call" a sub routine SubIdent which will, when complete, return to the Init state.
The parser will be implemented in much the same way, currently, having everything in a single big method like this allows me to easily return a token when I found one, but it also forces me to keep everything in one single big method. Is there a nice way to split these tokenization rules into separate methods?
What you're writing is called a pushdown automaton. This is usually more power than you need to write a lexer, it's certainly excessive if you're writing a lexer for a modern language like CSS. A recursive descent parser is close in power to a pushdown automaton, but recursive descent parsers are much easier to write and to understand. Most parser generators generate pushdown automatons.
Lexers are almost always written as finite state machines, i.e., like your code except get rid of the "stack" object. Finite state machines are closely related to regular expressions (actually, they're provably equivalent to one another). When designing such a parser, one usually starts with the regular expressions and uses them to create a deterministic finite automaton, with some extra code in the transitions to record the beginning and end of each token.
There are tools to do this. The lex tool and its descendants are well known and have been translated into many languages. The ANTLR toolchain also has a lexer component. My preferred tool is ragel on platforms that support it. There is little benefit to writing a lexer by hand most of the time, and the code generated by these tools will probably be faster and more reliable.
If you do want to write your own lexer by hand, good ones often look something like this:
function readToken() // note: returns only one token each time
while !eof
c = peekChar()
if c in A-Za-z
return readIdentifier()
else if c in 0-9
return readInteger()
else if c in ' \n\r\t\v\f'
nextChar()
...
return EOF
function readIdentifier()
ident = ""
while !eof
c = nextChar()
if c in A-Za-z0-9
ident.append(c)
else
return Token(Identifier, ident)
// or maybe...
return Identifier(ident)
Then you can write your parser as a recursive descent parser. Don't try to combine lexer / parser stages into one, it leads to a total mess of code. (According to the Parsec author, it's slower, too).
You need to write your own Recursive Descent Parser from your BNF/EBNF. I had to write my own recently and this page was a lot of help. I'm not sure what you mean by "with just code". Do you mean you want to know how to write your own recursive parser?
If you want to do that, you need to have your grammar in place first. Once you have your EBNF/BNF in place, the parser can be written quite easily from it.
The first thing I did when I wrote my parser, was to read everything in and then tokenize the text. So I essentially ended up with an array of tokens that I treated as a stack. To reduce the verbosity/overhead of pulling a value off a stack and then pushing it back on if you don't require it, you can have a peek method that simply returns the top value on the stack without popping it.
UPDATE
Based on your comment, I had to write a recursive-descent parser in Javascript from scratch. You can take a look at the parser here. Just search for the constraints function. I wrote my own tokenize function to tokenize the input as well. I also wrote another convenience function (peek, that I mentioned before). The parser parses according to the EBNF here.
This took me a little while to figure out because it's been years since I wrote a parser (last time I wrote it was in school!), but trust me, once you get it, you get it. I hope my example gets your further along on your way.
ANOTHER UPDATE
I also realized that my example may not be what you want because you might be going towards using a shift-reduce parser. You mentioned that right now you are trying to write a tokenizer. In my case, I did write my own tokenizer in Javascript. It's probably not robust, but it was sufficient for my needs.
function tokenize(options) {
var str = options.str;
var delimiters = options.delimiters.split("");
var returnDelimiters = options.returnDelimiters || false;
var returnEmptyTokens = options.returnEmptyTokens || false;
var tokens = new Array();
var lastTokenIndex = 0;
for(var i = 0; i < str.length; i++) {
if(exists(delimiters, str[i])) {
var token = str.substring(lastTokenIndex, i);
if(token.length == 0) {
if(returnEmptyTokens) {
tokens.push(token);
}
}
else {
tokens.push(token);
}
if(returnDelimiters) {
tokens.push(str[i]);
}
lastTokenIndex = i + 1;
}
}
if(lastTokenIndex < str.length) {
var token = str.substring(lastTokenIndex, str.length);
token = token.replace(/^\s+/, "").replace(/\s+$/, "");
if(token.length == 0) {
if(returnEmptyTokens) {
tokens.push(token);
}
}
else {
tokens.push(token);
}
}
return tokens;
}
Based on your code, it looks like you are reading, tokenizing, and parsing at the same time - I'm assuming that's what a shift-reduce parser does? The flow for what I have is tokenize first to build the stack of tokens, and then send the tokens through the recursive-descent parser.
If you are going to hand code everything from scratch I would definately consider going with a recursive decent parser. In your post you are not really saying what you will be doing with the token stream once you have parsed the source.
Some things I would recommend getting a handle on
1. Good design for your scanner/lexer, this is what will be tokenizing your source code for your parser.
2. The next thing is the parser, if you have a good ebnf for the source language the parser can usually translate quite nicely into a recursive decent parser.
3. Another data structure you will really need to get your head around is the symbol table. This can be as simple as a hashtable or as complex as a tree structure that can represent complex record structures etc. I think for CSS you might be somewhere between the two.
4. And finally you want to deal with code generation. You have many options here. For an interpreter, you might simply interpret on the fly as you parse the code. A better approach might be to generate a for of i-code that you can then write an iterpreter for, and later even a compiler. Of course for the .NET platform you could directly generate IL (probably not applicable for CSS :))
For references, I gather you are not heavy into the deep theory and I do not blame you. A really good starting point for getting the basics without complex, code if you do not mind the Pascal that is, is Jack Crenshaw's 'Let's build a compiler'
http://compilers.iecc.com/crenshaw/
Good luck I am sure you are going to enjoy this project.
It looks like you want to implement a "shift-reduce" parser, where you explicitly build a token stack. The usual alternative is a "recursive descent" parser, in which depth of procedure calls build the same token stack with their own local variables, on the actual hardware stack.
In shift-reduce, the term "reduce" refers to the operation performed on the explicitly-maintained token stack. For example, if the top of the stack has become Term, Operator, Term then a reduction rule can be applied resulting in Expression as a replacement for the pattern. The reduction rules are explicitly encoded in a data structure used by the shift-reduce parser; as a result, all reduction rules can be found in the same spot of the source code.
The shift-reduce approach brings a few benefits compared to recursive-descent. On a subjective level, my opinion is that shift-reduce is easier to read and maintain than recursive-descent. More objectively, shift-reduce allows for more informative error messages from the parser when an unexpected token occurs.
Specifically, because the shift-reduce parser has an explicit encoding of rules for making "reductions," the parser is easily extended to articulate what sorts of tokens could legally have followed. (e.g., "; expected"). A recursive descent implementation cannot easily be extended to do the same thing.
A great book on both kinds of parser, and the trade-offs in implementing different kinds of shift-reduce is "Introduction to Compiler Construction", by Thomas W. Parsons.
Shift-reduce is sometimes called "bottom-up" parsing and recursive-descent is sometimes called "top-down" parsing. In the analogy used, nodes composed with highest precedence (e.g., "factors" in multiplication expression) are considered to be "at the bottom" of the parsing. This is in accord with the same analogy used in "descent" of "recursive descent".
If you want to use the parser to also handle not-well-formed expressions, you really want a recursive descent parser. Much easier to get the error handling and reporting usable.
For literature, I'd recommend some of the old work of Niklaus Wirth. He knows how to write. Algorithms + Data Structures = Programs is what I used, but you can find his Compiler Construction online.
Is there a C# library that provides the functionality of ">>" and "<<" for IO in C++? It was really convenient for console apps. Granted not a lot of console apps are in C#, but some of us use it for them.
I know about Console.Read[Line]|Write[Line] and Streams|FileStream|StreamReader|StreamWriter thats not part of the question.
I dont think im specific enough
int a,b;
cin >> a >> b;
IS AMAZING!!
string input = Console.ReadLine();
string[] data = input.split( ' ' );
a = Convert.ToInt32( data[0] );
b = Convert.ToInt32( data[1] );
... long winded enough? Plus there are other reasons why the C# solution is worse. I must get the entire line or make my own buffer for it. If the line im working on is IDK say the 1000 line of Bells Triangle, I waste so much time reading everything at one time.
EDIT:
GAR!!!
OK THE PROBLEM!!!
Using IntX to do HUGE number like the .net 4.0 BigInteger to produce the bell triangle. If you know the bell triangle it gets freaking huge very very quickly. The whole point of this question is that I need to deal with each number individually. If you read an entire line, you could easily hit Gigs of data. This is kinda the same as digits of Pi. For Example 42pow1048576 is 1.6 MB! I don't have time nor memory to read all the numbers as one string then pick the one I want
No, and I wouldn't. C# != C++
You should try your best to stick with the language convention of whatever language you are working in.
I think I get what you are after: simple, default formatted input. I think the reason there is no TextReader.ReadXXX() is that this is parsing, and parsing is hard: for example: should ReadFloat():
ignore leading whitespace
require decimal point
require trailing whitespace (123abc)
handle exponentials (12.3a3 parses differently to 12.4e5?)
Not to mention what the heck does ReadString() do? From C++, you would expect "read to the next whitespace", but the name doesn't say that.
Now all of these have good sensible answers, and I agree C# (or rather, the BCL) should provide them, but I can certainly understand why they would choose to not provide fragile, nearly impossible to use correctly, functions right there on a central class.
EDIT:
For the buffering problem, an ugly solution is:
static class TextReaderEx {
static public string ReadWord(this TextReader reader) {
int c;
// Skip leading whitespace
while (-1 != (c = reader.Peek()) && char.IsWhiteSpace((char)c)) reader.Read();
// Read to next whitespace
var result = new StringBuilder();
while (-1 != (c = reader.Peek()) && !char.IsWhiteSpace((char)c)) {
reader.Read();
result.Append((char)c);
}
return result.ToString();
}
}
...
int.Parse(Console.In.ReadWord())
Nope. You're stuck with Console.WriteLine. You could create a wrapper that offered this functionality, though.
You can Use Console.WriteLine , Console.ReadLine ..For the purpose.Both are in System NameSpace.
You have System.IO.Stream(Reader|Writer)
And for console: Console.Write, Console.Read
Not that I know of. If you are interested of the chaining outputs you can use System.Text.StringBuilder.
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder(VS.71).aspx
StringBuilder builder = new StringBuilder();
builder.Append("hello").Append(" world!");
Console.WriteLine(builder.ToString());
Perhaps not as pretty as C++, but as another poster states, C# != C++.
This is not even possible in C#, no matter how hard you try:
The left hand side and right hand side of operators is always passed by value; this rules out the possibility of cin.
The right hand side of << and >> must be an integer; this rules out cout.
The first point is to make sure operator overloading is a little less messy than in C++ (debatable, but it surely makes things a lot simpler), and the second point was specifically chosen to rule out C++'s cin and cout way of dealing with IO, IIRC.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What are ‘closures’ in .NET?
I am currently looking at lambda expression and the word closure keeps coming. Can someone explain it to me in real simple language.
I'd say this is a duplicate of: What are ‘closures’ in .NET?
"In essence, a closure is a block of code which can be executed at a later time, but which maintains the environment in which it was first created - i.e. it can still use the local variables etc of the method which created it, even after that method has finished executing."
Your shoes are in the hall; your
jacket is in the kitchen. Put them
on, and your gloves (they're in the
drawer), when going outside.
Now you can go playing with your cars.
At eleven o'clock you must go buy some
bread in the corner store.
Kid plays. Forgets all the world.
Alarm clock goes off; kid sees: eleven o'clock! Oh - go outside to buy bread using the "going outside" closure.
I like the Google example for Javascript (you can morph it for C# easily). It's not something a 5 year old would understand but then I doubt an average 5 year old would understand what a function was.
/*
* When a function is defined in another function and it
* has access to the outer function's context even after
* the outer function returns
* An important concept to learn in Javascript
*/
function outerFunction(someNum) {
var someString = 'Hai!';
var content = document.getElementById('content');
function innerFunction() {
content.innerHTML = someNum + ': ' + someString;
content = null; // IE memory leak for DOM reference
}
innerFunction();
}
The below answer was to the original wording which was akin to "How to explain closures to a 5-year old."
Take this box of legos; build yourself
a nice little space craft. When you go
to billy's house and bring your space
craft there; with closures you can
still can use all the pieces in your
box of legos, even though the box was left
in your bedroom.
If you really need to keep it simple, then a closure is a function with its context. The function in the closure can still access the same variables it could when it was defined, no matter where you call it from. (In Lua, these are called upvalues, which I think is a very descriptive term.)
I met the concept first in Lua, and this definition helped me understand the concept. Maybe have a look at Lua: its simpleness and power is fascinating, and certainly helps to develop a certain view at other languages. Its concept of closures would be a good example to that.
If the 5 year old knew C#, I would explain with this code sample:
int i = 0;
string result = null;
Action iExaminer = () =>
{
result = i % 2 == 1 ? "Odd" : "Even";
};
i = 1;
iExaminer();
Console.WriteLine(result);
If the 5 year old was learning linq, I would explain with this code sample:
string name = null;
IEnumerable<Customer> query = Customers.Where(c => c.Name == name);
name = "Bob";
// query is resolved when enumerated (which is now)
// Where will now call our anonymous method.
foreach(var customer in query)
{
Console.WriteLine(customer.Name);
}
Closure (computer science) says:
In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.
Translation:
Closures close/attach the variables around the function, so that that function can be teleported to somewhere else and still use those variables
e.g. suppose you are teleported to a remote location but have still access to your coffed mug lying on your table
Example:
function makefunc(x)
{
return function(){return x}
}
Now using makefunc, you can make many anonymous functions which will return what you pass to makefunc
So if you want a function which returns 10, use makefunc(10)(), though pretty useless way toget back 10 :)
When you know how to do something in general, you can specify some (or all) details and get a closure.
For example, you know how to buy ice-cream. Yyou know what to do if you will be in front of any shop. But if you want to go to a particular shop (for example, due to a Sunday discount), you move out of house with the aim of buying ice-cream there. "Buy some ice-cream at a store on the corner" is a closure of "buy some ice-cream". In fact, all these are closures of "buy some ice-cream somewhere":
Buy some ice-cream at the corner
Buy two ice-creams
Buy two ice-creams at the corner
Now go play with your friends, son! (and I bear in mind not say anything like that in front of the children)
This is a simple approach to the idea in C#: Closure