www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Implementing a Programming Language in D: Lexical Analysis

reply Walter Bright <newshound2 digitalmars.com> writes:
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)
Dec 28 2015
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Dec 28 2015
next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Dec 28 2015
prev sibling parent reply burjui <bytefu gmail.com> writes:
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).
Dec 30 2015
parent Basile B. <b2.temp gmx.com> writes:
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.
Dec 30 2015