Re: object system...

On Thu, 15 Jan 2009 00:23:07 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:163b2w1jiz24c$.115zwvzcu6sr7.dlg@xxxxxxxxxxxxx
On Tue, 13 Jan 2009 23:54:00 +1000, cr88192 wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1obq05ayl19zl$.mghpopxh028w.dlg@xxxxxxxxxxxxx
On Mon, 12 Jan 2009 22:50:28 +1000, cr88192 wrote:

4. when rebuilding the code. in this case, usually the type information
is kept purely as sideband or scaffolding, and once the code is built
it ceases to matter, or at least until more code needs to be built around it..

Same as 3, the context must know the type where an operation on it
should happen. Context /= object /= type.

only when the code already exists at compile time...

if the code does not exist, it can't be typed at this point, and so the
information needs to be kept around until it can be used...

Yes, for a compiler the program is a text.

only to the parser...

Parser is an optional part of the compiler.

then it is ASTs, an IL format, ASM, ...

This changes nothing.

no, the OS only knows about apps after they are installed...

Yes, that is the behavior of "application type." <=> it knows
applications.


FWIW, the OS can be compared to a huge self-modifying program

No, it cannot be. Depending on what one understands under "system," does
this includes non-volatile memory etc. In any case, once you draw a line
and define what parts belong to the system, you will immediately see, that
it is not self-modifying. There is no such thing as self-modifying
programs, you always need an external agent, which does not change.

but, there is no need for it to compile (all of) itself, because the
external compiler (AKA: static compiler and linker) has already done so...

And the compiler does not change... Barber does not shave himself...

now, as for the barber:
it is a paradox if both possibilities are to be considered at the same time
(as in an axiom), however if on each day he makes this same decision (using
the prior day as his current status, as is more typical in procedural
logic), then he will only shave every-other day (the axiom will be true at
one try, but false at the next, then true, then false, ...).

He does not make decisions, he makes a statement about decisions. This
statement is self contradictory and thus cannot be used as a basis for
decision making. Other statements could be.

however, as can also be noted, software is based on code, not on abstract
logic...

Well, that is an interesting statement. It is business logic I guess? If
your software is not based on formal logic, then you cannot reason about it
in formal terms. My condolences...

if we say that in reality the types do not exist, but are merely
manifestations of the present state, then there is not a problem with saying
that a type is represented by a type...

Where that follows from? Existence in "reality" is irrelevant to the issue
of consistence. Does reality exist?

or, by the same definition, a compiler for C++ can't be written in C++,
since it would have to compile itself, but oh wait, this is the whole point
of writing the compiler in its own language...

This is a different issue. You write a compiler, the compiler writes
nothing. Same as a program printing its own code is not self-contradictory.
But reasoning about own behavior is. So halting problem goes. Typing system
is reasoning about behavior. A self-referential type system will inevitably
become inconsistent, at some point. So it is dangerous to play with this
stuff. An inconsistency will manifest itself in incomputability of some
operations, i.e. your system will either hang or else crash after eating
all available memory. BTW, most of compilers suffer this.

it is declared against a class but it uses the instance.

This is another case. If a polymorphic object is declared, then it is an
instance of the type which is a transitive closure of the class. I don't
know which case you mean, polymorphic or a non-polymorphic one.

I am not sure what is being said here...

Because class cannot be a type, you need some distinct type to represent
the class. The set of values of the type is a closure of the values of
types from the class.

structs, strings, ...

now, there are more direct versions of this wonkiness:
consider SmallTalk;
classes are first class objects (aka: instances) of prior existing classes
(aka: classes are needed to represent their own representation).

now, how ST implementations pull this off in practice, I am less certain,
but I am aware of this bit of amusing trivia...

I don't know how they do it. I think it is impossible to without some
acrobatics...

it is not declared against the instance, nor is it used against the
class...

When object is not declared to have a type related to the interface,
then any operation of the interface applied to the object is a type error.

In a consistent strong typed system, you just cannot do these things.
That is the idea of strong typing, not to allow this mess.

again, this does not make sense.

To break types indeed does not make sense. The point is, that if you tried
to formalize the stuff we discuss, you would quickly discover that you
could not do it. It is inconsistent like "all Cretans are liars."

formalisms don't matter so much as long as the code is working...

1. How do you know that it does?
2. How do you know that it will do?

do you use an interface to access static methods?...

Static method? If you mean C++ static member, that is an artefact of its
poor design, which confuses visibility issues with types.

close enough... I meant like Java and C# static methods, where the class can
be accessed apart from its instance...

What for? If type is not a first-class citizen you cannot do anything
useful with it anyway.

I may put a little more weight into this claim if evidence can be shown,
or at least a justifiably solid explanation is given...

"compiler can choose" does not necessarily mean "faster"...

maybe it means "can omit bounds check", but C does not use these anyways
(and more recent compilers, such as those for C#, are in many cases able
to figure out when to leave out the bounds check).

It can use a shorter machine type for the index instead of int. When you
specify int, the compiler does not know if this int is "as-is" or else an
implementation artefact, and unsigned char would go as well. To check such
issues is a heavy burden and is theoretically incomputable at all.
Furthermore, the compiler can use indexing machine instructions which may
have no explicit index at all. Because the index range is known the
compiler could load the whole array into a cache etc.

and you are saying an unsigned char would be faster for an array index?...

I don't know it, as a programmer. I don't even want to know it. It is not
my business. I say what I want and the compiler has to do best of it. It is
an absolutely different programming paradigm: higher level vs. lower level.

When you expose machine types, you cannot describe their semantics
in a machine-independent way, obviously.

doesn't matter when the machines in question implement more-or-less
the same semantics...

How do you define "more or less same semantics?" Computing is
discrete, 1+1 is either 2 or else wrong. Does 15326+35221 overflow?

you know... 2+2=5...

whether or not numbers overflow depends on their sizes and other
factor.

It depends on the type of. If you lack this information in types you
cannot write a program with defined semantic.

In Ada I write:

type T is range 1..2;

this instructs the compiler to implement a semantics that makes
impossible
to assign 2+2 to a variable of the type T.

yes, but typically the compiler usually does not need to know this.

It usually does, because using of built-in types is discouraged.

what kind of reason is that?...

A well-defined semantics and everything that follows:

1. Portability
2. Efficiency
3. Maintainability
4. Safety
5. Verifiability

in most mainstream languages, they are not discouraged.
in fact, they are the only things offered.

(:-)) You know, the mainstream languages are quite miserable, and the
current state of software developing is even worse.

all that is needed to know is that the types are big enough to hold the
values in question, and if there is an overflow, that is the programmers'
problem (or, possibly, the fault of whoever it was trying to compile the
code on whatever arch it does not work on...).

Everything is programmer's problem. The argument of "big enough" is plain
wrong. Consider a modular type with circular shift operation as a
counterexample.

if one needs a circular shift, it can be implemented easily enough with
existing types.

for example, a 20 bit circular left-shift:
v=((v<<i)&((1<<20)-1))|((v>>(20-i))&((1<<i)-1));

or, a right shift:
v=(((v&((1<<20)-1))>>i)|((v<<(20-i))&((1<<20)-1));

now, these could be wrapped nicely in macros, and there is no need for some
funky type...

Nope, you forgot the rest of ring arithmetic:

a+b mod 20
a*b mod 20
....

And sorry, do you call it a language?

Anyway, the point is, when you add values to the type, you get another
type. The argument about safe ranges is bogus.

The right technical term is substitutability = preservation of all
propositions about all possible programs using the type. Substitutability
does not hold even with safe ranges. That means, each time when you replace
one type with a machine type you have to analyse each use case of.

it can also be noted that most processors wont have built-in operations for
these cases anyways (and many expressions in the above would likely be
reduced to constants by the compiler).

Exactly, this is why I want the compiler to implement the semantics of,
instead of writing tons of macros, so typical to C.

more so, for many tasks, how can one justify using a language like Ada
anyways?...

Do you mean technical or economical justification? We just do not have
enough staff and time to develop reusable software in C++. It is too
expensive and risky to write high integrity software in C++. (We still
develop about 70% in C++, alas)


well, I guess it depends some on domain then.

Well, if your customers accepted any rubbish, you could use random
generator in order to produce code... (:-))

for example, how good of support does it have for DirectX, OpenGL, Win32
API, ... ?...

No problem, though we don't use either.

how effortlessly does it share data with C, C++, ?...

No problem.

how good is it at implementing customized memory management, VMs, and
self-modifying code?...

Memory management is no problem. VM is a possible target. Code management
is solvable using partitions.

how about easily doing copy/paste porting between languages?... (this is a
major win for many of the mainstream languages, since the similar syntax in
many cases keeps the porting effort fairly low in many cases...)
...

We don't port from C. But there are tools (like c2ada) that do it. Though
in many cases it does not worth the efforts. C code usually suffers a huge
amount of manual micro optimization, which make it unusable.

if the answers are "more effort than C and C++", then there is a problem...

Huh, did you ever try to port a MSVC++ application into Borland C++, or
reverse? Or at least to make one that will be compilable under both?

The answer is much less efforts. This is the major reason why we chose Ada.

to face them effectively, a language has to be without any major detractors,
with integration issues being minimal, and while still offering a general
improvement over many of their shortcommings.

Yes, yes, switching from Visual Studio 2003 to Studio 2005, been there,
have a shirt...

so, I figure, rather than trying to replace what exists, I will just try to
absorb it, while still hopefully making some improvements in the process
(this is the hard area, as it is difficult to implement things without their
implementation sucking, but if one tries to at least implement it reasonably
faithfully, that is probably ok...).

My impression is that this is likely impossible, to much clutter and
impedance. I think that maybe a better approach is a heterogeneous
middleware which could bridge the parties. Considering networking and
incoming massively multi-core architectures, this stuff will come this or
that why. So why not to use it as a glue on the same processor?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Free FAT16 Filesystem
    ... being an honourable reason. ... Dave, I made every effort 3 weeks ago to have you understand that if you ... >>Murray did not mention Keil in his correspondence to you. ... >>both your compiler AND under Keil's, ...
    (comp.arch.embedded)
  • compiler and metadata, request opinions...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.compilers)
  • misc: compiler and metadata...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.lang.misc)
  • Re: "Sorting" assignment
    ... issue on some ancient compiler doesn't make a lot of sense. ... to his on a few commonly used platforms and compilers, ...  Be sure and call the swap ... reason to find algorithms which operate independent of it. ...
    (comp.programming)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... >convention that has served Fortran for 50 years, is itself, no good ... >reason for change. ... >done, using implicit typing. ... The IBM 1130 compiler could do ...
    (comp.lang.fortran)