Уже неоднократно просили не трогать политику. А проблема - в ней. Во внутренней политике государства.
На Востоке говорят: “Аллах создал женщину, чтобы отвлекать мужчину от праведных трудов”. Но Вы же не женщина! ))) Поэтому давайте с этим заканчивать, у каждого есть дела поинтереснее.
Я как раз и спрашивал, поскольку я колеблюсь.
В данном случае вернул всё на место.
В своё время когда мы создавали грамматику языка - мы как раз и пользовались тем, что не везде слово в слово будет турбо паскаль. Иногда где можно делать лучше - будем лучше.
Вот еще одно место. В свойствах
property p: integer read write;
в Дельфи разрешено именнов таком порядке - вначале read, потом write. У нас - как в C# - в произвольном порядке.
Однако при наличии расширенных свойств возникает неоднозначность: write read - read - это легковесное ключевое слово или вызов процедуры read без параметра?
Если порядок read write, то такой проблемы нет.
Что делаем?
Если есть проблема, как она сейчас разрешена? Если никак - сделать, как проще…
Это не я сказал. Но согласен 
Read ведь не возвращает значения.
А если ставить точку с запятой?
Public Property p: Int32 Read; Write;
Можно ещё мягко посоветовать ставить () при вызове методов.
Вы не поняли. Речь идёт про старый синтаксис свойств. К примеру:
property p: integer read GetValue;
Вот в данном случае, конечно, если после read стоит write - можно заставить компилятор понимать - write не возвращает ничего, поэтому он не может быть читающим методом свойства. Но если написать не правильную программу (к примеру новичок, плохо знающий синтаксис - что то перепутал) - есть очень много неоднозначных моментов, когда сложно понять что имелось в виду изначально, и из за этого ошибка обычно не объясняет ничего.
На гитхабе я об этом писал тут, из за авто свойств. Если перед ними не ставить слово auto - скорее всего появится ещё больше непонятных ошибок. Но пример который я привёл там - уже показывает прекрасно случай, когда ошибка непонятная:
type t1 = class property p: object write write; end; begin end.
Ошибка: Неизвестное имя 'write'
Если разобраться в кишках компилятора - это конечно логично. Но новичку это будет совершенно не понятно.
Тем не менее, ставить ; между read и write (как необязательный, но рекомендуемый через предупреждение элемент синтаксиса), как предложил @Gleb - по моему не плохая идея.
А если вспомнить скобочки? При вызове метода должны стоять скобочки. Тогда такой код не будет никого смущать:
Type t1 = class
public property p: object write write(value); read read();
end;
Begin
End;
Не просто ведь так в большинстве скобочки при вызове обязательно 
Я вот читал не так давно чей-то код с кучей методов из PABCSystem, написанный в старом стиле. Код хороший, но читать - ад. Невозможно отличить вызов от получения значения свойства и много чего ещё.
Нет, старая запись оставлена для совместимости, если бы не совместимость - её вообще стоило бы удалить (потому что расширенными свойствами можно сделать всё то же и больше).
Тогда бы логично рекомендовать ставить ; и после имени типа, а не только между read/write:
type
t1 = class
property p: object; read read(); write write();
end;
Так гораздо читабельнее.
Вообще, кажется, пора уже делать версию PABC.NET 4.0 без всего этого бородатого груза старого синтаксиса (в т.ч. неудачных/неоднозначных решений из Турбо Паскаля и Делфи). Кому надо откомплировать старый код – берите версию 3.x (которая тогда перестанет быть поддерживаемой), для нового кода – только новый, продуманный и оптимизированный синтаксис без неоднозначностей в сложных конструкциях.
Фанатичная поддержка совместимости с неудачными решениями в учебно-экспериментальном продукте не имеет никакого практического смысла, а только тормозит его развитие и усложняет поддержку.
Ну, предположим. Но не говорите, что начинающие будут писать этот код и не ведать что творят. Надо лишь улучшить сообщения об ошибках.
Поскольку read - имя, то значит предпочтение отдается старому синтаксису, и read ищется среди функций класса. Если не найдена, то сообщение: “не найден метод с именем read, осуществляющий доступ на чтение к свойству p”
То же и для write. Если просто имя, то старые свойства. Иное - расширенные.
Плюсую к спектатору. Можете сделать отдельную версию, как для .NET 4.0, только со старым синтаксисом для (бессмысленных) попыток запуска старых программ? И оставить её в покое. А новые версии делать уже нормальными, без оглядки на мертворождённые проекты. С точкой с запятой я и правда проглядел. Надо ещё и после типа ставить.
Насколько я понимаю, сейчас разработчики - это два человека. Тут предлагается вместо одной версии, которую они и так “тянут” чисто на энтузиазме и в свободное от основной работы время, заниматься сразу двумя? Первую поддерживать, поскольку она сделана для обучения и обязана быть совместимой со старыми паскалями: в противном случае от PascalABС.NET разом откажутся большинство школ и иных учебных заведений, которые в силу имеющихся программ и учебников продолжают “возюкаться” в разных там турбопаскалях. А вторую развивать в угоду небольшому сообществу (уж извините), по-прежнему для чего-то желающему заполучить с/С++/С# в паскалевском синтаксисе, да еще сдобренное их хотелками. Учитывая, повторюсь, что разработчиков двое, все эти пожелания, извините за такое упертое мнение, но останутся лишь пожеланиями и не стоит на обсуждения в подобном ключе даже просто время тратить.
А зачем первую то поддерживать? В том виде, в каком она сейчас пребывает, её более чем достаточно для школы и института(если говорить о тех школах и институтах, которые ещё не дошли до чего - то серьёзнее Турбо Паскаля). А для тех, кто “дошёл”, пригодится новая версия языка. Вот на неё то и нужно сделать упор. Пока всё выглядит так, что PascalABC просто переделали под .NET и реализовали компилятор. Что стало с ABC? Он умер, так как мало чем отличался от TurboPascal, но только при этом ещё и не имел компилятора. Я думаю, никто не желает той же участи для ABC.NET.
Да ну? Вы хотите сказать, что нынешний PascalABc.NET - практически тот же PascalABC ? Если Вы упорно не хотите заметить, что он на порядок мощнее и в несколько раз обширнее, то говорить просто не о чем. Ах да, на нем Вам неудобно писать свои нейросети. Ну знаете, можно бомбардировать завод по выпуску автобусов письмами, что ему надо кое-что приделать от “Ламборджини”, только кроме усмешки у заводчан это ничего другого не вызовет. Вам уже говорили - нужно как у Ламборджини - просто берите Ламборджини.
Согласен, но скажите об этом школам, институтам и авторам учебников, которые до сих пор упорно препарируют труп 25 - и летней давности. Какой смысл надрываться над сохранением совместимости с допотопными версиями в современном языке программирования? Если говорить о государственных учебных заведениях, то для них PascalABC.NET - это просто красивая оболочка TurboPascal для Windows. Там ни о чём другом не слышали и не хотят слышать. Разве стоит хоронить хороший язык таким способом?
Ну мы то с Вами - нормальные люди. Понятно, что для полноценного программирования там есть небольшие(!) ошибки, скорее даже - недоработки. Для школ там всё есть. Даже на головную боль учителям, которым приходится спорить с учениками по поводу внутриблочных переменных
Нет, я не хочу так сказать, но вот у обоих проектов есть одна и та - же проблема: они держатся за какой - то идеал в лице TP и Delphi. Просто в этот раз разработчики учли неудачный опыт предыдущего проекта и стали добавлять современные возможности, что, естественно, не может не радовать.
Дело здесь совершенно не в этом. Писать нейросети на Паскале даже удобнее, чем на C#, а тем более, C/C++. Паскаль имеет хороший синтаксис. Проблема в том, что существует ряд проблем, делающих приложение неэффективным. Эти проблемы решить не так сложно, в C# их уже давно решили и он уже соревнуется с C++. Удивительно, что всех интересует только синтаксический сахар, который в реальных проектах используется процентов на 5 - 10, а предложения, касающиеся повышения производительности воспринимаются в штыки.
В языке, на 95% ориентированном на обучение интерес к оптимизации для каких-то “реальных проектов” может быть исключительно академическим. Т.е. опять же, "когда совсем уж нечем больше заняться. А вот синтаксический сахар - самое то.
Так. Давайте разбираться. Вы считаете, что в школе будут изучать PatternMathing?
Нет, конечно. Если бы Вы внимательно (и давно) следили за темой, возможно заметили бы, что я постоянно пишу о том, что разработчиков отвлекают на “всякую сишную хрень”, не давая им возможности работать над тем, что кода-то воспринималось, как база языка, предназначенного для обучения.
Ух… Я уже не знаю, как Вас понимать. Вы хотите современный TurboPascal?
А по моему - будут, но только с нормальным учителем (которому не 95 лет, и который готов принять что то новое). match не сложнее обычного case, ни на сколько.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021