www.digitalmars.com         C & C++   DMDScript  

D - My New Lang

reply Kevin Atkinson <kevin atkinson.dhs.org> writes:
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
Oct 07 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.
Oct 07 2003
next sibling parent reply Kevin Atkinson <kevin atkinson.dhs.org> writes:
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?
Oct 07 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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);



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?
Oct 08 2003
next sibling parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
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);



 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?
Oct 08 2003
next sibling parent Kevin Atkinson <kevin atkinson.dhs.org> writes:
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.
Oct 08 2003
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Jan-Eric Duden wrote:

 yep.
 Really nice are for example the windows macros:
=20
 from windows.h
 #ifdef _UNICODE
 #define CreateFile CreateFileW
 #else
 #define CreateFile CreateFileA
 #endif



 Great, isnt it?


Not really great. We have "alias" for that. Macros make the semantics of =

the substitution blur and disappear. Alias stands for another identifier =

only in the context where it has been defined, while the macro will=20
replace the same identifier in any other context. Think of Namespaces=20
and Classes, which can have the same identifier refer to unrelated=20
things. Heck, think of K=F6nig lookup!

There has been some university project which made a context-sensitive=20
pre-processor, which didn't expose problems of the C preprocessor, and=20
had immense power. This is actually near to the direction Kevin is=20
going, and was an effort to create something much simpler than OpenC++.

BTW, Kevin: I come to think that (among other things) i like your=20
definition of inner classes a lot - because they are a generalisation of =

*properties*, making them so much more flexible! Like, you can have not=20
only read and write, but also increments, decrements, all other=20
operators defined directly, and with unrestricted access to the=20
containing class!

-eye
Oct 16 2003
prev sibling parent Kevin Atkinson <kevin atkinson.dhs.org> writes:
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 ...."





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
Oct 08 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> a écrit dans le message de
news:blus3m$rs9$1 digitaldaemon.com...

 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.


While I like the idea of underscore in number, I think that ignoring them in
variable
might cause some surprises if 2 variables are considered equivalent when
they
should not:

    bool a_head = ... // indicate if the object is a head
    bool ahead = ... // indicate that the object is in the front.

Also this not works well with conventions that _ at the beginning is
reserved for
the compiler in C/C++ and for the convention that an ending _ is used for
(typically constructor) arguments that would otherwise have the same name:

    f(int i_) { i = i_; }

IMHO, identifier should be case sensitive but we might not allows having
the same identifier in the same scope with different case for the same
purpose but we should be able to have a class and an object that differs
only in case:

    class Something;
    Something something;

Otherwise, we need even more imagination to find variable names...

Finally, I think that complicate rules (like an exception for the first
letter
would make everything more complicate: we have to know the rule,
the compiler has to implement it and every parser would also have
to handle those rules....)


 You have a lot of good ideas.

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

 Sean
Oct 08 2003
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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).
Oct 07 2003
parent reply Kevin Atkinson <kevin atkinson.dhs.org> writes:
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.
Oct 07 2003
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.
Oct 08 2003
next sibling parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Charles Hixson wrote:


 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.


Previously I suggested that if D supported compile-time-methods, 
programming something like RTTI persistence would be easy.  It wouldn't 
be built into the language, but you'd be killing a load of birds with 
one stone.

-Anderson
Oct 08 2003
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
J Anderson wrote:

 Charles Hixson wrote:
 

 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.


 Previously I suggested that if D supported compile-time-methods, 
 programming something like RTTI persistence would be easy.  It wouldn't 
 be built into the language, but you'd be killing a load of birds with 
 one stone.
 
 -Anderson
 


Persistence doesn't need to be built into the language, but the 
appropriate hooks for building it do.  I'm not sure that 
compile-time methods would suffice, though they would definitely 
make at least a kludgey system feasible.  It also seems to me that 
there needs to be a way for an object to identify it's type to the 
system...compile time methods don't really handle that well without 
an attached database that tracks "known types", though I suppose 
that you could attach a copy of the source to each data item... 
maybe not a good idea.  Basically you need a way to register a type 
with the system, and for the system to identify it by a type number.

Also needed is some way of exporting and importing files that 
attaches to them the types necessary to understand them in a system 
independant way, that still avoids excessive redundancy.  Probably 
something that strips comments and spaces, and assigns variables 
cannonical names so that identically implemented algorithms are 
identical.  Then gzip it, and calculate a checksum to allow fast 
elimination of most candidates.  You'd still get some reduncancy, 
but a lot less.  And it would be smaller.  (One gzipped instance of 
each compressed type used per file.)  Fancier methods allow 
versioning, etc., but I was looking for a quick and easy method that 
would be portable.  Possibly versioning information could be stored 
separately.  Since all this is, is code the total amount would be 
small compared to data.  And if it could be reduced to a single 
number (long or int for types?  probably int within any one file) 
per data item then it becomes more practical.  Also, one should 
think seriously about the compression algorithm before finally 
deciding.  Bzip2 is a lot smaller than zip or gzip for large files, 
but what about something the size of a typical type?  Especially a 
stripped and condensed (via white space removal) type.  You need a 
compression algorithm that works well on small files, and acceptably 
on reasonably sized ones.

You could think of this as a super pickle (python), but pickles 
don't include the code, do they?  My impression is that when you 
read in a pickle, you need to identify the code yourself.  This is 
more like Smalltalk images... but I do find it significant that my 
two examples of something similar are Python and Smalltalk (though I 
do seem to remember that Pickle was originally used with C).  And 
both Python and Smalltalk are significantly differnt from D in their 
orientation towards dynamic typing.  (Again I think of Neon from 
Kyria Software, which had user speicfiable binding times for types, 
but that was an OO FORTH dialect, and types in FORTH are, again, a 
significantly differnt concept than those of D.)
Oct 08 2003
parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Charles Hixson wrote:


 J Anderson wrote:


 Charles Hixson wrote:


 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.


 Previously I suggested that if D supported compile-time-methods, 
 programming something like RTTI persistence would be easy.  It 
 wouldn't be built into the language, but you'd be killing a load of 
 birds with one stone.

 -Anderson


 Persistence doesn't need to be built into the language, but the 
 appropriate hooks for building it do.  I'm not sure that compile-time 
 methods would suffice, though they would definitely make at least a 
 kludgey system feasible.  It also seems to me that there needs to be a 
 way for an object to identify it's type to the system...compile time 
 methods don't really handle that well without an attached database 
 that tracks "known types", though I suppose that you could attach a 
 copy of the source to each data item... maybe not a good idea.  
 Basically you need a way to register a type with the system, and for 
 the system to identify it by a type number.


I was thinking that a database would be used with the compile time 
methods (CTM).  You could use a ralivent database that was already 
provided by a D library.  I would would manage type changes when the 
programs compile, that may be clunky. The actual unique identifier 
provided would be a constant at runtime, with no database searching 
required (with parhaps one or two lookups).  However, do I think CTM 
would require some sort of extra support, like making the typeid stuff 
available to the CTM at compile time.

(Actually I should probably call CTM, compile-time-function-calls 
because in my suggestion any library method could be used at compile 
time, as apposed to a function only being available for compile time.)


 Also needed is some way of exporting and importing files that attaches 
 to them the types necessary to understand them in a system independant 
 way, that still avoids excessive redundancy.  Probably something that 
 strips comments and spaces, and assigns variables cannonical names so 
 that identically implemented algorithms are identical.  Then gzip it, 
 and calculate a checksum to allow fast elimination of most 
 candidates.  You'd still get some reduncancy, but a lot less.  And it 
 would be smaller.  (One gzipped instance of each compressed type used 
 per file.)  Fancier methods allow versioning, etc., but I was looking 
 for a quick and easy method that would be portable.  Possibly 
 versioning information could be stored separately.  Since all this is, 
 is code the total amount would be small compared to data.  And if it 
 could be reduced to a single number (long or int for types?  probably 
 int within any one file) per data item then it becomes more 
 practical.  Also, one should think seriously about the compression 
 algorithm before finally deciding.  Bzip2 is a lot smaller than zip or 
 gzip for large files, but what about something the size of a typical 
 type?  Especially a stripped and condensed (via white space removal) 
 type.  You need a compression algorithm that works well on small 
 files, and acceptably on reasonably sized ones.


One other thing that would reduce clashes would be some form of name 
spacing.


 You could think of this as a super pickle (python), but pickles don't 
 include the code, do they?  My impression is that when you read in a 
 pickle, you need to identify the code yourself.  This is more like 
 Smalltalk images... but I do find it significant that my two examples 
 of something similar are Python and Smalltalk (though I do seem to 
 remember that Pickle was originally used with C).  And both Python and 
 Smalltalk are significantly differnt from D in their orientation 
 towards dynamic typing.  (Again I think of Neon from Kyria Software, 
 which had user speicfiable binding times for types, but that was an OO 
 FORTH dialect, and types in FORTH are, again, a significantly differnt 
 concept than those of D.)
Oct 08 2003
parent Charles Hixson <charleshixsn earthlink.net> writes:
Please note that most of the fancy mapping I talk about would only 
be needed when a chunk was being exported into a inter-machine 
portable form (which, I suppose, could also be used for long-term 
storage).  But most of the time a simple type sequence number should 
suffice, though this does require that the database always be loaded 
during compilations.  You use the sequence number to look up the 
check-sum, and if they don't match, you've got database consistency 
problems.  But comitting a new type to the database should be a 
separate step, not something that happens automatically (unless you 
have a "generate release version" option).

Also note that the database should be at the front of the search 
path when you are doing imports, or includes, or whatever you end up 
calling the process.  This helps prevent name clashes by detecting 
them early.  Creating non-memorable names should be legal, but of 
couse such names couldn't be remembered in the database, so it 
should generate a suppressable warning.

Think of the difference between short term and long term memory. 
Session memory is short term, inter-session memory is long term, and 
exportable is writing things to books.


J Anderson wrote:

 Charles Hixson wrote:
 

 J Anderson wrote:


 Charles Hixson wrote:


 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.


 Previously I suggested that if D supported compile-time-methods, 
 programming something like RTTI persistence would be easy.  It 
 wouldn't be built into the language, but you'd be killing a load of 
 birds with one stone.

 -Anderson


 Persistence doesn't need to be built into the language, but the 
 appropriate hooks for building it do.  I'm not sure that compile-time 
 methods would suffice, though they would definitely make at least a 
 kludgey system feasible.  It also seems to me that there needs to be a 
 way for an object to identify it's type to the system...compile time 
 methods don't really handle that well without an attached database 
 that tracks "known types", though I suppose that you could attach a 
 copy of the source to each data item... maybe not a good idea.  
 Basically you need a way to register a type with the system, and for 
 the system to identify it by a type number.


 I was thinking that a database would be used with the compile time 
 methods (CTM).  You could use a ralivent database that was already 
 provided by a D library.  I would would manage type changes when the 
 programs compile, that may be clunky. The actual unique identifier 
 provided would be a constant at runtime, with no database searching 
 required (with parhaps one or two lookups).  However, do I think CTM 
 would require some sort of extra support, like making the typeid stuff 
 available to the CTM at compile time.
 
 (Actually I should probably call CTM, compile-time-function-calls 
 because in my suggestion any library method could be used at compile 
 time, as apposed to a function only being available for compile time.)
 

 Also needed is some way of exporting and importing files that attaches 
 to them the types necessary to understand them in a system independant 
 way, that still avoids excessive redundancy.  Probably something that 
 strips comments and spaces, and assigns variables cannonical names so 
 that identically implemented algorithms are identical.  Then gzip it, 
 and calculate a checksum to allow fast elimination of most 
 candidates.  You'd still get some reduncancy, but a lot less.  And it 
 would be smaller.  (One gzipped instance of each compressed type used 
 per file.)  Fancier methods allow versioning, etc., but I was looking 
 for a quick and easy method that would be portable.  Possibly 
 versioning information could be stored separately.  Since all this is, 
 is code the total amount would be small compared to data.  And if it 
 could be reduced to a single number (long or int for types?  probably 
 int within any one file) per data item then it becomes more 
 practical.  Also, one should think seriously about the compression 
 algorithm before finally deciding.  Bzip2 is a lot smaller than zip or 
 gzip for large files, but what about something the size of a typical 
 type?  Especially a stripped and condensed (via white space removal) 
 type.  You need a compression algorithm that works well on small 
 files, and acceptably on reasonably sized ones.


 One other thing that would reduce clashes would be some form of name 
 spacing.
 

 You could think of this as a super pickle (python), but pickles don't 
 include the code, do they?  My impression is that when you read in a 
 pickle, you need to identify the code yourself.  This is more like 
 Smalltalk images... but I do find it significant that my two examples 
 of something similar are Python and Smalltalk (though I do seem to 
 remember that Pickle was originally used with C).  And both Python and 
 Smalltalk are significantly differnt from D in their orientation 
 towards dynamic typing.  (Again I think of Neon from Kyria Software, 
 which had user speicfiable binding times for types, but that was an OO 
 FORTH dialect, and types in FORTH are, again, a significantly differnt 
 concept than those of D.)
Oct 08 2003
prev sibling next sibling parent reply Kevin Atkinson <kevin atkinson.dhs.org> writes:
Charles Hixson wrote:


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


I am really not that familiar with that concept.  I can't think of any 
areas in RTTI where caching would help.
Oct 08 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Kevin Atkinson wrote:

 
 Charles Hixson wrote:
 

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


 
 I am really not that familiar with that concept.  I can't think of any
 areas in RTTI where caching would help.


Think of a user that opens application windows, resizes and fills them
to arrange a kind of workspace. Now he wants to exit, turn off the
computer, later restart his program and continue where he left. If you 
want to support this kind of convenience, you have a lot of work to 
save and restore all kinds of objects. Persistence would allow you to
stream out these objects and restore them almost without effort.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Oct 08 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> a écrit dans le message de
news:3F845D18.F18C2D98 chello.at...

 Kevin Atkinson wrote:

 Charles Hixson wrote:


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


 I am really not that familiar with that concept.  I can't think of any
 areas in RTTI where caching would help.


 Think of a user that opens application windows, resizes and fills them
 to arrange a kind of workspace. Now he wants to exit, turn off the
 computer, later restart his program and continue where he left. If you
 want to support this kind of convenience, you have a lot of work to
 save and restore all kinds of objects. Persistence would allow you to
 stream out these objects and restore them almost without effort.


But to be very usefull, the persistent format must be known and usable
with many target (file, compound storage (COM), registry, application files,
byte array,...) and we must have provision for type that are not represented
the same way on every platform...

If we switch language, platform, compiler version, OS,... we need to
be able to read the file anyway (maybe not easily but it should be
possible without reverse-enginnering of the file/stream format).

But in pratice, this will probably not works as the persistence must
recreate objects...

At least, it should be well defined for any D compiler and ideally
the format should be well known so that we would know how to
decode the file content (from C++ for example) or from D if
a new version of the application is enough modified to not being
able to uses the data directly.... but might like to read some
properties (for a checkbox that is replace by a radio group where
we might want to select one option if the check box was checked
in the old version of the application)



 -- 
 Helmut Leitner    leitner hls.via.at
 Graz, Austria   www.hls-software.com
Oct 08 2003
prev sibling parent reply Kevin Atkinson <kevin atkinson.dhs.org> writes:
Helmut Leitner wrote:

 
 Kevin Atkinson wrote:
 

I am really not that familiar with that concept.  I can't think of any
areas in RTTI where caching would help.


 
 Think of a user that opens application windows, resizes and fills them
 to arrange a kind of workspace. Now he wants to exit, turn off the
 computer, later restart his program and continue where he left. If you 
 want to support this kind of convenience, you have a lot of work to 
 save and restore all kinds of objects. Persistence would allow you to
 stream out these objects and restore them almost without effort.


So really what you are doing is saving an object and all of its 
subobjects?  I plan to provide an easy way to walk a complex data
structure so that you can copy it, print it, etc.
Oct 08 2003
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Kevin Atkinson wrote:

 ...
 So really what you are doing is saving an object and all of its 
 subobjects?  I plan to provide an easy way to walk a complex data
 structure so that you can copy it, print it, etc.
 


I've seen a crude persistence done that way, but it rapidly becomes 
both large and tangled as you try to increase the scale.  Eiffel had 
  something like that in an add-on class, and it ended up requiring 
a full memory state save.  Not ideal.  You want something that only 
records things that have changed from last time, and if the "same" 
data item (a tricky definition there!) has been changed, it gets 
overwritten on the external store.  Rewriting everything every time 
is not only inefficient in lots of ways, it also prevents the memory 
scaling well.  Imagine something that tracks your e-mail, and your 
responses...and saves partially completed responses until you either 
finish them or delete them.  You don't want to pull all that into 
ram each time, only the pieces you're working with.  Most of it 
doesn't change often, but some of it changes a lot.  And you'd like 
to be able to index it several ways, based on content, which needs 
to be determined by a program (since you can't rely on subject 
headers). --- O, and you switch from machine to machine 
occasionally, so you want to be able to pack this up and send it 
off, or merge it against messages already received.

That's actually not a good example, as there are already well 
defined ways to doing that particular job.  But they don't 
generalize into doing other similar jobs.  But most of this stuff 
shouldn't be a part of the basic language design, it's just that the 
language should have hooks to support this.  (Though including a 
basic B+Tree datatype as a part of the language might be rather 
nice.  It's the logical next step from hash tables. [Given my point 
of view.])
Oct 08 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
There's a great example of a persistence library for Java that uses
snapshots and command logs. It's called "prevayler" and you can read
about it at http://www.prevayler.org

--Benji
Oct 09 2003
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Benji Smith wrote:

 There's a great example of a persistence library for Java that uses
 snapshots and command logs. It's called "prevayler" and you can read
 about it at http://www.prevayler.org
 
 --Benji


I don't know about the Java model, but the Ruby implementation of 
Prevayler is an example of what I was talking about.  It requires a 
full memory state save of everything persisted.  And you must also 
roll in everything to use it, even if all you want to do is change a 
string (or, for that matter, an integer).
Oct 09 2003
parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message
news:bm4397$cll$1 digitaldaemon.com...

 Benji Smith wrote:

 There's a great example of a persistence library for Java that uses
 snapshots and command logs. It's called "prevayler" and you can read
 about it at http://www.prevayler.org

 --Benji


 I don't know about the Java model, but the Ruby implementation of
 Prevayler is an example of what I was talking about.  It requires a
 full memory state save of everything persisted.  And you must also
 roll in everything to use it, even if all you want to do is change a
 string (or, for that matter, an integer).


I have been talking about this for a long time. Here is my last reply on
Slashdot:

http://slashdot.org/comments.pl?sid=79683&cid=7042606

Objects need to be persistent. The main memory must be a cache between the
hard disk and the CPU. The O/S must handle object orientation, class
management and persistent.

All that a language needs is a 'persistent' attribute...each member marked
as persistent will be automatically saved to/loaded from disk; if it
contains other persistent members, they would be saved too in the order they
are declared. The layout of the class (known to the whole system by the O/S)
would be the format that the data are saved into.

Sorry if this seems slightly offtopic, but people don't seem to realize how
a true object-oriented operating system would change our lives.

(And object-oriented languages would be a natural for it).
Oct 10 2003
prev sibling parent Kevin Atkinson <kevin atkinson.dhs.org> writes:
Charles Hixson wrote:


 how you would implement persistence.


The MyLang *core* will not only support low-level objects.  It won't
even directly support inheritance since there will be no need to.  See
section 3.13 "Low Level Objects" in the expanded MyLang overview at
http://kevin.atkinson.dhs.org/mylang/.  Inheritance and all OO conceps
can be implemented by the user using Compile Time Functions (see section
5.1).  The default library will provide an OO implementation which
will be as easy to use, if not easier, than C++.  I do not know if how
much persistence support will be provided.  However, if you are not
satisfied with what is provided you can implement it yourself since
MyLang provides you with the necessary tools to do so.  And it will be
just as easy to use as if it was built into the language.
Oct 13 2003