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

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 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

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.

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.

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

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.

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

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

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