Re: language design implications for variant records in a pascal-like language

On 12/25/2010 8:19 AM, Hans-Peter Diettrich wrote:
> noitalmost schrieb:
>
>> I'm trying to keep my language (and compiler) fairly small, is there a good
>> case for variant records, or could everything be handled through classes
>> without too much inconvenience to the user programmer?
>
> Variant records can simplify memory management of polymorphic data,
> eliminating additional class instances (=heap objects) when embedded in
> other objects, and can reduce the number of new/additional objects
> during type conversions. External libraries (databases, COM) can use
> polymorphic records as arguments, so that such a feature may be a MUST
> for using such APIs. Otherwise every programmer should be happy with
> more type-safe polymorphic classes.


yeah.


admittedly, I am not familiar enough with Pascal-family languages to
have a good idea of whether or not supporting these as a language
feature is a good idea.


my thinking is that most cases where variability is needed, likely using
classes and inheritance is a better option.


this leaves structs/records as fixed-form, but the use of fixed-form
structs is where they are most useful IME.


providing only (reference-based) classes is likely to not be as good,
since classes hinder some of the sorts of semantics and optimizations
possible with record/struct/... types.




however, if both reference-based and value-based class semantics are
provided (more like in C++), then likely no explicit struct/record types
are not so much needed (a struct would be simply a non-inherited class
also lacking any virtual methods).


however, supporting the above is likely to be less trivial for a VM,
since struct/record/value-type style uses tend to imply a known physical
layout, which creates some additional issues when things like
inheritance and virtual methods are introduced.


hence, supporting only reference-based classes and value-based
records/structs may be a reasonable option, since this eliminates the
implied need that classes have a particular physical layout, or that
value-types support potentially problematic features.


for example, C# went the above route.




side note:


OTOH, I am designing (yet another) VM and language (BGBScript2 or BS2),
which uses both Class/Instance OO (single-inheritance, mostly
Java-style), and will supports struct (C# style semantics) and may
support unions (I am undecided on this, as there are pros to cons with
unions...).


the language design uses a syntax mostly based on Java and ActionScript3
with some C# elements (and possibly some elements retained from
BGBScript and Scheme).


its intention is mostly for scripting, but may also be used for
"portable components", probably with the VM supporting C, Java, C#
(likely), and BS2 as source languages (full C++ is unlikely).


the bytecode in use is mostly derived from that used in my BGBScript VM
and also by my C compiler. it will use a form of latent static-typing
(where the typesystem is statically typed, however types are not
necessarily determined until link-time or JIT).




previously I had looked some into using Java and using a JVM-based
design for my stuff, and got a largely working implementation (of a
J2ME-like subset), but changed course after concluding that the JVM is
just too ill-designed for my uses to be a worthwhile base, and decided
to design a different VM to be used here instead (for the time being,
JVM bytecode will remain, just I will halt extension efforts and likely
only use the bytecode for Java...).




I also got into a big argument with people over the matter of VM support
of struct types (at the time, still in the context of using them as a
hack onto the customized-JVM):
I was asserting that value semantics are useful and simplify VM-side
optimizations.


then a big argument ensued over whether or not a standard JVM can
perform the same optimizations with C/I objects, and over if this
actually matters in my case given I am not using a standard JVM (and so
could not likely support the same optimization).


it was my thinking that static lifetime analysis is unlikely to be
generally usable with C/I objects, as there would be far too many cases
where the lifetime of a C/I object will likely be unable to be
statically determined by the VM, meaning that likely many/most objects
being used as value-types will end up as heap garbage (whereas the
effective lifetime of a proper value-type is trivial to determine).




as another side note: the new language design also includes a 'delete'
keyword... so that, if one knows what they are doing, they can make the
object go away and not have to worry about whether or not the VM can
statically determine that it has gone away and can be reclaimed
immediately...




among this, and related issues (mostly with type semantics, declaration
scope handling, ...), I decided to just make another VM design, where I
could simply do things how I wanted without the need for design
contortions or social approval (or having to deal with likely trademark
issues).


yes, all this probably sounds like I am just recreating .NET or similar
in a different form, but IMO this is a fairly different design from .NET
as well.




in the end, maybe it is all pointless, but oh well...

Return to the comp.compilers page.
Search the comp.compilers archives again.