элементарно спроси других программистов (не себя), на других языках, которые не знают 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.
Формулирование типов через универсальные свойства (уникальные кратчайшие пути) помогает факторизовать вычисления - декомпозировать сложные задачи на простые и описать их с помощью типов.
Я дико извиняюсь, но можно как-то разжевать для обычных смертных, что значит
формулирование типов через уникальные свойства ?
как проявляется помощь в факторизации вычислений ?
что за фактор ?
о каких сложных задачах идет речь? те что в jira или те что доказательство P = NP ?
что значить описать с помощью типов? пример бы глянуть, о чем речь.
Я смутно догадываюсь о чем речь, но смутно
Про сумму типов
Вот не плохо бы разжевать, есть другое более наглядное объяснение в рамках Scala - это Either, можно сказать Either это такой enum
enum Either[A,B] {
Left(A),
Right(B)
}
// или Scala2
sealed trait Either[A,B]
case class Left[A,B](a:A) extends Either
case class Right[A,B](b:B) extends Either
Что в конечном итоге Left/Right - это тип (.class) внутри JVM и к некой переменной a типа Either, применима операция instanceOf, а match - это сахар над instanceOf.
Что важно, что переменная a не может одновременно содержать Left и Right. Но, при этом сохраняется информация о типе, что Either переменную можно определить Left/Right - и извлечь ее и с ней работать, зная что она Left.
Тут важно еще пояснить, зачем это знать, просто в Scala - world, точнее в части ее библиотек не принято кидать Exception, и большинство функций используют такую семантику:
// было
def some_fun( arg: A ): R
// стало
def some_fun( arg: A ): Either[Error,R]
Что обычно в Left хранятся ошибки и это знание важно, а вот не просто, так нам захотелось ввести Left/Right
Но к сожалению, такого рода утверждения не будут считаться полными и однозначными определениями. В нашем случае, мы должны ещё гарантировать, что нет никаких , и прочих, кто ещё связан отображениями с .
Почему они не могут считаться полными, и что нам дает отсутствие или наличие еще An... ?
Но с другой стороны, например, если для есть отображение в , то вполне можно исключить из определения типа
почему мы можем исключить ?? на основании чего ? а если при приобразовании у нас потеря точности ?
Зачастую такие отображения бывает удобно отобразить на диаграмме в виде ориентированного графа
Это про все виды отображений или про некоторые виды, отображений? если про некоторые, тогда стрелки в обратную сторону в случае сюръекции не возможны (или возможны) ?
Я с этим не спорю, обрати внимание
Нет, не стеб
вот грамматика 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)
оба содержат по структуре в которых имена полей разные, но их кол-во и типы полей совпадают, а так же их последовательность
пример
Компилятор С как знаем обращается к полям не по имени, а по смещению
то тогда верно утверждать что это один и тот же тип ?
Я дико извиняюсь, но можно как-то разжевать для обычных смертных, что значит
формулирование типов через уникальные свойства ?
как проявляется помощь в факторизации вычислений ?
что за фактор ?
о каких сложных задачах идет речь? те что в jira или те что доказательство P = NP ?
что значить описать с помощью типов? пример бы глянуть, о чем речь.
Я смутно догадываюсь о чем речь, но смутно
Про сумму типов
Вот не плохо бы разжевать, есть другое более наглядное объяснение в рамках Scala - это Either, можно сказать Either это такой enum
и дать например ссылку сюда https://github.com/anton-k/ru-neophyte-guide-to-scala/blob/master/src/p07-either.md
Что в конечном итоге Left/Right - это тип (.class) внутри JVM и к некой переменной a типа Either, применима операция instanceOf, а match - это сахар над instanceOf.
Что важно, что переменная a не может одновременно содержать Left и Right. Но, при этом сохраняется информация о типе, что Either переменную можно определить Left/Right - и извлечь ее и с ней работать, зная что она Left.
Тут важно еще пояснить, зачем это знать, просто в Scala - world, точнее в части ее библиотек не принято кидать Exception, и большинство функций используют такую семантику:
Что обычно в Left хранятся ошибки и это знание важно, а вот не просто, так нам захотелось ввести Left/Right
Извините, но вот
Почему они не могут считаться полными, и что нам дает отсутствие или наличие еще An... ?
почему мы можем исключить ?? на основании чего ? а если при приобразовании у нас потеря точности ?
Это про все виды отображений или про некоторые виды, отображений? если про некоторые, тогда стрелки в обратную сторону в случае сюръекции не возможны (или возможны) ?