d-programming-language.org

[Dmitry Olshansky]

On 05.07.2011 10:35, Max Klyga wrote:
> On 2011-07-05 08:31:46 +0300, Dmitry Olshansky said:
>
>> On 05.07.2011 1:10, bearophile wrote:
>>> Steven Schveighoffer:
>>>
>>>> Or, use a separate type which throws the errors if you wish.
>>> I have recently explained why this is not good enough, or even 
>>> currently impossible:
>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950 
>>>
>
>
> I
>>>
>>>> don't want
>>>> runtime errors thrown in code that I didn't intend to throw.  most 
>>>> of the
>>>> time, overflows will not occur, so I don't want to go through all 
>>>> my code
>>>> and have to throw these decorations up where I know it's safe.
>>> The idea is to add two switches to DMD that activate the integral 
>>> overflows (one for signed and one for signed and unsigned). If you 
>>> compile your code without those, the runtime tests will not happen.
>>>
>>>
>>>> Besides, D is a systems language, and has no business doing checks
>>>> on every integer instruction.
>>> This argument doesn't hold, Delphi and Ada too are system languages.
>> In case of Delphi that's a bit of  stretch to say least, e.g. it 
>> _still_ lacks normal pointer arithmetic:
>>
>> <quote>
>> In Delphi 2009, pointer arithmetic, as usable for the  PChar  type 
>> (and  PAnsiChar  and  PWideChar), is now also possible for other 
>> pointer types. When and where this is possible is governed by the 
>> new  $POINTERMATH  compiler directive.
>>
>> Pointer arithmetic is generally switched off, but it can be switched 
>> on for a piece of code using|{$POINTERMATH ON}|, and off again 
>> using|{$POINTERMATH OFF}|. For pointer types compiled with pointer 
>> arithmetic (pointer math) turned on, pointer arithmetic is generally 
>> possible.
>>
>> Apparently, in/Delphi 2009/, the new pointer arithmetic doesn't work 
>> as intended for pointers to/generic/types yet. Whatever type the 
>> parametric type is instantiated as, indices are not scaled 
>> by|SizeOf(T)|, as expected.
>> </quote>
>> http://rvelthuis.de/articles/articles-pointers.html
>> also:
>> http://stackoverflow.com/questions/4303880/delphi-pointer-arithmetic
>
> Pointer arithmetic is not strictly necessary for a systems language. 

Well, given this some more thought, it's not exactly necessary, much 
more needed is ability to treat some memory location as either address 
or integer.  Having that arithmetic can be done on integers and then 
casted back as pointers again, though that does gives you even _less_ 
safety the direct pointer arithmetic (at least it disallows /* on 
pointers ... and they track size of object).

> Several operating systems were written in Oberon. It has no pointer 
> arithmetics. Should it be considered not a systems language?
>

IMHO, yes,  generally the features to work as close as possible to 
"metal" should be first-class in a systems language, else you could fit 
almost any language with meta library of "intrinsic functions" and call 
it a systems language (that would make sense as long as you have a 
native code compiler).

Looking on Oberon it seems to do the latter i.e. stay Pascal but use 
intrinsic functions (spec of Oberon-07, page 15):

SYSTEM additional definitions that are particular to the specific, 
underlying computer. In the
following, v stands for a variable, x, a, and n for expressions.
Function procedures:
Name         Argument types                Result type Function
ADR(v)        any INTEGER                         address of variable v
SIZE(T)        any type INTEGER                size in bytes
BIT(a, n)      a, n: INTEGER BOOLEAN    bit n of mem[a]

Proper procedures:
Name          Argument types                         Function
GET(a, v)   a: INTEGER; v: any basic type    v := mem[a]
PUT(a, x)   a: INTEGER; x: any basic type     mem[a] := x

Ti seems Go took the same route, but also using magic types:
http://golang.org/pkg/unsafe/

-- 
Dmitry Olshansky