Ошибки PascalABC.NET


#1791

А вот с этим и не поспорить.


#1792

Уже неоднократно просили не трогать политику. А проблема - в ней. Во внутренней политике государства.

На Востоке говорят: “Аллах создал женщину, чтобы отвлекать мужчину от праведных трудов”. Но Вы же не женщина! ))) Поэтому давайте с этим заканчивать, у каждого есть дела поинтереснее.


#1793

Я как раз и спрашивал, поскольку я колеблюсь.

В данном случае вернул всё на место.

В своё время когда мы создавали грамматику языка - мы как раз и пользовались тем, что не везде слово в слово будет турбо паскаль. Иногда где можно делать лучше - будем лучше.


#1794

Вот еще одно место. В свойствах

property p: integer read write;

в Дельфи разрешено именнов таком порядке - вначале read, потом write. У нас - как в C# - в произвольном порядке.

Однако при наличии расширенных свойств возникает неоднозначность: write read - read - это легковесное ключевое слово или вызов процедуры read без параметра?

Если порядок read write, то такой проблемы нет.

Что делаем?


#1795

Если есть проблема, как она сейчас разрешена? Если никак - сделать, как проще…


#1796

Это не я сказал. Но согласен :smile:

Read ведь не возвращает значения.

А если ставить точку с запятой?

Public Property p: Int32 Read; Write;

Можно ещё мягко посоветовать ставить () при вызове методов.


#1797

Вы не поняли. Речь идёт про старый синтаксис свойств. К примеру:

property p: integer read GetValue;

Вот в данном случае, конечно, если после read стоит write - можно заставить компилятор понимать - write не возвращает ничего, поэтому он не может быть читающим методом свойства. Но если написать не правильную программу (к примеру новичок, плохо знающий синтаксис - что то перепутал) - есть очень много неоднозначных моментов, когда сложно понять что имелось в виду изначально, и из за этого ошибка обычно не объясняет ничего.

На гитхабе я об этом писал тут, из за авто свойств. Если перед ними не ставить слово auto - скорее всего появится ещё больше непонятных ошибок. Но пример который я привёл там - уже показывает прекрасно случай, когда ошибка непонятная:

type
 t1 = class
   property p: object write write;
 end;

begin end.

Ошибка: Неизвестное имя 'write'
Если разобраться в кишках компилятора - это конечно логично. Но новичку это будет совершенно не понятно.

Тем не менее, ставить ; между read и write (как необязательный, но рекомендуемый через предупреждение элемент синтаксиса), как предложил @Gleb - по моему не плохая идея.


#1798

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

Type t1 = class
  public property p: object write write(value); read read();
end;
Begin
End;

Не просто ведь так в большинстве скобочки при вызове обязательно :wink:

Я вот читал не так давно чей-то код с кучей методов из PABCSystem, написанный в старом стиле. Код хороший, но читать - ад. Невозможно отличить вызов от получения значения свойства и много чего ещё.


#1799

Нет, старая запись оставлена для совместимости, если бы не совместимость - её вообще стоило бы удалить (потому что расширенными свойствами можно сделать всё то же и больше).


#1800

Тогда бы логично рекомендовать ставить ; и после имени типа, а не только между read/write:

type
 t1 = class
   property p: object; read read(); write write();
 end;

Так гораздо читабельнее.

Вообще, кажется, пора уже делать версию PABC.NET 4.0 без всего этого бородатого груза старого синтаксиса (в т.ч. неудачных/неоднозначных решений из Турбо Паскаля и Делфи). Кому надо откомплировать старый код – берите версию 3.x (которая тогда перестанет быть поддерживаемой), для нового кода – только новый, продуманный и оптимизированный синтаксис без неоднозначностей в сложных конструкциях.

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


#1801

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

Поскольку read - имя, то значит предпочтение отдается старому синтаксису, и read ищется среди функций класса. Если не найдена, то сообщение: “не найден метод с именем read, осуществляющий доступ на чтение к свойству p”

То же и для write. Если просто имя, то старые свойства. Иное - расширенные.


#1802

Плюсую к спектатору. Можете сделать отдельную версию, как для .NET 4.0, только со старым синтаксисом для (бессмысленных) попыток запуска старых программ? И оставить её в покое. А новые версии делать уже нормальными, без оглядки на мертворождённые проекты. С точкой с запятой я и правда проглядел. Надо ещё и после типа ставить.


#1803

Насколько я понимаю, сейчас разработчики - это два человека. Тут предлагается вместо одной версии, которую они и так “тянут” чисто на энтузиазме и в свободное от основной работы время, заниматься сразу двумя? Первую поддерживать, поскольку она сделана для обучения и обязана быть совместимой со старыми паскалями: в противном случае от PascalABС.NET разом откажутся большинство школ и иных учебных заведений, которые в силу имеющихся программ и учебников продолжают “возюкаться” в разных там турбопаскалях. А вторую развивать в угоду небольшому сообществу (уж извините), по-прежнему для чего-то желающему заполучить с/С++/С# в паскалевском синтаксисе, да еще сдобренное их хотелками. Учитывая, повторюсь, что разработчиков двое, все эти пожелания, извините за такое упертое мнение, но останутся лишь пожеланиями и не стоит на обсуждения в подобном ключе даже просто время тратить.


#1804

А зачем первую то поддерживать? В том виде, в каком она сейчас пребывает, её более чем достаточно для школы и института(если говорить о тех школах и институтах, которые ещё не дошли до чего - то серьёзнее Турбо Паскаля). А для тех, кто “дошёл”, пригодится новая версия языка. Вот на неё то и нужно сделать упор. Пока всё выглядит так, что PascalABC просто переделали под .NET и реализовали компилятор. Что стало с ABC? Он умер, так как мало чем отличался от TurboPascal, но только при этом ещё и не имел компилятора. Я думаю, никто не желает той же участи для ABC.NET.


#1805
  1. Все, что не поддерживается - умирает. 2) А ничего, что там еще не все ошибки убраны и что-то не сделано?

Да ну? Вы хотите сказать, что нынешний PascalABc.NET - практически тот же PascalABC ? Если Вы упорно не хотите заметить, что он на порядок мощнее и в несколько раз обширнее, то говорить просто не о чем. Ах да, на нем Вам неудобно писать свои нейросети. Ну знаете, можно бомбардировать завод по выпуску автобусов письмами, что ему надо кое-что приделать от “Ламборджини”, только кроме усмешки у заводчан это ничего другого не вызовет. Вам уже говорили - нужно как у Ламборджини - просто берите Ламборджини.


#1806

Согласен, но скажите об этом школам, институтам и авторам учебников, которые до сих пор упорно препарируют труп 25 - и летней давности. Какой смысл надрываться над сохранением совместимости с допотопными версиями в современном языке программирования? Если говорить о государственных учебных заведениях, то для них PascalABC.NET - это просто красивая оболочка TurboPascal для Windows. Там ни о чём другом не слышали и не хотят слышать. Разве стоит хоронить хороший язык таким способом?

Ну мы то с Вами - нормальные люди. Понятно, что для полноценного программирования там есть небольшие(!) ошибки, скорее даже - недоработки. Для школ там всё есть. Даже на головную боль учителям, которым приходится спорить с учениками по поводу внутриблочных переменных :smile:

Нет, я не хочу так сказать, но вот у обоих проектов есть одна и та - же проблема: они держатся за какой - то идеал в лице TP и Delphi. Просто в этот раз разработчики учли неудачный опыт предыдущего проекта и стали добавлять современные возможности, что, естественно, не может не радовать.

Дело здесь совершенно не в этом. Писать нейросети на Паскале даже удобнее, чем на C#, а тем более, C/C++. Паскаль имеет хороший синтаксис. Проблема в том, что существует ряд проблем, делающих приложение неэффективным. Эти проблемы решить не так сложно, в C# их уже давно решили и он уже соревнуется с C++. Удивительно, что всех интересует только синтаксический сахар, который в реальных проектах используется процентов на 5 - 10, а предложения, касающиеся повышения производительности воспринимаются в штыки.


#1807

В языке, на 95% ориентированном на обучение интерес к оптимизации для каких-то “реальных проектов” может быть исключительно академическим. Т.е. опять же, "когда совсем уж нечем больше заняться. А вот синтаксический сахар - самое то.


#1808

Так. Давайте разбираться. Вы считаете, что в школе будут изучать PatternMathing?


#1809

Нет, конечно. Если бы Вы внимательно (и давно) следили за темой, возможно заметили бы, что я постоянно пишу о том, что разработчиков отвлекают на “всякую сишную хрень”, не давая им возможности работать над тем, что кода-то воспринималось, как база языка, предназначенного для обучения.


#1810

Ух… Я уже не знаю, как Вас понимать. Вы хотите современный TurboPascal?