Thanks Sam, I managed without a token_peek(). It just leads to more verbose code with calls to scan() and switches everywhere.
On Thursday, August 25, 2016 at 10:52:54 PM UTC+1, Sam Whited wrote: > > On Thu, Aug 25, 2016 at 2:09 PM, DrGo <salah....@gmail.com <javascript:>> > 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.
