freepascal.ru

доработать указатели до ума, реализовать нормальные адресные операции, запретиь всякие извращения по смешению типов (int+pointer например - сам этим грешу иногда).
Ведь сами указатели не страшны - страшно не верное использование их.

Все это делается определением специального численного типа. И регламентацией прямого доступа к железу, включая память - системщикам оно надо. Этакая платформенно-зависимая библиотека System.
Но зачем это вводить непосредственно в язык?

предложи альтернативы структур работы с произвольными массивами данных?
связанные списки?

слабо представляю как без указателей можно написать чтото более менее серъезное

предложи альтернативы структур работы с произвольными массивами данных?

Массивы+записи+варианты+рекурсивные типы.
Например (синтаксис а-ля Паскаль)

tList(tElement) = NullList | record Head:tElement; Tail:tList(tElement) end;

Список может быть или пустым (NullList) или быть записью, с полями Head (тип элемента) и Tail - список (тип элемента).
И никаких указателей на уровне языка

а вариант с не определённым содержимым массива? на этапе компиляции тип данных может быть не известен
варианты не предлагать.

на этапе компиляции тип данных может быть не известен

Это в языке со статической типизацией?

внешний мир не типизирован - а мы (программа и компилятор общаются с внешним миром)

внешний мир не типизирован

Еще как типизирован Только типизация динамическая.
Но вернемся к нашим баранам - где в "идеальном языке" необходима нетипизированность?

мой пример - пишу компонету доступа к птице - внутренний буфер данных - кажды раз запросы/данные новые

zub писал(а):слабо представляю как без указателей можно написать чтото более менее серъезное

По мне, так как раз наоборот - с указателями что-нибудь серьезное будешь писать долго и упорно, тратя уйму времени на отладку, вылавливание ошибок, устранение утечек. Повышаются требования к квалификации программиста, увеличивается время разработки и затраты на проект.

В прикладном программировании указатели не нужны. А вот в системном без них никак. Вопрос в том, для чего язык. Если двустволка для двух зайцев, то надо делать указатели.

мой пример - пишу компонету доступа к птице - внутренний буфер данных - кажды раз запросы/данные новые

Ага, обмен данными с жестко заданной реализацией. Т.е. системное программирование. Такие вещи лучше реализовать как часть RTL, а не языка.

В прикладном программировании указатели не нужны. А вот в системном без них никак. Вопрос в том, для чего язык. Если двустволка для двух зайцев, то надо делать указатели.

Для системного программирования - надо. Но не в языке, а в специальной стандартизированной библиотеке. Тогда и прикладникам проще, и системники будут сыты.

Bonart писал(а):Такие вещи лучше реализовать как часть RTL

этот пруть ведёт в тупик - сегодня одну часть делаем преопределённой, завтра другую. Это не выход.

Bonart писал(а):Для системного программирования

Я вобще против введени различий: системное программирование - прикладное програмирование

ты либо программируеш либо нет

мы тут обсуждаем язык широкого уровня применяемости - по функциналу не менбше чем текущий FPC
и чем мне нравится FPC (в отличии от дельфина) что он сам себя компилирует и все библиотеки свои (в т.ч. system) он собирает честно.

мы тут обсуждаем язык широкого уровня применяемости - по функциналу не менбше чем текущий FPC

Тогда, безусловно, указатели нужны. А уж использовать их или нет, пусть программист сам решает.

alexs писал(а):этот пруть ведёт в тупик - сегодня одну часть делаем преопределённой, завтра другую. Это не выход

В честь чего? ЧТО надо переопределять? Реализацию? Так она для разных платформ всегда переопределяется.

alexs писал(а):Я вобще против введени различий: системное программирование - прикладное програмирование

Этот путь ведет в тупик. Системное программирование ТРЕБУЕТ машинно-ориентированного языка (ассемблер, Си).
Прикладное ТРЕБУЕТ абстрагирования от конкретной платформы.
Простейший пример - на каком языке пишется львиная доля кода игр?

alexs писал(а):и чем мне нравится FPC (в отличии от дельфина) что он сам себя компилирует и все библиотеки свои (в т.ч. system) он собирает честно.

FPC сейчас - машинно-ориентрованный язык. Вдобавок весьма эклектичный.

Deepthroat писал(а):Тогда, безусловно, указатели нужны. А уж использовать их или нет, пусть программист сам решает.

Только не на уровне языка, а на уровне стандартной библиотеки. Т.е. если надо писать с ориентацией на конкретную реализацию - пожалуйста, но указывать это придется явно. (библиотека System с типами Int16, Int32, Int64, Byte, процедурой memcopy и т.д и т.п.)

Bonart писал(а):В честь чего? ЧТО надо переопределять? Реализацию? Так она для разных платформ всегда переопределяется.

в части объявления частью самого компилятора

чем меньшье конструкций языка вшито в сам компилятор - тем лучше - в паскале самый яркий пример такой вшитой возможности - это процедура writeln

согласно твоей логики - большую часть возможностей (библиотек) ты предлагаеш аналогично зашить в компилятор

не нужно этого.

я тебе открою секрет - меня как програмиста вобще не должна инетересовать внутренне устройство типа pointer - я просто знаю что о он есть и всё - это как другие атомарные типы

точно также нет особой нужды в посвседневном коде использовать Int16, Int32, Int64 - есть тип integer

и как сейчас рабают операции с типом integer - также свой набор операций должен быть и для указателей
вот реализацию их - чтобы сделать их ошибко-безопасными и надо обсуждать
а на факт наличия или не наличия указателей

Bonart писал(а):Простейший пример - на каком языке пишется львиная доля кода игр

если ты мне скажеш что это не С/С++ - я тебе не поверю