View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2005
Symbol to char[]
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
December 01, 2005
Re: Symbol to char[]
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.
January 04, 2006
Re: Symbol to char[]
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
January 05, 2006
Re: Symbol to char[] (OT: language)
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
    C# 3.0 feature)
  * 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.
January 05, 2006
Re: Symbol to char[] (OT: language)
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.

##### Lux #####
# define function void if (bool expr) (; elsif, else) {
#   expr && yield ;
#   expr || chain ;
# }
#
# define function else () (if ;) {
#   yield ;
# }

-- 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
>     C# 3.0 feature)
>   * 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.
January 05, 2006
Re: Symbol to char[] (OT: language)
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
January 05, 2006
Re: Symbol to char[] (OT: language)
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.
January 05, 2006
Re: Symbol to char[] (OT: language)
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
January 05, 2006
Re: Symbol to char[] (OT: language)
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
January 05, 2006
Re: Symbol to char[] (OT: language)
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home