Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
December 28, 2015 Implementing a Programming Language in D: Lexical Analysis | ||||
---|---|---|---|---|
| ||||
http://blog.felixangell.com/implementing-a-programming-language-in-d-part-1/ https://www.reddit.com/r/programming/comments/3ykko7/implementing_a_programming_language_in_d_lexical/ https://news.ycombinator.com/item?id=10802610 (Go through the front page, not this link, or your votes won't count) |
December 28, 2015 Re: Implementing a Programming Language in D: Lexical Analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 12/28/2015 04:28 PM, Walter Bright wrote: > https://www.reddit.com/r/programming/comments/3ykko7/implementing_a_programming_language_in_d_lexical/ Although the author does not use many D idioms, I've just learned (re-learned?) anonymous enums from that code. I've realized that with a nested anonymous enum, there is no need to (and no way of) mentioning the enum type inside a user-defined type. This can simplify the implementation: struct S { enum { value } void foo() { // Look ma, no type: assert(value == 0); } } void main() { // Properly name-spaced outside of the struct: assert(S.value == 0); } As can be seen, the users of the struct still have to name-space the enum value as S.value. There is no need for an additional enum type for example like S.MyEnum.value. Ali |
December 28, 2015 Re: Implementing a Programming Language in D: Lexical Analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On 12/28/2015 09:57 PM, Ali Çehreli wrote: > anonymous enums Wow! They are pretty weird: 1) The second form of the AnonymousEnumDeclaration spec is redundant, right? http://dlang.org/spec/enum.html#AnonymousEnumDeclaration enum : EnumBaseType { EnumMembers } enum { EnumMembers } <-- Redundant? enum { AnonymousEnumMembers } The reason is, AnonymousEnumMembers already covers EnumMembers, no? 2) Anonymous enum definitions can have types right inside the list: AnonymousEnumMember: EnumMember Type Identifier = AssignExpression enum { a, ulong b = 42, c, // b and c are ulong s = "hello", // an inferred string between integrals! x = 7, y, z } 3) The types of x, y, and z are 'int' because 7 is an int (they don't follow the type of 'c'). However, move 's' to the end of the list or remove it altogether, then x, y, and z become ulong! Weird. Ok, I'm going to forget about this feature now. :p Ali |
December 30, 2015 Re: Implementing a Programming Language in D: Lexical Analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote: > I've realized that with a nested anonymous enum, there is no need to (and no way of) mentioning the enum type inside a user-defined type. This can simplify the implementation: Only if you intend to use enum members as manifest constants, otherwise you're losing the type safety and explicitness offered by named enums. For example, I wouldn't use an anonymous enum for lexeme types. > enum { > a, > ulong b = 42, c, // b and c are ulong > s = "hello", // an inferred string between integrals! > x = 7, y, z > } For me, it's a clear example of unnecessary over-engineering. > However, move 's' to the end of the list or remove it altogether, > then x, y, and z become ulong! Weird. It's even worse than that: x, y and z will still be int (inferred from 7). This code > void main() > { > enum { > a, > ulong b = 42, c, // b and c are ulong > x = 7, y, z > } > import std.stdio, std.typecons; > tuple!(typeof(b), typeof(c), typeof(x)).writeln; > } will print > Tuple!(ulong, ulong, int)(0, 0, 0) which is somewhat counter-intuitive. I would suggest to remove this feature as useless and bug-prone. The following is much clearer IMHO, even though it's more verbose: > enum { a } > enum: ulong { b = 42, c } > enum { s = "hello" } > enum { x = 7, y, z } Even more than that, I would also suggest to remove anonymous auto-typed enums without an initial value from which type can be inferred, e.g.: > enum { a } // a is an int implicitly Again, the following is not much harder to write, but the type of 'a' is immediately clear: > enum: int { a } // a = int.init, obviously Although I understand that these are breaking changes, and D is too mature to break anything (almost not being sarcastic). |
December 30, 2015 Re: Implementing a Programming Language in D: Lexical Analysis | ||||
---|---|---|---|---|
| ||||
Posted in reply to burjui | On Wednesday, 30 December 2015 at 14:41:38 UTC, burjui wrote:
> On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote:
>> [...]
> Even more than that, I would also suggest to remove anonymous auto-typed enums
> without an initial value from which type can be inferred, e.g.:
>
>> [...]
>
> Again, the following is not much harder to write, but the type of 'a' is immediately clear:
>
>> [...]
>
> Although I understand that these are breaking changes,
> and D is too mature to break anything (almost not being sarcastic).
anonymous enum are just not enumerations... They are more "manifest constants" available at CT. Actually their members even dont verify (is(T == enum)) ;).
They also allow not to write too much enum... and to fold in an editor.
|
Copyright © 1999-2021 by the D Language Foundation