Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2078

Re: Wirth-ian languages

Show all headers | View raw

On 2014-04-30, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 29 Apr 2014 15:51:17 +0000 (UTC), Kaz Kylheku wrote:
>
>> On 2014-04-29, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On Mon, 28 Apr 2014 21:46:00 -0400, Rod Pemberton wrote:
>>>
>>>> So, let's list some (what I recall right now...) of what I think
>>>> C gets correct:
>>>> 
>>>> 1) pointers
>>>
>>> Since C did almost everything wrong. I will comment only on pointers, which 
>>> is also an easy game. What is wrong with them:
>>>
>>> 1. Pointer types are improperly typed as they are matched by structure. 
>>> Thus you cannot have two distinct pointer types for the same target type. 
>>> The feature extremely important for building sorted containers and custom 
>>> memory pools.
>> 
>> "Extremely" is a hyperbole, since people have developed these things in C
>> without even so much a fleeting thought such as "I could use pointer type names
>> based on name equivalence".
>
> It is not about Turing-completeness of C, it is about pointer design. Yes,
> people don't even aware of a possibility to automatically select the memory
> pool based on the pointer type. Not possible, per wrong design.

Indeed, C has very little compile-time polymorphism.

(The successor language C++ adds considerable compile-time polymorphism, while
maintaining strong backward compatibility. C++ hasn't completely succeeded in
displacing C.)

>> Any decent C compiler has a warnings for uninitialized locals,
>
> Record fields, dynamically allocated objects?

In C, an aggregate or struct field cannot be individually initialized, such
that others are left uninitialized.  If the object has an initializer, all
members are initialized.

The problem of partially initialized objects occurs when objects are
left uninitialized and then configured member by member.

  (This is, ironically, a big problem in C++, rather than C. In C++, when you
  define a constructor, that constructor takes all responsibility for
  initializing an object, and an atomic C-like initialization isn't possible.)

Dynamically allocated objects can be produced by a function that returns all
zero memory, like calloc, or your own wrapper for malloc.

   struct foo *p_dynamic_foo = calloc(sizeof *pf, 1);

   struct foo local_foo = { 0 }; /* all fields are initialized */

Another technique:

   static const struct foo blank_foo; /* "blank" static structure */

   struct foo *ptr = malloc(sizeof *pf);

   *ptr = blank; /* initialize allocated object by copying the blank */

(This two-step approach avoids relying on a pattern of a all-zero bits
producing 0.0 floating-point values and null pointers.)

> Anyway, it is a halting problem. Trivially:

A perfectly accurate diagnostic is not only equivalent to solving the Halting
problem, but it requires access to functions in external compilation units, and
knowledge whether the function in question is ever called, which could depend
on inputs to the program and events. In other words, it is in fact intractable.

The Halting Problem is primarily of academic importance; it requires that we
have a complete description of the entire program that is to be analyzed, and
its complete input.

But we do not need a perfectly accurate diagnostic for uninitialized variables
in the real world; a suspicion is enough.

>    int x;
>    int * y;
>
>    if (HALT (p)) y = &x;
>
> So any such check must necessarily generate false negatives or false
> positives.

If there is any suspicion that the variable is uninitialized, the case
can be made that it needs to be fixed. If a machine finds it hard to tell
whether the variable is uninitialized, a human being will also find it hard to
tell.

Even if HALT(p) (which is in a library somewhere) always returns true today,
so that the assignment always executes whenever this function is called,
someone could change the defnition of HALT so that it no longer always returns
true. When HALT changes, the above code does not get recompiled.

Generating a rational suspicion is easy; it doesn't require solving the Halting
Problem.  If it's obvious that the variable is used uninitialized, emit a
confident diagnostic. Otherwise if it is not obvious that the variable is
initialized, emit a "possibly uninitialized" warning. If your compiler is told
to treat warnings as errors, then the build fails.

There is no reason to have false negatives (neglect to identify suspicious cases).

When we fix the false positive with "int *y = NULL", we are at that point no
worse off than a language which forces this automatically, and we can still
leave variables uninitialized in cases that are obviously safe.

> And it is not in C programming culture to pay much attention to silly
> compiler warnings, anyway.

That is neither here nor there. Every language that has ever been popular has
had attracted the goofballs, and always will.  It is a social problem.

> Anyway, a precaution that can be done by compiler but left to the
> programmer is a language design fault, which C pointers are.

Not every precaution that can be done by the compiler *should* be done.

Static checking is bane of programming. Ideally, everything should be dynamic,
especially type and dispatch. Binding should always be as late as possible.

Write in a dynamic language, and leave C for the device drivers, codecs,
OS schedulers, etc.

>>> 4. Pointer arithmetic is a low level hack which should not be there, 
>>> because it does not make any sense for variable sized targets or advanced 
>>> structures like graphs and trees.
>> 
>> Pointer arithmetic is necessary for managing variable-sized targets,
>> like records that have multiple variant fields, all in the same linear
>> memory block. These could be stuck into a graph structure.
>
> No. If you need a pointer to the next element you don't have to compute it.
> You just store it. Otherwise, see the position #1.

But then you're dictating to me the memory layout.

Firstly, I don't like that; I'm the designer of my program, I choose the layout.

Now I can live with dictation of memory representations in a nice, high-level
language (e.g. Lisp: I don't care what a cons cell looks like on the heap).
But I still need a language or sub-language for those cases when I do want to
control the layout.

Secondly, what if this is a third-party memory-mapped file where the layout is
imposed?

When the programming language interferes with implementing third-party
requirements, it's a poor language (at least for the problem domain at hand).

> If pointers were
> properly designed as ADTs, there would be no problem to define arithmetic
> on *some* of them as needed. Instead of that the language enforces blanket
> garbage semantics on all of them. Which is a language design fault.

I've never seen pointer arithmetic happen by accident in C code.
This problem Just Doesn't Happen (TM). (Like, "Oops, how did that completely
pointless ++ get onto that ptr variable? I didn't write that!")

I've seen arithmetic wrongly used, of course, but it was used because the
programmer needed and intended it, which is a different problem. If incrementable
pointers were wrapped in an ADT, then the programmer would have used the ADT
in that situation.

That said, there are pointers in C that do not support arithmetic: pointers
to incomplete types.  One incomplete type is void: void * pointers do not
support pointer arithmetic. (Arithmetic on void * is a well-known GNU C
extension that is diagnosed if you tell GCC to stick to ISO C).

Other incomplete types beside "void" are incomplete arrays and incomplete
structure, the latter of which are very useful:

   struct foo *p;  /* no definition of struct foo in scope */
                   /* arithmetic on p not allowed */

Pointers to incomplete struct types are often used in library or module API's.
The client doesn't know what struct foo is, and cannot perform arithmetic
on pointers to struct foo.  The implementation code, of course, can.

(We are sure on a roll. Let's see what utter basics you don't know about C ...)

>> The demand for C toolchains killed those architectures, so that's not a problem
>> any more.
>
> So much for being "close to hardware"!

"C is close to the hardware" is simply the clueless mantra of those who haven't
ever seen the cover of an ISO standard.

C isn't that close to the hardware. There is no standard way to disable interrupts,
or read register R7, or peek at the return address that goes back to the
caller, or test the arithmetic overflow flag of the CPU, if it has one, ...

Now C is close *enough* to the hardware that low-level-ish operating system
code, including device drivers, can be ported between machines. E.g. a UART
driver developed on x86 Linux can work on MIPS, if the same peripheral chip is
available. Furthermore, that driver is not at any serious disadvantage compared
to one written in assembly language for either processor.

>> This is not a "huge problem" in the world; on the contrary, it is a
>> non-problem, now that cheap 64 bit machines are available to consumers.
>
> Well, the balance between the cost of a CPU cycle vs. memory byte has
> shifted towards CPU. It is difficult to say whether that will stay so. When
> massively parallel architectures will arrive, the model of shared memory
> will inevitable die. There is no way to share memory between thousands of
> cores. This might shift the balance back, away from flat, isotropic memory
> models...

There is no way to share memory between millions of machines on an internet,
yet they all use a TCP/IP stack written in C.

A massively parallel machine with many cores will still have local memories,
with some software that uses them conventionally.

>> What would constitute sufficient difficulty in the integer-pointer conversion?
>> Sacrificing a goat for each instance?
>
> Making meaningless conversions unnecessary?

So what then implements the requirements served by those conversions?
Converting a number to a pointer is something which is used because it is needed.

>>> 7. Each object in C is assumed to be addressable, i.e. the &-operation is 
>>> defined on each object.
>> 
>> Variables declared "register" cannot have this operation applied to them.
>> 
>> But even without this, the analysis is very easy for determining whether or not
>> a declared object is subject to the & operator over its scope.
>
> So, the program semantics and legality may depend on the outcome of
> register optimization?

The register storage class means that taking the address of the object is a
diagnosable constraint violation.

(It is additionally intended to be an optimization hint at the same time,
that access to the object should be fast.)

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Wirth-ian languages bruce axtens <bugmagnet@outlook.com> - 2014-04-28 16:23 +0000
  Re: Wirth-ian languages Joe Hynes <theda@southpark.net> - 2014-04-28 17:31 +0000
    Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 18:47 +0000
      Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-28 20:35 +0100
        Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 20:18 +0000
          Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-28 22:50 +0100
            Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 00:03 +0100
              Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 23:51 +0000
              Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 07:59 +0100
                Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 10:04 +0100
                Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 11:33 +0100
                Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:41 -0400
            Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 21:46 -0400
              Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 08:24 +0100
                Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:33 -0400
                Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 14:38 +0100
                Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 21:28 -0400
                Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-05-01 10:44 +0100
              Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-04-29 09:59 +0200
                Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 15:51 +0000
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-04-30 10:57 +0200
                Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-30 15:47 +0000
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 10:18 +0200
                Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 16:56 +0000
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 10:10 +0200
                Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-30 18:27 +0100
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 10:18 +0200
                Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 17:10 +0000
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 09:22 +0200
  Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 20:59 -0400
    Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 21:10 -0400
    Re: Wirth-ian languages Nils M Holm <news2009@t3x.org> - 2014-04-29 07:52 +0000
    Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 09:45 +0100
  Re: Wirth-ian languages Jacko <jackokring@gmail.com> - 2014-04-29 05:37 -0700

csiph-web