[go-nuts] compiler in golang

On Tuesday, 21 October 2014 19:07:49 UTC-4, [email protected] wrote:
Thanks. Are there any other options you prefer regarding the parser?

On Wednesday, October 22, 2014 1:42:51 PM UTC+13, [email protected] wrote:

A recursive descent parser is pretty straightforward. Most simple
languages are LL(1) or close enough.
There's a recursive descent parser for Go written in Go here you can use
as a guide:

http://golang.org/src/pkg/go/parser/parser.go

Go isn't LL(1) because infinite lookahead is required to distinguish
func(x, y, z int) from func(x, y, z), so the parseParameterList function
has to fix things up afterwards.

On Wed, Oct 22, 2014 at 2:25 PM, wrote:
"Go isn't LL(1) because infinite lookahead is required to distinguish
func(x, y, z int) from func(x, y, z)"

It is only one token of look ahead required to see the closing brace though?

On 21 October 2014 23:30, Nigel Tao wrote:

The ambiguity is, given only "func(x", is x a type or an argument? The
former looks like "func(x, y, z)", the latter looks like "func(x, y, z
T)". Resolving the ambiguity requires infinite lookahead. In
hindsight, it might have been better to always require a type for
every argument, so that it's "func(x T, y T, z T)" but Go 1 is what it
is.

On Tuesday, October 21, 2014 2:17:58 PM UTC-7, [email protected] wrote:

Hello,

Can someone suggest a lexer and parser generator like yacc to write a
compiler for a small domain specific language in golang?

Thank,
-Gerald

On Tuesday, 21 October 2014 20:02:16 UTC-4, Zellyn wrote:
I highly recommend Rob Pike's talk, "Lexical Scanning in Go," to, well,
everyone: http://youtu.be/HxaD_trXwRE

On Wed, Oct 22, 2014 at 10:35 AM, wrote:



I was confused by Rob's comments at 34'23" to the effect that the
goroutines created during initialization will not run until after
initialization is complete. There are no words to that effect in the spec,
nor does the runtime behave that way, as these example show:

http://play.golang.org/p/xU7eZD-MTF
http://play.golang.org/p/vY_cwweocZ

Indeed, it would be hard to imagine how this could be workable since it
would in effect establish a restricted dialect of Go for all code
potentially invoked during initialization.

What did he mean? Was this an earlier draft of the language?

cheers
alan

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

On Wednesday, October 22, 2014 1:02:16 PM UTC+13, Zellyn wrote:

I highly recommend Rob Pike's talk, "Lexical Scanning in Go," to, well,
everyone: http://youtu.be/HxaD_trXwRE

On Wed Oct 22 2014 at 8:28:12 PM wrote:

Regarding robs talk, I don't necessarily see the benefit in using higher
order functions to retain lexer state when you can just send tokens in a
channel and never lose state. You can have a recursive lexer that can park
state if you use channels.

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 [email protected].
For more options, visit https://groups.google.com/d/optout.

On Friday, October 24, 2014 12:44:18 AM UTC+13, Gustavo Niemeyer wrote:


You cannot use a channel without goroutines, and as mentioned earlier in
this thread you could not use goroutines during initialization back then.


On Wed Oct 22 2014 at 8:28:12 PM <[email protected] <javascript:>>
wrote:

On Tuesday, October 21, 2014 11:17:58 PM UTC+2, [email protected] wrote:
Can someone suggest a lexer and parser generator like yacc to write a

On Tue, Oct 21, 2014 at 11:17 PM, wrote:
Can someone suggest a lexer and parser generator like yacc to write a
compiler for a small domain specific language in golang?

On Tuesday, October 21, 2014 11:17:58 PM UTC+2, [email protected] wrote:
Can someone suggest a lexer