I release this is off topic but I thought some people would be interested.

For my Ph D Theseus I am strongly considering developing a new Programming language to replace C, C++.  (So I guess there will be some competition between my yet-to-be-named-lang and D :) ).

I have written an very rough draft of an overview of the Lang which you can find at http://kevin.atkinson.dhs.org/mylang/.

My Philosophy differers from D in several ways.

* Macros are good.  In fact will be an integral part of the language, and
  will behave much like lisp macros, with all the same power that lisp
  macros give.  More info in my overview.  Please read it before you
  argue with me.

* The core language should be as simple as possible.  For example my new
  language will very likely NOT have a builtin floating point type.
  Instead that will be provided by a library.  The aim is to provide
  the necessary info structure in the core language to make floating point
  operations as fast as if they were builtin.

-- 
http://kevin.atkinson.dhs.org

I had an idea for case sensitivity that I like alot.

Identifiers should be case insensitive, *except* that the first character is case sensitive.  That way, it doesn't matter if you write Foo or FOO or FoO, or fooBar or foobar or fOoBaR, yet A and a are considered different, and foo and Foo are considered different.  Underscores should be allowed but ignored.

You have a lot of good ideas.

I would try if I were you to make macros *not* be based on textual substitution.

Sean

"Kevin Atkinson" <kevin@atkinson.dhs.org> wrote in message news:Pine.LNX.4.44.0310071208260.1551-100000@kevin-pc.atkinson.dhs.org...
>
> I release this is off topic but I thought some people would be interested.
>
> For my Ph D Theseus I am strongly considering developing a new Programming language to replace C, C++.  (So I guess there will be some competition between my yet-to-be-named-lang and D :) ).
>
> I have written an very rough draft of an overview of the Lang which you can find at http://kevin.atkinson.dhs.org/mylang/.
>
> My Philosophy differers from D in several ways.
>
> * Macros are good.  In fact will be an integral part of the language, and
>   will behave much like lisp macros, with all the same power that lisp
>   macros give.  More info in my overview.  Please read it before you
>   argue with me.
>
> * The core language should be as simple as possible.  For example my new
>   language will very likely NOT have a builtin floating point type.
>   Instead that will be provided by a library.  The aim is to provide
>   the necessary info structure in the core language to make floating point
>   operations as fast as if they were builtin.

I couldn't tell how you intended to deal with inheritance.  One of the sticky issues.  (Personally, I like the Eiffel model.)

Also, I couldn't tell if you intend to deal with dynamic types, or how you would implement persistence.  I've often thought that languages should have a b+tree that stores "active code", and that there should be an "export this routine" operation which creates a package that includes a stripped b-tree of the code needed by the routine being exported.  (There would also need to be a complementary "import" routine.)

If I recall, in the early days something like this was considered for Eiffel, but was decided against, for reasons of compactness. Smalltalk made the other choice, but went on to decide on a closed system...understandable if you recall the days in which it started.  But what I'm contemplating here is something similar to a "long-term memory", and anything which only depended on items that had been remembered in the b+tree could be efficiently persisted, and less efficiently exported.  (Persisting of the data might be similar to the "remembering" of the code...i.e., the same system could probably be used for both.)  It seems that perhaps something like CVS could be adapted to this purpose without too much contortion, but there would need to be provisions for indexing things so that they could be found again, and perhaps an overnight cycle which could purge the tree of items over a certain date which had lost all of their indexes (which would mean that it would be necessary to determine what was still current).

Charles Hixson wrote:
> I couldn't tell how you intended to deal with inheritance.  One of the sticky issues.  (Personally, I like the Eiffel model.)

I don't know yet.

> Also, I couldn't tell if you intend to deal with dynamic types, or how you would implement persistence.

I'm sorry, I'm not sure what you mean by persistence.

Sean L. Palmer wrote:

> I would try if I were you to make macros *not* be based on textual
> substitution.

Exactly what do you mean by that?

I mean make them symbolic if at all possible.

So you don't have problems like this:

#define op(arg, arg2) arg+arg2  // bad because needs parenthesis to make
grouping clear

#define moo(str) str+3 // bad because type cannot be checked
moo("foo");
moo(while);

Textual macros will bite you!  Then there's the need for a ## operation...

But if you're using them to define language elements your "types" would have to include literals and such.  I've not really been exposed to Lisp macros so I am not sure what that would look like, or what you're going to be trying to do with the macros.

All I know is I've seen some really really nasty stuff crafted using C macros.  Stuff that barely works, which is worse I think than something that doesn't work at all.  Macros in C cause lots of problems (especially with header files).

Sean


"Kevin Atkinson" <kevin@atkinson.dhs.org> wrote in message news:blvufa$29cg$1@digitaldaemon.com...
> Sean L. Palmer wrote:
>
> > I would try if I were you to make macros *not* be based on textual substitution.
>
> Exactly what do you mean by that?

yep.
Really nice are for example the windows macros:

from windows.h
#ifdef _UNICODE
#define CreateFile CreateFileW
#else
#define CreateFile CreateFileA
#endif

from someheader.h which is used with windows.h

class MyFileAbstractionClass
{
public:
    void CreateFile();
};


Great, isnt it?
-- 
Jan-Eric Duden
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
news:bm0h8q$2lq$1@digitaldaemon.com...
> I mean make them symbolic if at all possible.
>
> So you don't have problems like this:
>
> #define op(arg, arg2) arg+arg2  // bad because needs parenthesis to make
> grouping clear
>
> #define moo(str) str+3 // bad because type cannot be checked
> moo("foo");
> moo(while);
>
> Textual macros will bite you!  Then there's the need for a ## operation...
>
> But if you're using them to define language elements your "types" would
have
> to include literals and such.  I've not really been exposed to Lisp macros so I am not sure what that would look like, or what you're going to be trying to do with the macros.
>
> All I know is I've seen some really really nasty stuff crafted using C macros.  Stuff that barely works, which is worse I think than something
that
> doesn't work at all.  Macros in C cause lots of problems (especially with
> header files).
>
> Sean
>
>
> "Kevin Atkinson" <kevin@atkinson.dhs.org> wrote in message news:blvufa$29cg$1@digitaldaemon.com...
> > Sean L. Palmer wrote:
> >
> > > I would try if I were you to make macros *not* be based on textual substitution.
> >
> > Exactly what do you mean by that?
>
>

Sean L. Palmer wrote:

> So you don't have problems like this:
> 
> #define op(arg, arg2) arg+arg2  // bad because needs parenthesis to make
> grouping clear

Macros that expand to expressions will have implicit grouping.

> #define moo(str) str+3 // bad because type cannot be checked
> moo("foo");
> moo(while);

This may still be allowed but the error message will be clearer.  It will be something like "syntax error .... expanded from moo ...."

> Textual macros will bite you!  Then there's the need for a ## operation...

Macros are functions which return a string to be used instead of the macro.  Ie there are written in MyLang themself.  Thus there will be no need to have new operators.

> I've not really been exposed to Lisp macros
> so I am not sure what that would look like, or what you're going to be
> trying to do with the macros.

Than you can not really appreciate macros as I intend to use them.

> All I know is I've seen some really really nasty stuff crafted using C
> macros.  Stuff that barely works, which is worse I think than something that
> doesn't work at all.  Macros in C cause lots of problems (especially with
> header files).

Most all of those problems will be avoided.  Macros in MyLang will not be blanket replacements.  They obey namespace rules, and can not evaluate to anything. They must evaluate to a valid grammatical element or list of.

For example:

      "a * b"  OK
      "* b"      NOT
      "var x; var y;" OK
      "var x; var"    NOT
      "a = 10; b = 20" OK
      "=10; b=" NOT

Jan-Eric Duden wrote:

> Really nice are for example the windows macros:
> 
> from windows.h
> #ifdef _UNICODE
> #define CreateFile CreateFileW
> #else
> #define CreateFile CreateFileA
> #endif
> 
> from someheader.h which is used with windows.h
> 
> class MyFileAbstractionClass
> {
> public:
>     void CreateFile();
> };
> 

That type of macro will most likely not be allowed in MyLang.

Kevin Atkinson wrote:
> Charles Hixson wrote:
> 
>> I couldn't tell how you intended to deal with inheritance.  One of the sticky issues.  (Personally, I like the Eiffel model.)
> 
> 
> I don't know yet.
> 
>> Also, I couldn't tell if you intend to deal with dynamic types, or how you would implement persistence.
> 
> 
> I'm sorry, I'm not sure what you mean by persistence.
> 
data, classes, and other objects that are remembered between invocations, and can be rolled in and out of memory.  Rather like a database built into the language, but designed to work with the language so it can easily restore things complete with the type that they had when they were "learned".  Usually it's been done as an add-on, and such have usually been quite clumsy, so it probably needs to be built into the language...though you do speak of end-users being able to add language features.  I'm not sure if you mean this in as thorough-going a manner as FORTH does, but a good persistence mechanism would definitely require that data be able to identify to the system what it's type was, and to be seen as being of the appropriate type even after being rolled back in.   Smalltalk does this reasonably well, Java quite poorly, many others even worse.