кажется посыл не понял, а он был именно в томчто в нем есть и Статическая типизация (в Compile time) И Динамическая типизация (Run time - Variant и позднее связывание)
И вот определить, что тот или иной код является только со статической типизацией, без чтения исходников - я не знаю
не делает язык "не строгим".
спорное утверждение - о понятиях, и они разные у нас
Ты будешь удивлен, но ты можешь сам сделать такой тип на основе record
Меня вообще это не интересует, меня интересует, как убрать из сторонних исходников Variant и/или убедиться что подобной динамики по типам в run time в коде нет, при том что бы мне это компилятор сказал или linter, а не читать исходники самому
элементарно спроси других программистов (не себя), на других языках, которые не знают delphi, какой из следующих примеров кода на delphi является валидным
if expr then succ() else fail();
if expr then succ();
if expr then succ() else;
if expr then else fail();
if expr then ;
а вот все эти примеры являются валидными (Delphi 7), то что ты это знаешь, не вопрос, где о этом написано официально ?
Ты бы ещё взял турбо Паскаль и пытался без изменения кода запустить его в Delphi 12 (2024 года)
В моем случае, реального проекта с 500 000+ строк delphi 7 и delphi 2010 оно совместимо и используется, без переписывания, есть части на delphi 7 и delphi 2010
те Delphi 2010 в рамках своего языка понимает Delphi 7
Была бы возможность не брать delphi, вообще бы не подходил бы к нему
Ой блин... снова Паскаль..., т.к. я с Delphi в последнее время вожусь, то вот порция критики самого языка, в контексте обучения
Синтаксис... это вот прям проблема на равном месте, например Delphi его формальный синтаксис не описан производителем (Embercadero), да существует стороннее описание, но они толком не особо работают, вот... попытался описать https://github.com/gochaorg/delphi-parser/blob/main/src/main/resources/Delphi.g4, я этот парсер, чтоб он взлетел и на Delphi 7 и на Delphi 2010 больше месяца убил, отлавливая глюки у себя
Вот, а как не имея строгой грамматики (тот же BNF или Antlr) и семантики языковой будем объяснять за программирование ? по мне это уже оксюморон.
На счет строгой типизации... ну да... там вообще есть variant такой тип, он же any в других, аргумент за типизацию (применительно к Delphi) не работает.
Вообще мне кажется это, overhead начинать с типизированного языка, хотя я сам люблю Rust, конечно если задача стоит отбить желание изучать, тогда да...
Если уж и говорить за обучение, то языку программирования должно прилагаться
заинтересованный ученик
заинтересованный преподаватель (который сам в состоянии написать свой язык)
интересная обучающая задача
линтер, который не пропустит код с ошибками
А что касается типизации и прочего... это уже отдельная история про Haskell / Rust / Agda / etc .... молодому человеку (со сколки лет там обучают) по мимо нашего программирования нужно еще кучу чего учить, а еще отдыхать и с друзьями общаться, и более сложные темы будет время в институте изучать
Извините, но я один вижу что вы написали интерпретатор? Глупый вопрос, а зачем когда на той же jvm есть jsr223, который scripting, ну или на худой конец сама jvm и есть интерпретатор/транслятор байткода. Зачем писать управление стеком и осуществлять интерпретирование? Я молчу про escape analyse, inline... Вывод типов в ast...
Или тут речь про dsl который любят в scala называть алгебрами?
Из этих трёх пунктов резюмирую просто, для начала "продуктивного спора" необходимо установить предмет разногласий , ну или иначе по классике Аристотель - все споры из за терминов
P.s. покажите мне тот спор, где выясняют термины, то мне видеться будет уже не спор, а дискуссия
Я в своем pet-proj делал для себя компилятор, так чтоб всегда вычислялись типы конечного выражения и в рамках вычисления проводил проверку на совместимость типов
в качестве совместимости я определил одну бинарную функцию isAssignable( left: Type, right: Type ) : bool, в Scalа она выглядила так leftSomeType.isAssignable( rightType )
при помощи нее строил граф отношений (частично упорядоченное множество на базе упомянутой функции) в рамках области видимости импортируемых типов
isAssignable включала как и отношения наследования, так и не явных преобразований из Int в Long
Правильно ли я понимаю что речь именно о этом ? что это и есть случай под-типизации ?
Я же правильно понимаю, что множественное наследование - это та самая приславутая проблема алмаза, и что она успешно решается в рамках С3 линириализации https://ru.wikipedia.org/wiki/C3-линеаризация ?
Я к той же Scala, где в Scala 2 до умножения типов (A & B & C) использовали подход class SomeClass extends A with B with C ?
Я вот про ту самую цепь A->B->C, в целом понятно, что чем короче путь - тем "лучше"
Просто у меня может не правильное понимание, допустим есть такие функции
def a( value:Long ):Int = value % 10
def b( value:Int ):String = value.toString
val result = b(a(10))
def c( value:Long ):String = value.toString
Формально с - это короткий путь из Long в String, но его результат очевидно не совпадает с композицией b * a
Я тут сознательно нарушаю, я так понимаю правильнее всего говорить не о буквальной трактовке типов, а о таких типах которые при вычислении значений не дают отличий ?
В теории хороший компилятор пометил бы результат композиции b * a - как некий тип String* (со звездочкой, а-ля зависимый тип) и данный тип не был эквивалентен типу из результата функции c.
вот с чего в друг?
что в твоем понимании синтаксические ошибки ? а что другого не синтаксические ошибки компилятора ?
кажется посыл не понял,
а он был именно в томчто в нем есть и Статическая типизация (в Compile time) И Динамическая типизация (Run time - Variant и позднее связывание)
И вот определить, что тот или иной код является только со статической типизацией, без чтения исходников - я не знаю
спорное утверждение - о понятиях, и они разные у нас
Меня вообще это не интересует, меня интересует, как убрать из сторонних исходников Variant и/или убедиться что подобной динамики по типам в run time в коде нет, при том что бы мне это компилятор сказал или linter, а не читать исходники самому
Я с этим не спорю, обрати внимание
Нет, не стеб
вот грамматика if в delhi вообще не очевидна
элементарно спроси других программистов (не себя), на других языках, которые не знают delphi, какой из следующих примеров кода на delphi является валидным
if expr then succ() else fail();
if expr then succ();
if expr then succ() else;
if expr then else fail();
if expr then ;
а вот все эти примеры являются валидными (Delphi 7), то что ты это знаешь, не вопрос, где о этом написано официально ?
Компилятор пропускает много ошибок
https://docwiki.embarcadero.com/RADStudio/Alexandria/en/List_of_publicly_reported_bugs_fixed_in_11.2
https://docwiki.embarcadero.com/RADStudio/Sydney/en/List_of_publicly_reported_bugs_fixed_in_10.4.1
А что бы сказать какого рода эта ошибка, синтаксическая или runtime или программиста или еще что... необходима спецификация языка, которой нет
PS Язык программирования - тот же софт, те ми же глюками, а ТехЗадания нет на него, спецификации нет
Кто сказал, что код пишется в здравом уме ? особенно когда речь за освоение школьником, который тонкостей языка не знает
В моем случае, реального проекта с 500 000+ строк delphi 7 и delphi 2010 оно совместимо и используется, без переписывания, есть части на delphi 7 и delphi 2010
те Delphi 2010 в рамках своего языка понимает Delphi 7
Была бы возможность не брать delphi, вообще бы не подходил бы к нему
Можешь кинуть ссылку на формальное описание языка ? вот тут https://docwiki.embarcadero.com/RADStudio/Athens/en/Delphi_Language_Reference
его нет
Вот где почитать официальную спецификацию языка ? по аналогии https://docs.oracle.com/javase/specs/
такой официальной документации не нашел
Ой блин... снова Паскаль..., т.к. я с Delphi в последнее время вожусь, то вот порция критики самого языка, в контексте обучения
Синтаксис... это вот прям проблема на равном месте, например Delphi его формальный синтаксис не описан производителем (Embercadero), да существует стороннее описание, но они толком не особо работают, вот... попытался описать https://github.com/gochaorg/delphi-parser/blob/main/src/main/resources/Delphi.g4, я этот парсер, чтоб он взлетел и на Delphi 7 и на Delphi 2010 больше месяца убил, отлавливая глюки у себя
Вот, а как не имея строгой грамматики (тот же BNF или Antlr) и семантики языковой будем объяснять за программирование ? по мне это уже оксюморон.
На счет строгой типизации... ну да... там вообще есть variant такой тип, он же any в других, аргумент за типизацию (применительно к Delphi) не работает.
Вообще мне кажется это, overhead начинать с типизированного языка, хотя я сам люблю Rust, конечно если задача стоит отбить желание изучать, тогда да...
Если уж и говорить за обучение, то языку программирования должно прилагаться
заинтересованный ученик
заинтересованный преподаватель (который сам в состоянии написать свой язык)
интересная обучающая задача
линтер, который не пропустит код с ошибками
А что касается типизации и прочего... это уже отдельная история про Haskell / Rust / Agda / etc .... молодому человеку (со сколки лет там обучают) по мимо нашего программирования нужно еще кучу чего учить, а еще отдыхать и с друзьями общаться, и более сложные темы будет время в институте изучать
Сомнительная статья
Ну вот как бы не следует что наличие сообщений обязательно приводит к поддержке транзакций
надежность понятие по ширше чем устойчивы к сбоям
например доступность - сегодня одно rest api, а завтра другое и как бы все ломается
данные и система в целом имеет свойства накапливать данные и ошибки
Так что сколько там не рассчитывай, все равно пальцем в небо, а потому и надо мониторить
Извините, но я один вижу что вы написали интерпретатор? Глупый вопрос, а зачем когда на той же jvm есть jsr223, который scripting, ну или на худой конец сама jvm и есть интерпретатор/транслятор байткода. Зачем писать управление стеком и осуществлять интерпретирование? Я молчу про escape analyse, inline... Вывод типов в ast...
Или тут речь про dsl который любят в scala называть алгебрами?
А ещё... Все примеры опираются на dyn trait, хотя лучше бы не опирались, код стал чище и понятнее
Из этих трёх пунктов резюмирую просто, для начала "продуктивного спора" необходимо установить предмет разногласий , ну или иначе по классике Аристотель - все споры из за терминов
P.s. покажите мне тот спор, где выясняют термины, то мне видеться будет уже не спор, а дискуссия
Хорошее ТЗ в таком случае = Хорошая программа
Я в своем pet-proj делал для себя компилятор, так чтоб всегда вычислялись типы конечного выражения и в рамках вычисления проводил проверку на совместимость типов
в качестве совместимости я определил одну бинарную функцию isAssignable( left: Type, right: Type ) : bool, в Scalа она выглядила так leftSomeType.isAssignable( rightType )
при помощи нее строил граф отношений (частично упорядоченное множество на базе упомянутой функции) в рамках области видимости импортируемых типов
isAssignable включала как и отношения наследования, так и не явных преобразований из Int в Long
Правильно ли я понимаю что речь именно о этом ? что это и есть случай под-типизации ?
Спасибо за комментарий
Я же правильно понимаю, что множественное наследование - это та самая приславутая проблема алмаза, и что она успешно решается в рамках С3 линириализации https://ru.wikipedia.org/wiki/C3-линеаризация ?
Я к той же Scala, где в Scala 2 до умножения типов (A & B & C) использовали подход class SomeClass extends A with B with C ?
Другой вопрос, всякий раз когда я смотрю на диаграмму суммы типов
всегда мучает вопрос, а при чем тут D ?
ну хорошо, есть у нас такие пути
1) A -- ia -> A+B -- u --> D
2) A -- f --> D
вроде как короче, A+B получается тогда - как пятое колесо телеге, может сразу из A в D, и выкинуть из проекта A+B ?
A+B - это вроде важный концепт и выкидывать его не хочется
Что хотел сказать автор этим ? или я читаю не глазами, а жо---ой
Формально я понимаю, что запись в языке `
def f( a: A | B )` - короче, чем воротить свои велосипеды с sealed + case classДругое так же понимаю, что
def f( a: A & A )формально этоdef f( a: A )По простой причине некий тип A обладает теми же методами, что и A
А вот тип A & B - по сути обладает методами и свойствами обоих типов одновременно, интересно другое
допустим A имеет метод
def f( a : Int ) = a % 10,а тип B имеет такой же метод, но с другой реализацией
def f( a: Int ) = a % 16тогда вызов
a.f( 13 )- какая в итоге будет вызвана реализация - это на откуп компилятору отдается.Если сумму типов рассматривать как множественное наследование, тогда как-то легче в голове уложить.
Я вот про ту самую цепь A->B->C, в целом понятно, что чем короче путь - тем "лучше"
Просто у меня может не правильное понимание, допустим есть такие функции
Формально с - это короткий путь из Long в String, но его результат очевидно не совпадает с композицией b * a
Я тут сознательно нарушаю, я так понимаю правильнее всего говорить не о буквальной трактовке типов, а о таких типах которые при вычислении значений не дают отличий ?
В теории хороший компилятор пометил бы результат композиции b * a - как некий тип String* (со звездочкой, а-ля зависимый тип) и данный тип не был эквивалентен типу из результата функции c.
Или рассуждения не верны ?
Я же правильно понимаю, что если допустим имеем 2 исходника source-1 source-2 (допустим C)
оба содержат по структуре в которых имена полей разные, но их кол-во и типы полей совпадают, а так же их последовательность
пример
Компилятор С как знаем обращается к полям не по имени, а по смещению
то тогда верно утверждать что это один и тот же тип ?