On Thu, Aug 25, 2016 at 2:09 PM, DrGo <salah.mah...@gmail.com> wrote: > Ok! So my original post was not clear. Let us say you just executed scan() > twice on this string: a= x > As expected, Scan() returned scanner.Ident for a, followed by a rune > indicating the = sign. > Now, peek() will return 32 for the space whereas scan() returns scanner.Ident > for the identifier x. Peek() essentially returns the next rune whereas scan() > returns the next token which may or may not be a rune, e.g., it could be an > identifierm an iinteger or an page-length raw string. > Finally, Next() advances the parser reading the next rune, so it is the > scanning equivalent of peek(). > My question, should not there be a func that is equivalent in behaviour to > scan() except that it doesn't advance the scanner?
Ah, I see what you're asking. I'm not sure that I have a good answer for that off the top of my head other than "that's not what Peek is for". Peeking at an entire token would be a waste of time and generally isn't something you need to do; peeking at a character (eg. is the next character a '<' or a '>' or are we at the end of a line, '\n') is more useful when rapidly scanning and lets us make common decisions earlier than we would otherwise need too while saving a scan call. I'm sure someone who knows more about lexing can provide you with a better answer though. —Sam -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
