Skip to content
This repository has been archived by the owner on Sep 20, 2021. It is now read-only.

doc : improve explanation on namespace #69

Open
Grummfy opened this issue Jun 2, 2017 · 8 comments
Open

doc : improve explanation on namespace #69

Grummfy opened this issue Jun 2, 2017 · 8 comments

Comments

@Grummfy
Copy link
Member

Grummfy commented Jun 2, 2017

When I read the following topics http://discourse.hoa-project.net/t/hoa-compiler-keyword-identifier-clash/252 I can understand that namespace permit to avoid collision between namespace but also to isolate each namespace (correct?).

So it could be intresting to add a section in the namespace documentation about that, on the why using namespace and they purpose with a good example ;)


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@Hywan
Copy link
Member

Hywan commented Jun 2, 2017

There is already a section for that, https://hoa-project.net/En/Literature/Hack/Compiler.html#Namespaces.

Thoughts?

@Grummfy
Copy link
Member Author

Grummfy commented Jun 2, 2017

Indeed, I don't know if it's new or if I don't understand it at first. But honestly for me it was not clear when I read this doc (and I read it several times ...)

@Hywan
Copy link
Member

Hywan commented Jun 2, 2017

Is it clear now?

@Grummfy
Copy link
Member Author

Grummfy commented Jun 2, 2017

it seems, I will re-read it and close the issue if it is. Otherwise I will try to suggest something.

@KurtAhn
Copy link

KurtAhn commented Jun 14, 2017

I know this was supposed to be an issue on namespace documentation, but since it was related to my forum post, I wanted to make a suggestion for documentation on lexer mechanism. The lexer behaviour is sometimes mysterious if you haven't looked at the source to see this:

#\G(?|<regex>)#<option> (from line 277 in Lexer.php)

After that point, you can specify your tokens with the help of an online regex parser, but I don't think it's obvious at all without this knowledge.

@Hywan
Copy link
Member

Hywan commented Jun 14, 2017

The \G(?|…) construction should not have any impact on your regular expression definitions. Was it a source of a bug on your side?

@KurtAhn
Copy link

KurtAhn commented Jun 14, 2017

I think the problem was with space characters. After reading your post, I tried replicating problems I had (or thought I had), but I wasn't able to. What I noticed instead was this:

%skip space \s
%token boolean true|false
//%token boolean true | false

The first boolean token works as expected, while the second one doesn't. Maybe I'm just being dumb, but I think the spacing behaviour is a little weird if you don't know exactly how the parser generator works. If you specify spaces to be skipped, isn't it natural to think spaces don't matter in token specification? I guess what I'm saying is I didn't know the lexer would just take true | false part and embed it into the \G(?|...) expression without more preprocessing before passing it through a regex engine, and that became clear only after I looked at the source.

SerafimArts added a commit to railt/compiler that referenced this issue Jan 6, 2018
@flip111
Copy link

flip111 commented Jan 25, 2019

@Grummfy what is your opinion about the documentation at the moment?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

4 participants