www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Symbol to char[]

reply John Reimer <terminal.node gmail.com> writes:
Features like this are great:

void main()
{
     alias long A;

     writefln( typeid(A) );  	// prints "long"
     writefln( typeid(int) );  	// prints "int"
}


I'm therefore curious to know if it's possible to get the name of a 
function (the symbol name converted to a string as above) during compile 
time.  I know you can get the class name with typeinfo stuff.  So why 
not the function or member symbol names.  The compiler knows about them, 
so it would be very useful to have direct access to the string at 
compile time:

int myFunc()
{
}

void main()
{
     writefln( symbolID( myFunc ) );  // prints "myFunc"
}

Something like this would be useful in templates for situations where 
you wanted to store the symbol submitted in string form for future lookup.

In fact, access to any symbol would be useful in this manner.  Perhaps 
there's a way to do it that I don't see.  Any suggestions?

-JJR
Nov 30 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 Features like this are great:
 
 void main()
 {
     alias long A;
 
     writefln( typeid(A) );      // prints "long"
     writefln( typeid(int) );      // prints "int"
 }
 
 
 I'm therefore curious to know if it's possible to get the name of a 
 function (the symbol name converted to a string as above) during compile 
 time.  I know you can get the class name with typeinfo stuff.  So why 
 not the function or member symbol names.  The compiler knows about them, 
 so it would be very useful to have direct access to the string at 
 compile time:
 
 int myFunc()
 {
 }
 
 void main()
 {
     writefln( symbolID( myFunc ) );  // prints "myFunc"
 }
 
 Something like this would be useful in templates for situations where 
 you wanted to store the symbol submitted in string form for future lookup.
 
 In fact, access to any symbol would be useful in this manner.  Perhaps 
 there's a way to do it that I don't see.  Any suggestions?
 
 -JJR
How about myFunc:name syntax using the colon operator? AFAIK colon is only used in special cases such as the latter half of a ?: (conditional) expression, after a case label, or a statement label. It looks nice, like a property syntax, but could be used for compile-time properties which resolve to constant string or integer (or whatever else) literals. In fact, this is an idea I'm considering throwing into my own language, but that's for another discussion if anyone cares to know =P.
Nov 30 2005
parent reply John Reimer <terminal.node gmail.com> writes:
James Dunne wrote:
 John Reimer wrote:
 Features like this are great:

 void main()
 {
     alias long A;

     writefln( typeid(A) );      // prints "long"
     writefln( typeid(int) );      // prints "int"
 }


 I'm therefore curious to know if it's possible to get the name of a 
 function (the symbol name converted to a string as above) during 
 compile time.  I know you can get the class name with typeinfo stuff.  
 So why not the function or member symbol names.  The compiler knows 
 about them, so it would be very useful to have direct access to the 
 string at compile time:

 int myFunc()
 {
 }

 void main()
 {
     writefln( symbolID( myFunc ) );  // prints "myFunc"
 }

 Something like this would be useful in templates for situations where 
 you wanted to store the symbol submitted in string form for future 
 lookup.

 In fact, access to any symbol would be useful in this manner.  Perhaps 
 there's a way to do it that I don't see.  Any suggestions?

 -JJR
How about myFunc:name syntax using the colon operator? AFAIK colon is only used in special cases such as the latter half of a ?: (conditional) expression, after a case label, or a statement label. It looks nice, like a property syntax, but could be used for compile-time properties which resolve to constant string or integer (or whatever else) literals. In fact, this is an idea I'm considering throwing into my own language, but that's for another discussion if anyone cares to know =P.
James, I'm sorry I didn't respond to you. Yes, using the colon to get the symbol string sounds like a good idea. I only wish there were a way to test it out. :P What's this new language of yours? Is there site where one can have a looksee? Thanks. -JJR
Jan 04 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 
 What's this new language of yours?  Is there site where one can have a 
 looksee?
 
 Thanks.
 
 -JJR
Well, if you want to read endless ramblings and mind dumps for the design of my language, Iris, then you may head on over to http://iris-design-log.blogspot.com/. As of this new design I don't have much code to show except what is in the repository right now, and it's not much. I have a working lexer and am starting on solidifying my parser rules so that I can get to work on my parser. My new reference compiler is being written in D! =P It will most likely rely on a C code generator back end for the time being. More backends are planned for the future like native code (of course), and perhaps MSIL bytecode generation. Some features that I'm quite fond of in my new design (mostly in my head =P) are: * Named/anonymous groups * Compile-time properties (using ':' token as separator instead of '.') * Run-time properties * Object/struct definitions can span multiple source files (just like * Source files are NOT modules * Objects (like D classes but only reference syntax/semantics) * Singletons (no need to explicitly 'new' them, just refer to them by name) * Structs (value syntax/semantics, including assignment operator overloading) * Records (strictly a flat layout of data members, just like struct in C) * Enums (type safe) * Flagsets - collection of named bit flags which can be ORed together * Attribute lists for symbols. * Alias expressions as identifiers. For instance, you can alias the expression (a + b) as an identifier. The identifier would expand out to the aliased expression wherever it is used. * Identifiers can be "constant string expressions" which evaluate to valid Iris identifiers. These can be aliased to identifiers. * Direct mapping of unicode characters to language tokens (see http://iris-design-log.blogspot.com/2005/11/special-support-for-unicode-characters.html) * Symbolic imports within object definitions. * NO object inheritance - use symbolic import (not sure about this one yet) See? Already I'm getting way ahead of myself on my ideas for the language. Of course, this list isn't complete by any means - missing things like sets, ranges, foreach, etc. that I want to get as well. I'm also thinking I want to ditch the tired old "for (init; test; incr)" loop construct in favor of more Pascal/BASIC-like syntax "for var = start to end step stepsize". This is better because it is trivial for the compiler to figure out what you are looping over so that it may unroll the loop or even parallelize it. I know that I want parallel processing primitives in the language, but haven't given it much thought on how to "Do It Right" from the start. I also have been hearing a bit about TOP (Table Oriented Programming). I tend to agree with its basic principles, but have yet to research further into it to see if it actually holds any water. ------------ There is an older (6 months ago) design fork of Iris that I was working on, implemented in C, that I had abandonded due to the overwhelming complexity and near-unmaintainability of the code. Also, the language needed a redo. However, if interested you can check it out at http://jamesdunne.no-ip.org/iris/. Free source code downloads (I wasn't using SVN at the time). It does (as of its last release) produce completely valid C code and is a potentially, if very limited, useful language.
Jan 04 2006
next sibling parent Chris Sauls <ibisbasenji gmail.com> writes:
If you haven't yet, check out Ruby.  Its a pretty interesting language, and
might give you 
some ideas.  (It has, for example, the open-ended object definitions you
mention.)  I know 
the Ruby treatment of dynamic closures ("blocks" in Ruby parlance) is damned
nice.  I 
mimicked it in a hypothetical "dream language" of my own ("Lux"... sadly, I
believe the 
name is actually taken), adding a 'chain' expression in addition to their
'yield', with 
which I can actually define the 'if-else' statement as a function.  Its wild.











-- Chris Sauls

James Dunne wrote:
 John Reimer wrote:
 
 What's this new language of yours?  Is there site where one can have a 
 looksee?

 Thanks.

 -JJR
Well, if you want to read endless ramblings and mind dumps for the design of my language, Iris, then you may head on over to http://iris-design-log.blogspot.com/. As of this new design I don't have much code to show except what is in the repository right now, and it's not much. I have a working lexer and am starting on solidifying my parser rules so that I can get to work on my parser. My new reference compiler is being written in D! =P It will most likely rely on a C code generator back end for the time being. More backends are planned for the future like native code (of course), and perhaps MSIL bytecode generation. Some features that I'm quite fond of in my new design (mostly in my head =P) are: * Named/anonymous groups * Compile-time properties (using ':' token as separator instead of '.') * Run-time properties * Object/struct definitions can span multiple source files (just like * Source files are NOT modules * Objects (like D classes but only reference syntax/semantics) * Singletons (no need to explicitly 'new' them, just refer to them by name) * Structs (value syntax/semantics, including assignment operator overloading) * Records (strictly a flat layout of data members, just like struct in C) * Enums (type safe) * Flagsets - collection of named bit flags which can be ORed together * Attribute lists for symbols. * Alias expressions as identifiers. For instance, you can alias the expression (a + b) as an identifier. The identifier would expand out to the aliased expression wherever it is used. * Identifiers can be "constant string expressions" which evaluate to valid Iris identifiers. These can be aliased to identifiers. * Direct mapping of unicode characters to language tokens (see http://iris-design-log.blogspot.com/2005/11/special-support-for-unic de-characters.html) * Symbolic imports within object definitions. * NO object inheritance - use symbolic import (not sure about this one yet) See? Already I'm getting way ahead of myself on my ideas for the language. Of course, this list isn't complete by any means - missing things like sets, ranges, foreach, etc. that I want to get as well. I'm also thinking I want to ditch the tired old "for (init; test; incr)" loop construct in favor of more Pascal/BASIC-like syntax "for var = start to end step stepsize". This is better because it is trivial for the compiler to figure out what you are looping over so that it may unroll the loop or even parallelize it. I know that I want parallel processing primitives in the language, but haven't given it much thought on how to "Do It Right" from the start. I also have been hearing a bit about TOP (Table Oriented Programming). I tend to agree with its basic principles, but have yet to research further into it to see if it actually holds any water. ------------ There is an older (6 months ago) design fork of Iris that I was working on, implemented in C, that I had abandonded due to the overwhelming complexity and near-unmaintainability of the code. Also, the language needed a redo. However, if interested you can check it out at http://jamesdunne.no-ip.org/iris/. Free source code downloads (I wasn't using SVN at the time). It does (as of its last release) produce completely valid C code and is a potentially, if very limited, useful language.
Jan 04 2006
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
James Dunne wrote:

 
 Well, if you want to read endless ramblings and mind dumps for the 
 design of my language, Iris, then you may head on over to 
 http://iris-design-log.blogspot.com/.
 
< snip > Thanks, James! Lots of really good ideas there. On your site, you blog in more detail about your :name property idea; I like it. Once again, I wish D would implement some such feature. As you mention there, it would be a huge convenience to template work. -JJR
Jan 04 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 James Dunne wrote:
 
 Well, if you want to read endless ramblings and mind dumps for the 
 design of my language, Iris, then you may head on over to 
 http://iris-design-log.blogspot.com/.
< snip > Thanks, James! Lots of really good ideas there. On your site, you blog in more detail about your :name property idea; I like it. Once again, I wish D would implement some such feature. As you mention there, it would be a huge convenience to template work. -JJR
Thanks for taking the time to check it out! What do you think of the latest post on {% %} syntax for Identifier generation? Would really come in handy with templates, yet again. If anyone is interested, I could use some help on sorting out parser rules and combining language ideas together into something cohesive. I really want to start things off "The Right Way" and see how far it'll fly. Design in proper complex number handling, strong typing, type inference, sets, ranges, arrays, array literals, parallel processing primitives (including threads), proper Unicode string handling and string encodings, etc. A lot of posts here on the D newsgroups have educated me on language issues which I had no idea about.
Jan 04 2006
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 05 Jan 2006 01:01:25 -0600, James Dunne wrote:


 A lot of posts here on the D newsgroups have educated me on language 
 issues which I had no idea about.
Ain't that the truth! A huge "thanks" to everyone in helping increase my computer science[programming languages] knowledge. -- Derek (skype: derek.j.parnell) Melbourne, Australia "A learning experience is one of those things that says, 'You know that thing you just did? Don't do that.'" - D.N. Adams 5/01/2006 6:20:50 PM
Jan 04 2006
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
James Dunne wrote:

 Thanks for taking the time to check it out!
 
 What do you think of the latest post on {% %} syntax for Identifier 
 generation?  Would really come in handy with templates, yet again.
 
Ah yes, I see you changed the syntax... if I had only read a little further :). The colon method was attractive because of its simplicity, but I see that it could cause some parsing difficulties. {% %} certainly stands out, but then it begins to look more like a preprocessor directive; in which case, I guess the C preprocessor was what used to do these sort of things in the first place. Either way, it would be nice if D or your language could experiment with these options; these things shouldn't require a full blown preprocessor. I fervently hope that we /never/ return to the era of preprocessors.
 If anyone is interested, I could use some help on sorting out parser 
 rules and combining language ideas together into something cohesive.  I 
 really want to start things off "The Right Way" and see how far it'll 
 fly.  Design in proper complex number handling, strong typing, type 
 inference, sets, ranges, arrays, array literals, parallel processing 
 primitives (including threads), proper Unicode string handling and 
 string encodings, etc.
 
That's kind of beyond me at this point. But I'll be interested to see where you go with all this. I'm pretty busy with a couple big projects right now. :)
 A lot of posts here on the D newsgroups have educated me on language 
 issues which I had no idea about.
Same here! The last few years here have been very educational for me. -JJR
Jan 04 2006
parent reply John Reimer <terminal.node gmail.com> writes:
John Reimer wrote:
 James Dunne wrote:
 
 Thanks for taking the time to check it out!

 What do you think of the latest post on {% %} syntax for Identifier 
 generation?  Would really come in handy with templates, yet again.
Ah yes, I see you changed the syntax... if I had only read a little further :). The colon method was attractive because of its simplicity, but I see that it could cause some parsing difficulties. {% %} certainly stands out, but then it begins to look more like a preprocessor directive; in which case, I guess the C preprocessor was what used to do these sort of things in the first place. Either way, it would be nice if D or your language could experiment with these options; these things shouldn't require a full blown preprocessor. I fervently hope that we /never/ return to the era of preprocessors.
Sorry, James. After further reading at your blog, I conclude that my above paragraph is completely confused concerning {% %}. Disregard this paragraph. :P -JJR
Jan 04 2006
parent James Dunne <james.jdunne gmail.com> writes:
John Reimer wrote:
 John Reimer wrote:
 
 James Dunne wrote:

 Thanks for taking the time to check it out!

 What do you think of the latest post on {% %} syntax for Identifier 
 generation?  Would really come in handy with templates, yet again.
Ah yes, I see you changed the syntax... if I had only read a little further :). The colon method was attractive because of its simplicity, but I see that it could cause some parsing difficulties. {% %} certainly stands out, but then it begins to look more like a preprocessor directive; in which case, I guess the C preprocessor was what used to do these sort of things in the first place. Either way, it would be nice if D or your language could experiment with these options; these things shouldn't require a full blown preprocessor. I fervently hope that we /never/ return to the era of preprocessors.
*Raised eyebrows with inquisitive look on face* =)
 
 Sorry, James.  After further reading at your blog, I conclude that my 
 above paragraph is completely confused concerning {% %}.  Disregard this 
 paragraph. :P
 
 -JJR
Hahaha. No problem. Though in a way you were somewhat on track, since that {% %} block was intended to succeed the era of preprocessors and let the compiler do the work of generating identifiers. I guess one general aim of mine is to reduce to a bare minimum the amount of cases where an external code generator is required. The only obstacle is trying to track down a large subset of patterns I see common in code and trying to alleviate the painstaking work by pushing that work to the compiler instead of leaving it to the programmer (or code generator). Also, the problem with code generators is (if done naively, and it usually is) that once you generate your code and try to go in and modify it later...then realize your generated code had a bug or you want to refactor it, you're basically screwed. Unless you know exactly what all you customized in your generated code, you can't go back and regenerate your code and then apply your changes again. Sure sucks. Having the compiler do this "code generation" work should prevent this scenario. But I can't say that with 100% certainty of course. Yeah, I still enjoy the ':' syntax for compile-time properties because it stands out and at the same time doesn't get in the way or look too terribly odd.
Jan 05 2006