I posted and realized that I basically created a long winded post about a Syntax section when I was really just trying to say that I feel like Syntax isn’t a good name for that section.
Sorry for not getting my point across the first time.
Azolo
rvirding
Creator of Erlang
Well, you save a whopping 2 characters if you use the keyword list instead of the do ... end. Unless you you have more than 1 expression and need parentheses.
0
rvirding
Creator of Erlang
Sorry, I don’t agree here. Most of the time it is completely irrelevant whether def is a keyword or a macro. I don’t need to know. Yes, you need to describe the alternative ways of writing a def, if, etc but at this stage it is really not necessary to explain why, a reference to a place where it is described is enough. And seriously while macros are cool and a lot of fun most users will not be defining their own macros, and those that do will need to read a section describing macros anyway.
And again the syntax reference section while it is correct is definitely not needed at this level. Worst case it can scare people off. Someone comes looking for a description of def and starts to wonder whether:
- Do I really need to know all stuff just to define a function?
- Does this mean I can write the expanded AST forms instead? (this is my thought anyway
)
1
rvirding
Creator of Erlang
Someone asked earlier about a BNF form. I don’t think this is necessary. Is it possible?
No, I think the level presented in the Erlang language spec is enough.
0
LostKobrakai
I’m of the same opinion. Providing knowledge about the differences between compile-time and run-time is nice in the beginning, knowing that there’s something called AST possibly as well, but explaining the internal data-structure of the AST is probably not to helpful to someone new to elixir. I mean they’re hardly going to work with the AST directly anytime soon if they struggle to get the syntax for defstruct correct, wondering why modules(-names) are atoms or what those _ in numbers do.
The more advanced explanations about the AST are in my opinion much better placed in the latter portion of such a reference. I mean it is part of the language and how it’s syntax works after all. It’s just not the first thing you need to know when trying to write elixir (for the first time).
1
josevalim
Creator of Elixir
We can easily break that page in two. We can start with the Syntax reference and then have an AST reference that goes over the same sections but containing AST information. This way you get the benefit of both in the same page but you can still learn the syntax without reading through the AST bits.
7
tmbb
I can’t find a spec that describes:
- All the literals (characters, integers and floats in different bases)
- Strings and everything you can put inside them. I know about
\c(normal escape)\xHH,\x{H*}and\uHHHH, but are there more? - all the size specs for binaries. For example, there are
<< a::size(i) >>and<< byte-size::byte-size(i) >>. But is there any reference for all of them?
This is quite irrelevant for my day-to-day coding (besides the binary pattern matching I don’t use any of these things), but I’m writing a syntax highlighting library in elixir. It’s almost a port of Pygments (a python library) to elixir. Without a good reference for what kinds of literals are supported it’s hard… I’ve been following the original Pygments lexer as a reference, but it has some mistakes (it lexes as valid things that are not valid Elixir syntax).
BTW, demo website for my (to be released) library: https://tmbb.github.io/makeup_demo/index.html
It’ll be called Makeup. Currently it highlights Elixir (badly, because of the points above) and HTML5 (better, but doesn’t highlight embedded CSS or JS yet). After releasing the library I’ll be asking for contributions of new lexers for other programming/markup languages
1
josevalim
Creator of Elixir
The Syntax Reference page above should include much of this information:
- The literals are currently documented there - we should probably reorganize that part of the document
- We should document strings escape chars - we will add that
- The binary bits not part of the syntax.
h <<>>will bring the information you need
0
tmbb
EDIT: you were referring to the whole document and not to a specific part.
Hm… Why do you say this is not part of the syntax? It’s certainly not a normal function or macro call… Those follow the syntax f(x1, x2, x3, ...). This clearly doesn’t. It’s not no an infix operator either.
0
