Здравствуйте, samius, Вы писали:

Помимо этого интересно почитать и возможные решения этой проблемы...
Именно к этому выступления Хоара, Бертран Мейер выпустил статью под названием "Void Safety: Putting an End To the Plague of Null Dereferencing", в которой он предлагает решение этой проблемы. Причем решение это не только предложено, но и реализовано в последней версии Eiffel Studio.

Существует две версии этой статьи: 1-я опубликована в Dr. Dobb's Journal: http://www.ddj.com/architect/219500827
2-я версия, более полная, доступная в виде pdf, например здесь

Здравствуйте, ole!, Вы писали:

S>>Но нужно быть по-настоящему великим, чтобы признавать такие ошибки.

O>нужно быть по-настоящему великим, чтобы их не делать изначально!
O>предложите альтернативу nullptr

data Maybe a = Nothing | Just a

для программеров на c++/c#:

struct Maybe<A> {};
struct Nothing<A> : Maybe<A> {};
struct Just<A> { A value; };

void fun(Maybe<A> x)
{
    print(x.value); // type ERROR

    if (x is Just<A>)
        print( (Just<A>)x.value ); // OK
}

С помощью правильной системы типов можно вынудить программеров писать проверки на null в 100% случаев, потому что иначе оно не будет компилироваться.

Сколько в процессе разработки/поддержки возникает Access violation at (0x00000000/0x00000004/0x00000008), Null pointer exception, и т.д. и т.п.? Их могло не быть.

Здравствуйте, Mazay, Вы писали:

M>>>Угу. И исключения InvalidCastException посыпятся как из приложения на Java 1.4 (пока не было дженериков).
N>>Вот и пусть сыпятся, что лучше, чем реальный доступ по кривому указателю.
M>Чем лучше-то? Тем что вместо NullReferenceException вылетит InvalidCastException? Один фиг проверка в рантайме.

Ты почему-то резко переключил контекст на Java. У неё и так подобной проблемы нет. А вот у C, C++, других полностью статических языков — есть. И для них исключение внятного типа во внятном месте — лучше, чем вылет неизвестно куда.

M>>>int doUseful(MainData* notnull md, AuxData1* notnull ad1, AuxData2* notnull ad2)
M>>>int doUseful(MainData* notnull md, AuxData1* notnull ad1)
M>>>int doUseful(MainData* notnull md, AuxData2* notnull ad2)
M>>>int doUseful(MainData* notnull md)
N>>Это — по-хорошему?? Вот за такое как раз — расстрел через повешение на медленном огне (заменяется на написание драйверов на Excel).
M>А что тебя собственно пугает? То что много функций? Ну тогда напиши код для твоей единой версии doUseful(). Будут те же яйца только на if-ах.

Вот именно, что на if'ах будут не те же яйца, а вменяемый код без дублирования.

Здравствуйте, samius, Вы писали:

N>>Пусть специальный тип. Но в его реализации должно быть не только это. Например, конструирование произвольного указателя из целого числа или из буфера должно быть под соответствующей защитой. Выход за пределы массива или отведённой области — тоже. (Что приводит нас, например, к слайсам Go.)
S>Вот возможность конструирования произвольного указателя и сломает все старания по уходу от null-ов.

Ну почему же. Если такое значение можно присвоить только nullable варианту, именно проблему применения пустого значения это уже решает. Не решает проблему иного левого значения.

N>>Ну почему же. Если часть кода целиком переведена на использование такого notnull (а также использование честно полученных указателей, см. выше) — то в ней уже можно не опасаться таких проблем. А дальше постепенной передвижкой границы мы сузим опасные места до предела...
S>Мы только лишь одни исключения заменим другими.

Это вполне нормальный подход. Например, резко сокращается отладка: не надо лезть внутрь сложного кода, выискивая, кто начудил — проверка произведена на входе, проблема ясна и однозначна. Варианта же вообще обойтись без исключений я не вижу: можешь придумывать какие угодно Nullable<тип>, Option<тип> — останется один принципиальный факт: если что-то может отсутствовать, его присутствие нужно проверять. Я не боюсь тут формулировок в стиле "если где-то нет кого-то, значит, кто-то где-то есть": мы идём от задачи и от удобства её реализации, и если где-то удобнее наложить ограничение при компиляции — накладываем при компиляции, а если удобнее при выполнении — накладываем при выполнении. И контроль условий при выполнении — поддерживается исключениями при их нарушении. А будет это отдельный параметр, элемент хэша или списка или нечто из заранее неизвестного типа — уже менее важно.

N>>Ну так у тебя будут в итоге те же яйца, но вид в профиль. Например, мне в Erlang'е несколько раз приходилось делать операцию типа "выберем значение из проплиста во втором элементе в пятом поле, а если его нет — из проплиста в третьем элементе третьего поля, а если и его нет — из седьмого элемента". Выглядит кошмарно, но деться некуда. Не будет у тебя null — заменят просто на факт присутствия элемента в какой-то структуре данных.
S>Если при этом исключится возможность разыменования null-ов, то это будут уже другие яйца!

Почему это вдруг другие? Тут нет никакой принципиальной разницы. Если у меня процесс свалится от того, что я пытаюсь получить XState#xstate.nbars, хотя XState вместо структуры xstate оказался атомом undefined — то по последствиям это ничуть не отличается от разыменования null'а: будет исключительная ситуация и, если не перехвачена — гибель процесса.

Даже на Си у NULL нет неуловимых особенностей в большинстве случаев. Да, в Linux'е упустили — бывает. Но в 99.99% применений доступ на достаточно длинный участок от 0 запрещён и ловится сразу. От замусоренных указателей проблем больше и они хуже.

S>Преимущество в том, что в Option не добраться до значения (указателя), если его нет.

Если разыменование допустимо только для notnull, последствия не меняются.

S>>>Соглашусь, что человек меняется. Но эти изменения не имеют случайный характер. Взгляды на одни и те же вещи могут меняться в том числе и благодаря накопленному опыту, а не просто потому что человек стал другим.

N>>В данном случае не могу согласиться. Если бы речь шла об опыте и о его грамотном осознании, была бы предложена альтернатива. Как легко видеть, альтернативы не предложено, а реально она появилась в пределах доступа широких народных масс не раньше пары последних лет (почему мы собственно эту дискуссию и ведём). Это никак не 65-й год.

S>Я не был на той конференции. Быть может формат конференции не позволил Хоару указать альтернативу, а может просто в википедии об этом не написали.
S>Да и нужна ли была альтернатива тогда? По высказыванию Хоара
S>

S>But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.

S>можно косвенно судить о том, что необходимости в null-е не было. Да и тот факт что в ALGOL-е не было null-а до 65-го года, тоже кое-что значит.

Ваш вывод грубо неверен. В это время шла разработка Алгола-68. Предшественниками были Алгол-60 и вариации на его тему, которые с памятью работали примерно как учебный Паскаль имени Вирта — то есть никак. Указатель вводился для работы с динамической памятью. Отсюда возвращаемся к моему начальному тезису — признак отсутствия данного надо как-то показывать, особое значение — путь дешёвый, выделенный флаг — дорогой, а другие описанные здесь методы — вообще неподъёмны на тот момент.

Здравствуйте, netch80, Вы писали:

N>По твоему описанию как раз и получилась вариация на тему nullable.
Нет. У меня получается чистое решение которое работает для любых типов, а не только указателей.
Это нужно ибо опциональными могут быть значения любых типов.

N>При этом детали её внутреннего устройства сокрыты (в реальности может передаваться и отдельный флаг, но где он — ведает компилятор, а не программист).
Вот именно что скрыты, а значит не парят мозг программисту. И это главное.
На физическом уровне может быть что угодно.
Например в случае если для типа которым параметризовали Option существуют значения которые он не может принимать то для None можно использовать одно из этих значений. Для указателей это null.
Если это структура данных имеющая дырки для выравнивания то флаг можно разместить в одной из дырок не увеличив физический объем данных.
Такие хаки как размещение полезных данных внутри паддинга и определение физически не допустимых значений может безопасно делать только компилятор.
Если же ни то ни другое не подходит то от отдельного флага ты никуда не денешься при всем жилании. Но в данном случае им будет заниматься компилятор, а не программисть.

N>А которая система "моя"? Та, в которой notnull?
Угу.

N>Наверно, никак, но я и не вижу полезности в таком стиле различения, он уже слишком заковырист.
Нет в нем ничего заковыристого.
Например можно взять тот словарь и реализовать на его основе кешь:

class Cache[Key, Value]
{
    private _fn : Key -> Value;
    private _cache : Dictionary[Key, Value] = Dictionary();
    public this(fn : Key -> Value)
    {
        _fn = fn;
    }
    public Get(key : Key) : Value
    {
        match (_cache.Get(key))
        {
        | Some(value) => value;
        | None =>
            def value = _fn(key);
            _cache.Add(key, value);
            value;
        }
    }
}

В данном случае Value может иметь тип Option[T].
Чего в этом примере заковыристого я не понимаю.

N>API действительно почти везде ужасно, но у меня лично ужас вызывают совсем не эти моменты — с ними как раз достаточно легко справиться.
То что с чемто можно лего справится не значит что это лучше чем решение где не надо справляться.

N>А вот попробуй справься, например, с тем, что O_NONBLOCK ставится не на операцию или дескриптор, а на ofile в целом. (В Windows, однако, это ещё кошмарнее сделано.)
Неблокирующие IO вообще костыль нужный исключительно из-за того что современные ОС плохо работают когда много процессов.

N>>>А нужна такая, которая не позволит разыменовать пустой указатель.
WH>>Нужна такая которая не позволяет их иметь.
N>Это нереальное и непродуктивное требование.
Многие языки живут без пустых указателей и не имеют проблем.
Так что и реальность и продуктивность этого требования продтверждена практикой.
А у тебя одни слова.

N>Маскированные варианты через тот же Option не меняют общий подход.
Какой такой "общий подход"?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, samius, Вы писали:

S>>Вот возможность конструирования произвольного указателя и сломает все старания по уходу от null-ов.

N>Ну почему же. Если такое значение можно присвоить только nullable варианту, именно проблему применения пустого значения это уже решает. Не решает проблему иного левого значения.

Пример: выделяю и обнуляю память, после чего создаю непустой указатель на эту память и интерпретирую его как экземпляр типа, содержащий notnullable указатели. Эти указатели будут содержать null-ы.

S>>Мы только лишь одни исключения заменим другими.

N>Это вполне нормальный подход. Например, резко сокращается отладка: не надо лезть внутрь сложного кода, выискивая, кто начудил — проверка произведена на входе, проблема ясна и однозначна.

Это если все указатели заменить на notnallable. А если оставить их nullable-ами (а такие нужны будут), то проблема не исчезнет.

S>>Если при этом исключится возможность разыменования null-ов, то это будут уже другие яйца!

N>Почему это вдруг другие? Тут нет никакой принципиальной разницы. Если у меня процесс свалится от того, что я пытаюсь получить XState#xstate.nbars, хотя XState вместо структуры xstate оказался атомом undefined — то по последствиям это ничуть не отличается от разыменования null'а: будет исключительная ситуация и, если не перехвачена — гибель процесса.
Ну это примерно то же самое, что пытаться привести 42 к типу указатель на список (без проверки) с надеждой что по адресу 42 действительно окажется список. С той лишь разницей, что XState#xstate.nbars будет в среднем чаще давать ожидаемый результат.

N>Даже на Си у NULL нет неуловимых особенностей в большинстве случаев. Да, в Linux'е упустили — бывает. Но в 99.99% применений доступ на достаточно длинный участок от 0 запрещён и ловится сразу. От замусоренных указателей проблем больше и они хуже.
А я не спорю, что замусоренные указатели тоже проблема. Но это другая проблема и решения для нее другие.

S>>Преимущество в том, что в Option не добраться до значения (указателя), если его нет.

N>Если разыменование допустимо только для notnull, последствия не меняются.

Ну как же, в случае Option нарваться на исключение можно только если

S>>>>Соглашусь, что человек меняется. Но эти изменения не имеют случайный характер. Взгляды на одни и те же вещи могут меняться в том числе и благодаря накопленному опыту, а не просто потому что человек стал другим.

N>>>В данном случае не могу согласиться. Если бы речь шла об опыте и о его грамотном осознании, была бы предложена альтернатива. Как легко видеть, альтернативы не предложено, а реально она появилась в пределах доступа широких народных масс не раньше пары последних лет (почему мы собственно эту дискуссию и ведём). Это никак не 65-й год.

S>>можно косвенно судить о том, что необходимости в null-е не было. Да и тот факт что в ALGOL-е не было null-а до 65-го года, тоже кое-что значит.

N>Ваш вывод грубо неверен. В это время шла разработка Алгола-68. Предшественниками были Алгол-60 и вариации на его тему, которые с памятью работали примерно как учебный Паскаль имени Вирта — то есть никак. Указатель вводился для работы с динамической памятью. Отсюда возвращаемся к моему начальному тезису — признак отсутствия данного надо как-то показывать, особое значение — путь дешёвый, выделенный флаг — дорогой, а другие описанные здесь методы — вообще неподъёмны на тот момент.

Допускаю, что не верен. Это даже не вывод а догадка. Не знаток Алгола.

Полагаю, что не неподъемны, а более сложны в реализации на тот момент, чем nullptr. Если бы Хоар мог тогда предвидеть последствия, имхо, его решение могло бы быть другим.

Здравствуйте, samius, Вы писали:

S>>>Вот возможность конструирования произвольного указателя и сломает все старания по уходу от null-ов.
N>>Ну почему же. Если такое значение можно присвоить только nullable варианту, именно проблему применения пустого значения это уже решает. Не решает проблему иного левого значения.
S>Пример: выделяю и обнуляю память, после чего создаю непустой указатель на эту память и интерпретирую его как экземпляр типа, содержащий notnullable указатели. Эти указатели будут содержать null-ы.

Мнэээ... что значит "интерпретирую"? В языке такую защиту имеет смысл делать только тогда, когда такое "интерпретирую" уже исключено другими средствами (в общем именуемыми managed code). Тогда такой "интерпретации" не будет за пределами тщательно огороженных мест.

S>>>Если при этом исключится возможность разыменования null-ов, то это будут уже другие яйца!
N>>Почему это вдруг другие? Тут нет никакой принципиальной разницы. Если у меня процесс свалится от того, что я пытаюсь получить XState#xstate.nbars, хотя XState вместо структуры xstate оказался атомом undefined — то по последствиям это ничуть не отличается от разыменования null'а: будет исключительная ситуация и, если не перехвачена — гибель процесса.
S>Ну это примерно то же самое, что пытаться привести 42 к типу указатель на список (без проверки) с надеждой что по адресу 42 действительно окажется список. С той лишь разницей, что XState#xstate.nbars будет в среднем чаще давать ожидаемый результат.

Да, действительно, практически то же самое. Именно поэтому я не считаю саму по себе возможность иметь указателю пустое значение (null) чем-то более стрёмным, чем вообще свободная генерация любого значения как указателя.

N>>Даже на Си у NULL нет неуловимых особенностей в большинстве случаев. Да, в Linux'е упустили — бывает. Но в 99.99% применений доступ на достаточно длинный участок от 0 запрещён и ловится сразу. От замусоренных указателей проблем больше и они хуже.
S>А я не спорю, что замусоренные указатели тоже проблема. Но это другая проблема и решения для нее другие.

Да, другая. При этом более важная и, что тут наиболее существенно — перекрывающая проблему пустых значений — в смысле, что пока нет защиты от внедрения мусора, null'ы лечить бесполезно.

N>>Ваш вывод грубо неверен. В это время шла разработка Алгола-68. Предшественниками были Алгол-60 и вариации на его тему, которые с памятью работали примерно как учебный Паскаль имени Вирта — то есть никак. Указатель вводился для работы с динамической памятью. Отсюда возвращаемся к моему начальному тезису — признак отсутствия данного надо как-то показывать, особое значение — путь дешёвый, выделенный флаг — дорогой, а другие описанные здесь методы — вообще неподъёмны на тот момент.
S>Допускаю, что не верен. Это даже не вывод а догадка. Не знаток Алгола.
S>Полагаю, что не неподъемны, а более сложны в реализации на тот момент, чем nullptr. Если бы Хоар мог тогда предвидеть последствия, имхо, его решение могло бы быть другим.

Даже без тех сложностей Алгол-68 уже получился значительно сложнее, чем могли себе позволить на практике. Точно так же рядом дохли PL/1, Ada и прочие. А если бы ввели какие-то вариации на тему nullable, так он и до спецификации не дошёл бы.
См. ряд соседних веток про Go.

Здравствуйте, WolfHound, Вы писали:

N>>По твоему описанию как раз и получилась вариация на тему nullable.
WH>Нет. У меня получается чистое решение которое работает для любых типов, а не только указателей.

Я нигде не говорил, что оно только для указателей. Nullable в общем случае может быть и int, и record...

N>>При этом детали её внутреннего устройства сокрыты (в реальности может передаваться и отдельный флаг, но где он — ведает компилятор, а не программист).
WH>Вот именно что скрыты, а значит не парят мозг программисту. И это главное.

Да на сейчас-то я с этим согласен. А вот на 1965 — ой нет...

N>>API действительно почти везде ужасно, но у меня лично ужас вызывают совсем не эти моменты — с ними как раз достаточно легко справиться.
WH>То что с чемто можно лего справится не значит что это лучше чем решение где не надо справляться.
N>>А вот попробуй справься, например, с тем, что O_NONBLOCK ставится не на операцию или дескриптор, а на ofile в целом. (В Windows, однако, это ещё кошмарнее сделано.)
WH>Неблокирующие IO вообще костыль нужный исключительно из-за того что современные ОС плохо работают когда много процессов.

Увы, не костыль.

N>>>>А нужна такая, которая не позволит разыменовать пустой указатель.
WH>>>Нужна такая которая не позволяет их иметь.
N>>Это нереальное и непродуктивное требование.
WH>Многие языки живут без пустых указателей и не имеют проблем.
WH>Так что и реальность и продуктивность этого требования продтверждена практикой.
WH>А у тебя одни слова.

У меня рассмотрение в том же контексте, в котором Хоар, 1965-й год и язык уровня не выше Алгола-68, а то и ниже. Для этого уровня, nullable — предел сложности. Конечно, через 44 года можно на это смотреть свысока, но тогда это тема вообще не данного треда и некорректный подход.

Здравствуйте, netch80, Вы писали:

N>Я нигде не говорил, что оно только для указателей. Nullable в общем случае может быть и int, и record...
А для Nullable?
Зачем нам нужен дважды nullable я тебе показал.

N>>>При этом детали её внутреннего устройства сокрыты (в реальности может передаваться и отдельный флаг, но где он — ведает компилятор, а не программист).
WH>>Вот именно что скрыты, а значит не парят мозг программисту. И это главное.
N>Да на сейчас-то я с этим согласен. А вот на 1965 — ой нет...
В алголе были tagged unions.
Так шта твой аргумент идет лесом.

WH>>Неблокирующие IO вообще костыль нужный исключительно из-за того что современные ОС плохо работают когда много процессов.
N>Увы, не костыль.
А зачем?
Вот представь у нас есть легкие процессы как в ерланге и строготипизированные каналы как в сингулярити.
Внимание вопрос: Нахрена нам в этом случае всякие там epoll'ы и прочие извращения?

N>У меня рассмотрение в том же контексте, в котором Хоар, 1965-й год и язык уровня не выше Алгола-68, а то и ниже. Для этого уровня, nullable — предел сложности. Конечно, через 44 года можно на это смотреть свысока, но тогда это тема вообще не данного треда и некорректный подход.
Твои слова опять расходятся с фактами... см выше.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, samius, Вы писали:

S>>Пример: выделяю и обнуляю память, после чего создаю непустой указатель на эту память и интерпретирую его как экземпляр типа, содержащий notnullable указатели. Эти указатели будут содержать null-ы.

N>Мнэээ... что значит "интерпретирую"? В языке такую защиту имеет смысл делать только тогда, когда такое "интерпретирую" уже исключено другими средствами (в общем именуемыми managed code). Тогда такой "интерпретации" не будет за пределами тщательно огороженных мест.

Тогда о каких мусорных указателях речь? Если код managed, то мусорные указатели просто должны исчезнуть из контекста обсуждения.

S>>Ну это примерно то же самое, что пытаться привести 42 к типу указатель на список (без проверки) с надеждой что по адресу 42 действительно окажется список. С той лишь разницей, что XState#xstate.nbars будет в среднем чаще давать ожидаемый результат.

N>Да, действительно, практически то же самое. Именно поэтому я не считаю саму по себе возможность иметь указателю пустое значение (null) чем-то более стрёмным, чем вообще свободная генерация любого значения как указателя.

Свободная генерация указателей в managed среде — нонсенс.

S>>А я не спорю, что замусоренные указатели тоже проблема. Но это другая проблема и решения для нее другие.

N>Да, другая. При этом более важная и, что тут наиболее существенно — перекрывающая проблему пустых значений — в смысле, что пока нет защиты от внедрения мусора, null'ы лечить бесполезно.

Вот у меня в рамках .net платформы проблема мусора в указателях не стоит. А проблемма null-ов стоит и еще как. Можно сказать торчит! Т.к. в проекте со многомегабайтным кодом с разрешением этой проблемы связано значительное кол-во кода. Возможно речь о процентах от общего объема (наверняка более 1%).

S>>Полагаю, что не неподъемны, а более сложны в реализации на тот момент, чем nullptr. Если бы Хоар мог тогда предвидеть последствия, имхо, его решение могло бы быть другим.

N>Даже без тех сложностей Алгол-68 уже получился значительно сложнее, чем могли себе позволить на практике. Точно так же рядом дохли PL/1, Ada и прочие. А если бы ввели какие-то вариации на тему nullable, так он и до спецификации не дошёл бы.
N>См. ряд соседних веток про Go.

Здесь спорить не буду, ибо не подкован.

Здравствуйте, WolfHound, Вы писали:

N>>Я нигде не говорил, что оно только для указателей. Nullable в общем случае может быть и int, и record...
WH>А для Nullable?

Почему бы и нет? ;)

WH>Зачем нам нужен дважды nullable я тебе показал.

Мне этот подход не понравился, но если тебе годится — то пусть. В общем, возможность таких вариантов действительно склоняет в сторону nullable, а не notnull. (Надо бы это в go-nuts скормить, если они ещё сами не нашли)

N>>>>При этом детали её внутреннего устройства сокрыты (в реальности может передаваться и отдельный флаг, но где он — ведает компилятор, а не программист).
WH>>>Вот именно что скрыты, а значит не парят мозг программисту. И это главное.
N>>Да на сейчас-то я с этим согласен. А вот на 1965 — ой нет...
WH>В алголе были tagged unions.
WH>Так шта твой аргумент идет лесом.

Ты спешишь с выводами. Во-первых, они появились только в A-68, если я правильно раскопал историю. На 1965-й они если и были придуманы, то только-только вводились и ещё не были привычны. Во-вторых, делать Option<> через них — заметный кусок ручной работы, а главное — неконтролируемо компилятором. Я же говорил о варианте, когда этим управляет компилятор — для этого не требуется собственно поддержки tagged unions в самом языке, но требуется — в компиляторе. jIMHO, конечно, но на тот момент это было очень сложным.

Если же сам программист реализует такое, то ему использовать null value (опять же jIMHO, но по практике) проще, чем tagged union. И памяти это меньше кушает, раза в 2 (16-битные указатели плюс выравнивание => 4 байта вместо 2. сэкономить можно только когда таких TU много, ценой затрат времени процессора — тоже дорогой ресурс)

WH>>>Неблокирующие IO вообще костыль нужный исключительно из-за того что современные ОС плохо работают когда много процессов.
N>>Увы, не костыль.
WH>А зачем?
WH>Вот представь у нас есть легкие процессы как в ерланге и строготипизированные каналы как в сингулярити.
WH>Внимание вопрос: Нахрена нам в этом случае всякие там epoll'ы и прочие извращения?

Ты пытаешься забраться на высокий уровень реализации. А теперь представь себе всё это на уровне ядерного API... сразу появляется дохрена проблем. Примеры борьбы с ними есть, но что-то ни один не выжил дальше опытной установки.

Впрочем, может, это и костыль — тут поле не точных фактов, а эмоциональных и эстетических оценок, не буду твёрдо возражать. Но если костыль — то не от дофига процессов, а от сложности реализации на границе user land и kernel land.

N>>У меня рассмотрение в том же контексте, в котором Хоар, 1965-й год и язык уровня не выше Алгола-68, а то и ниже. Для этого уровня, nullable — предел сложности. Конечно, через 44 года можно на это смотреть свысока, но тогда это тема вообще не данного треда и некорректный подход.
WH>Твои слова опять расходятся с фактами... см выше.

См. выше.

Здравствуйте, samius, Вы писали:

S>Свободная генерация указателей в managed среде — нонсенс.

Отлично. Значит, в ней уже имеет смысл побороться на тему nullable/option/etc. Что и требовалось доказать.:)

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, samius, Вы писали:

S>>Свободная генерация указателей в managed среде — нонсенс.

N>Отлично. Значит, в ней уже имеет смысл побороться на тему nullable/option/etc. Что и требовалось доказать.

Э не, это не надо было доказывать. Борьба уже вовсю идет в случае с F# (может и еще где).

Здравствуйте, netch80, Вы писали:

N>>>Я нигде не говорил, что оно только для указателей. Nullable в общем случае может быть и int, и record...
WH>>А для Nullable?
N>Почему бы и нет?
Тогда у нас получаются tagged unions почти на всю катушку.
И как следствие становится не ясно нахрена нам частный случай если почти за теже деньги можем получить общий?

WH>>Зачем нам нужен дважды nullable я тебе показал.
N>Мне этот подход не понравился, но если тебе годится — то пусть. В общем, возможность таких вариантов действительно склоняет в сторону nullable, а не notnull. (Надо бы это в go-nuts скормить, если они ещё сами не нашли)
Он не просто годится, а когда у нас появляются генерики становится необходим как воздух иначе начинаются проблемы.
Попробуй переписать мой пример с кешем без этого...

N>Ты спешишь с выводами. Во-первых, они появились только в A-68, если я правильно раскопал историю. На 1965-й они если и были придуманы, то только-только вводились и ещё не были привычны.
3 года не большая разница как ни крути.

N>Во-вторых, делать Option<> через них — заметный кусок ручной работы, а главное — неконтролируемо компилятором.
В ML и всех его наследниках именно так и делается. И никаких проблем с этим не возникает.
Тем более что Option нужен не так уж и часто.

N>Я же говорил о варианте, когда этим управляет компилятор — для этого не требуется собственно поддержки tagged unions в самом языке, но требуется — в компиляторе.
Вот это я вообще не понял что ты пытался сказать.

N>jIMHO, конечно, но на тот момент это было очень сложным.
Прошло всего 3 года и оказалось легко. Не смешите мои тапочки.

N>Если же сам программист реализует такое, то ему использовать null value (опять же jIMHO, но по практике) проще, чем tagged union.
Сколько у тебя практики с tagged union в статически типизированном языке? Что-то мне подсказывает что 0.
Ибо как раз на практике знание где значение есть всегда, а где может не быть очень упрощает жизнь.

N>И памяти это меньше кушает, раза в 2 (16-битные указатели плюс выравнивание => 4 байта вместо 2. сэкономить можно только когда таких TU много, ценой затрат времени процессора — тоже дорогой ресурс)
Как это можно оптимизировать я тебе уже сказал.
Оверхед в большенстве случаев будет ноль целых хрен десятых.

N>Ты пытаешься забраться на высокий уровень реализации. А теперь представь себе всё это на уровне ядерного API... сразу появляется дохрена проблем. Примеры борьбы с ними есть, но что-то ни один не выжил дальше опытной установки.
В ОС типа сингулярити я это очень легко представляю.
Но тут нужно начинать дизайн ОС с дизайна базовой ВМ.
Ибо если взять плохую ВМ то все пойдет насмарку. Скажем на JVM или CLR такими вещами заниматься не имеет смысла вообще.

N>Впрочем, может, это и костыль — тут поле не точных фактов, а эмоциональных и эстетических оценок, не буду твёрдо возражать. Но если костыль — то не от дофига процессов, а от сложности реализации на границе user land и kernel land.
Нет ни какой ложки. В смысле граници... Ибо если у нас в основе ОС лежит безопасная ВМ то изоляция процессов получается сама собой причем лучше чем в классических ОС.

Здравствуйте, IT, Вы писали:

S>>Но нужно быть по-настоящему великим, чтобы признавать такие ошибки.

IT>Думаю, если бы не он, то без проблем кто-то другой.

Я бы сказал больше — он слишком себя преувеличил, сказав, что именно он изобрёл null.

Здравствуйте, SergeyT., Вы писали:

ST>Здравствуйте, samius, Вы писали:

ST>Помимо этого интересно почитать и возможные решения этой проблемы...
ST>Именно к этому выступления Хоара, Бертран Мейер выпустил статью под названием "Void Safety: Putting an End To the Plague of Null Dereferencing", в которой он предлагает решение этой проблемы. Причем решение это не только предложено, но и реализовано в последней версии Eiffel Studio.

ST>Существует две версии этой статьи: 1-я опубликована в Dr. Dobb's Journal: http://www.ddj.com/architect/219500827
ST>2-я версия, более полная, доступная в виде pdf, например здесь

Прочитал. Как-то всё запутанно у них получается. По сути их attached/detachable это тот же Option variant либо Nullable<T> на уровне языка. К сожалению, с Eiffel я не знаком, но лично для меня variant и nullable generic гораздо понятней, к тому же имеют сами по себе гораздо более широкое применение.

Здравствуйте, mkizub, Вы писали:

S>>>Но нужно быть по-настоящему великим, чтобы признавать такие ошибки.

IT>>Думаю, если бы не он, то без проблем кто-то другой.

M>Я бы сказал больше — он слишком себя преувеличил, сказав, что именно он изобрёл null.

Хоару надо сильно потрудиться, чтобы слишком себя преувеличить. Я бы сказал, у него это не получится при всем желании.