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

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.

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

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

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

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

"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

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

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.

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.])