1) Not sure. A lot depends on what is actually built into the language, e.g. if the language gained a way of specifying that a certain type of quoting implied that a certain type of data structure were to be considered it would probably be viable.
That (conversions) of course, overload selection is another one. COM/ActiveX compatibility is another one and a possible reason for the (3) difference.
For the implied conversions (literals inclusive) I have a small text prepared from an earlier discussion, see overview. It might be outdated, they might be more. It is our own little "Perl 6 periodic table of operators" like dirty secret
Pascal's "Periodic table of the elementals" :-)
I was of course using quoting as an example, but I've done things in the past like allowing (via pragmata and extensible syntax) / / to be defined as quotes surrounding a regex (with comparison operators) or backref (as the source of an assignment). It worked out surprisingly well.
Now I'm obviously not suggesting for one moment that regexes should be a fundamental part of the language. But perhaps having that degree of flexibility should, even if restricted to privileged users.
Note that I'm /not/ suggesting that the underlying language should be a complete and compatible Pascal implementation.
As said that IMHO defeats the purpose of the whole exercise. If not compatible, why keep the rest of it? Backwards compatibility is so central (with the exception of the unicode migration) that it is hard to detach from the rest.
Give the core language the responsibility for code generation, in particular stackframe management. Keep it simple and clean enough that maintainers have less of an argument that every single trivial change (e.g. more C-style operators extending the += etc. family) is something that they'd have to maintain, because it was actually defined and implemented at the library level.
2) Implies that a dynamic array also needs attributes of various types.
If you go too far in that direction, make everything a variant with some attributes ;-)
And for what? To save 10k of type helpers?
In this particular case, I was thinking of the case where a codepage number was potentially saved with each string. In the more general case, if type helpers would allow all of this to be moved out of the core language then that's fine by me.
3) Is there any reason why both strings and dynamic arrays should not benefit from this?
Don't know. My guess is that dynamic arrays are key to some activex safe arrays implementation.
It might also be simply statistics. Deep copies of arrays are rare than strings.
True. Whatever, I'm trying to make some general points here.
* A core "pascal-like" language handling code generation. Very strongly typed, extensible operators and possibly extensible syntax.
* Around that a shell language compatible with Pascal "as we know it", isolated from code generation etc. and fairly accessible to people who want to tinker.
* RTL, FCL, LCL, Lazarus plugins etc.
People who simply want to do things like adding operators shouldn't need to get anywhere near the code generation, and they shouldn't be able to do anything that breaks the system. And $DEITY help us, that potentially includes people who want to replace begin/end with braces... let 'em try, their attempt might even result in something from which others can learn.
As I've said: some of this stuff I've done myself, although I'm quite a long way down the ladder as far as compiler proficiency goes. There's also
https://en.wikipedia.org/wiki/Seed7 and
https://web.archive.org/web/20201112030222/www.dlugosz.com/Perl6/web/APL.html ... both of these demonstrate a useful amount of extensibility but I think they emphasise that due to having to specify associativity etc. they might be beyond most application-grade programmers.
But I think the lesson is that particularly with today's computing power, it's realistic for a core/shell compiler to build itself (incorporating all required syntax) at the start of each run.
MarkMLl