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