Действительно - есть синтаксические ограничения - в скобках в качестве параметров могут находиться только имена. Конструкции вида real -> real - нет
Пожалуйста, исправьте это, хотелось бы писать красивые “функции-однострочники”. Это же и есть параметр: лямбда или по-другому функция.
Не получим ли мы при таком разрешении допущение многократно вкладывать лямбды и, более того, получать “лямбда-рекурсии” ? И не потребуется ли при этом сложный аппарат для реализации всего этого в компиляторе? Ведь PascalABC.Net все же полноценный компилятор, а не интерпретирующая среда.
В этом и весь сок, что мы можем в параметрах указывать функции, а не только числа и строки, лямбды очень крутую функцию выполняют, без них было бы трудно жить, раз уж можно в параметрах функции при обычном объявлении указывать лямбду, только почему нельзя в самой лямбде указывать как параметр лямбду, ведь лямбда - это та же функция, только в ее короткой записи. Я уже приводил пример кода, который показывает, что писать лямбды через лямбды будет удобно и понятно, а писать через type - долго и нерационально, если не получается добавить такое разрешение, тем самым упростив код для пользователей, тогда вообще зачем весь этот .NET в Pascal-е, писали бы в старом и все, раз уж делаете мощный и качественный паскаль, то нужно делать рационально, грамотно и удобно.
Нет, не можем. Возникают семантические сложности
Появилось:
(var a, var b) := (1,2);
(var S, var P) := CalcSP(a,b);
Скачайте новую версию
Значения могут быть разных типов, да?
Ну конечно - любых.
(var a, var b) := t;
это синтаксический сахар для
var a := t[0];
var b := t[1];
В продолжение темы о совместимости с предыдущими версиями. Даже с ранними PascalABC.NET. Она уже частично утрачена. Сегодня по просьбе одного ученика школы написал простенькую программку для вывод кодов русских букв. Да, я помню, что с некоторых пор надо писать не Ord(),а OrdANSI() при желании получить десятичные коды ASCII, а не UNICODE. Но… это приводит к несовместимости с другими версиями. При переносе программы в иную среду/версию Pascal, приходится отслеживать все Ord и при необходимости делать замены. Более того, при публикации программы где-либо, нужно писать довольно сомнительного свойства замечание: "Программа будет корректно работать только в “свежих” версиях PascalABC.NET. При неверной работе замените все вхождения OrdANSI( на Ord(" Нехорошо это… очень нехорошо. Большая ложка дегтя. Опция совместимости нужна, как глоток воды.
Вот так работает:
begin var a,b,c:integer; (a,b,c):=(1,3,2); Println(a,b,c); end.
А так - синтаксическая ошибка:
begin (var a, var b, var c):=(1,2,3); Println(a,b,c); end.
Ну нельзя же всё время держаться за старый убогий Паскаль и сохранять совместимость с неюникодовскими кодировками.
Не пойму: Вы то соглашаетесь, что совместимость опционально должна быть, то высказываетесь, что нельзя на старые версии озираться. Почему бы не разделить опционально синтаксис на “старый” (в целях совместимости и на переходный период) и “новый”? Стимул перехода очевиден будет: в “старой версии” зарубаются все вкусности новой. версии. Хочешь воспользоваться новинкой - изволь писать по-новому!
Школы только-только на ABC.NET стали переходить постепенно - а Вы им несовместимость с каноническими свойствами языка. Ord/Chr еще у Вирта прописаны, во всех учебниках они работают на кодах ASCII - и на тебе!
Мир со времён Вирта сильно изменился.
Вы неправы. Это не синтаксис. Это - библиотечные функции.
Ord/Chr и у нас сейчас работают на кодах ASCII: https://ru.wikipedia.org/wiki/ASCII Дело в том, что ASCII - это первые 128 символов любой кодовой таблицы.
Если Вы работаете с русскими буквами и имеете в виду однобайтовые кодировки, которые были реализованы в старом Turbo Pascal образца 1980 г., то таких кодировок - распространенных - по крайней мере три.
Во всех учебниках, которые Вы, очевидно, имеете в виду, описан Ord/Chr для Турбо-Паскаля когда еще не знали Юникод. Равняться на учебники по программированию с информацией 80-х годов, равно как и равняться на учебники 70х годов не хочется.
Ord - это код символа - так у Вирта. Так вот, поскольку символ у нас 16-битный, это ровно его код, так символ хранится у нас в памяти.
Ord в книгах по Турбо-Паскалю - это макулатура.
Исправили. Версия на сайте.
Я не имел в виду именно Ord/Chr. Это продолжение все той же темы с требованием “for var i:=” и теми, что могут появиться позднее (уже было тут упоминание про требование Result:= в функциях). Если синтаксис разделить опционально, то можно уж заодно и чисто синтаксически научить компилятор понимать, что под Ord() при старом синтаксисе следует иметь в виду OrdANSI().
Попытаюсь объяснить проблему. Школьнику задали задачу напечатать табличку кодов строчных русских букв. Работают с Pascal ABC, но именно этого не было уточнено, а я посчитал, что речь об ABC.NET. Понятно, что программа выдала четырехразрядные коды Unicode. Учитель посмотрел - и забраковал. Коды, сказал, трехзначные должны быть! Запустили программу на их системе - трехзначные, конечно. И не зачел работу, потому что были приложены коды “не те”. Был бы я на месте школьника - мы бы подискутировали. А что ребенок может сделать - идти со своими “знаниями” против своего школьного учителя? Я подправил на вызов OrdANSI(), получил коды трехразрядные. Но теперь “там” программа не идет.
И знаете - я не видел ни одного школьного учебника, где Ord() работает с кодами Unicode. Они переиздаются, а кодировка все еще PC-1251.
Отлично! Наконец-то есть в какой-то степени аналог сишного a=b=c=0 Если бы еще и var писать один раз… !!! )))))))
Здравствуйте. А PascalABC.NET умеет работать с XML, по типу как Делфи? Если да, то какой модуль подключать, есть ли справка или работа с компонентом такая же как и Делфи?
Вот завалялся пример:
{$reference System.Xml.dll}
uses System.Xml;
begin
var settings := new XmlWriterSettings();
settings.Indent := true;
settings.NewLineOnAttributes := true;
settings.OmitXmlDeclaration := true;
var xmlw := XmlWriter.Create('out.xml',settings);
xmlw.WriteStartElement('books');
xmlw.WriteStartElement('book');
xmlw.WriteAttributeString('genre','IT');
xmlw.WriteElementString('title','C# and OOP');
xmlw.WriteElementString('author','Vasja Pupkin');
xmlw.WriteElementString('year','2006');
xmlw.WriteEndElement();
xmlw.WriteEndElement();
xmlw.Close();
var xmlr := XmlReader.Create('out.xml');
xmlr.Read();
xmlr.ReadStartElement('books');
xmlr.ReadStartElement('book');
writeln('book:');
xmlr.ReadStartElement('title');
writeln('title: ',xmlr.ReadString());
xmlr.ReadEndElement();
xmlr.ReadStartElement('author');
writeln('author: ',xmlr.ReadString());
xmlr.ReadEndElement();
xmlr.ReadStartElement('year');
writeln('year: ',xmlr.ReadContentAsInt());
xmlr.ReadEndElement();//year
xmlr.ReadEndElement();//book
xmlr.ReadEndElement();//books
xmlr.Close();
end.
Мда…
Ну, должны появляться. Тут как раз обратная зависимость - школьные учебники описывают возможности реальных систем программирования и языков. Может, и школьные учителя тогда поменяются