FDS>>Информация о типе, хранящаяся в голове программиста — это абстракция. Т.е. у компилятора, получается, системы типов технологически нет, соответственно и функции она никакой в языке не играет.
S>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
S>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
Это я должен был пояснить.
Языком без системы типов можно называть язык с одним типом. Например, bash.
Здравствуйте, FDSC, Вы писали:
FDS>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>Это — чушь
FDS>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
foo() { foo(); }
память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>Рекурсивный вызов не может быть переходом по синтаксическому дереву, так как это уже переход по графу потока управления, который имеет циклы и деревом вообще не является.
Здравствуйте, Temoto, Вы писали:
S>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
T>Это я должен был пояснить.
T>Языком без системы типов можно называть язык с одним типом. Например, bash.
Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
T>>Понятно, всё делает метод +. Всё ещё непонятно, как метод (+) :: Object -> Object -> Object имея на руках только два неименованных куска битов узнает, что к ним надо применить численное сложение, а не конкатенацию строк.
FDS>Метод "+" ничего не узнаёт, он просто складывает два целых числа, так как в числах он именно такой. FDS>В строках метод "+" определён другим способом — он уже выполняет конкатенацию.
FDS>Указатель на конкретный метод "+" каждый объект получает от программиста в свой словарь методов — что программист дал, то и есть, т.е. сам метод считает, что он применим к нужному куску битов без какой-либо проверки.
То есть вы имели в виду случай, когда после создания каждого объекта программист должен сам навесить ему операторов. Теперь всё ясно, спасибо.
S>>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
T>>Это я должен был пояснить.
T>>Языком без системы типов можно называть язык с одним типом. Например, bash.
S>Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
Потому что это неконструктивно, как считать всякую программу информацией.
Здравствуйте, samius, Вы писали: S>язык без системы типов
А вот фиг его знает. Можно подразумевать под этим язык, где значения переменных интерпретируются по-разному: как строки или как числа или как еще что в зависимости от текущей операции.
А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
>Io
Вот и бедному io досталось. А чем он хуже любого другого динамического языка?
Здравствуйте, Temoto, Вы писали:
T>>>Языком без системы типов можно называть язык с одним типом. Например, bash.
S>>Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
T>Потому что это неконструктивно, как считать всякую программу информацией.
Здравствуйте, samius, Вы писали:
FDS>>Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
S>Этот пример не опровергает моего утверждения, более того он не имеет отношения к вопросу.
Этот пример как раз имеет отношение к вопросу, так как он показывает, что любое определение процедуры объявляет информацию о хранении аргументов этой процедуры.
S>Вот пример обратного
S>[scheme] S>(define (cons x y) S> (define (dispatch m) S> (cond ((= m 0) x) S> ((= m 1) y) S> (else (error "Argument not 0 or 1 -- CONS" m)))) S> dispatch)
S>(define (car z) (z 0))
S>(define (cdr z) (z 1)) S>[/scheme]
Где именно здесь пример обратного? Во всех объявлениях функций интерпретатор получает информацию о том, сколько в них аргументов — т.е. определяет, по сути, структуру, в которой передаются аргументы, и, соответственно, место под эту структуру. А уж что в ней дальше содержится — нам без разницы. Важно, что определяя функцию мы указали о способе хранения аргумента. Например, для функции cons мы указали о том, что её аргумент состоит из пары значений (если считать все функции только с одним аргументом) или, что то же самое, что при вызове этой функции нам необходимо запомнить в стеке два аргумента. Это и есть так информация, которая предоставляется компилятору в описании функции — и она есть.
А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
S>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
Здравствуйте, Mr.Cat, Вы писали: MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Дополню. В языке с динамической типизацией скорее всего не будет способа записи этих самых высказываний — так что программа вроде как и не является доказательством чего-либо.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, samius, Вы писали: S>>язык без системы типов MC>А вот фиг его знает. Можно подразумевать под этим язык, где значения переменных интерпретируются по-разному: как строки или как числа или как еще что в зависимости от текущей операции. MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Нет статической, значит есть динамическая. А подразумевать-то конечно можно.
>>Io MC>Вот и бедному io досталось. А чем он хуже любого другого динамического языка?
Его имя короче )))
Здравствуйте, Temoto, Вы писали:
T>То есть вы имели в виду случай, когда после создания каждого объекта программист должен сам навесить ему операторов. Теперь всё ясно, спасибо.
Ну да, потому что иначе придётся объявлять типы, а их у нас нет
MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>>Это — чушь
FDS>>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
S>foo() { foo(); } S>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
1. Частный случай
2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST
3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
S>>Этот пример не опровергает моего утверждения, более того он не имеет отношения к вопросу.
FDS>Этот пример как раз имеет отношение к вопросу, так как он показывает, что любое определение процедуры объявляет информацию о хранении аргументов этой процедуры.
О передаче аргументов — без базара. О зранении их вне вызова — нет.
S>>Вот пример обратного
S>>[scheme] S>>(define (cons x y) S>> (define (dispatch m) S>> (cond ((= m 0) x) S>> ((= m 1) y) S>> (else (error "Argument not 0 or 1 -- CONS" m)))) S>> dispatch)
S>>(define (car z) (z 0))
S>>(define (cdr z) (z 1)) S>>[/scheme]
FDS>Где именно здесь пример обратного? Во всех объявлениях функций интерпретатор получает информацию о том, сколько в них аргументов — т.е. определяет, по сути, структуру, в которой передаются аргументы, и, соответственно, место под эту структуру. А уж что в ней дальше содержится — нам без разницы. Важно, что определяя функцию мы указали о способе хранения аргумента. Например, для функции cons мы указали о том, что её аргумент состоит из пары значений (если считать все функции только с одним аргументом) или, что то же самое, что при вызове этой функции нам необходимо запомнить в стеке два аргумента. Это и есть так информация, которая предоставляется компилятору в описании функции — и она есть.
Продолжаешь обсасывать передачу аргументов? Дальше сам с собой!
FDS>А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
Вот именно другого вопроса и касалось мое утверждение
S>>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
FDS>И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
Теперь поделись секретом, как ты из моего утверждения сделал такой далекоидущий вывод? Нет, ну интересно просто.
Здравствуйте, Temoto, Вы писали:
MC>>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
T>Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Если я правильно понял, он имеет в виду, что мы высказываем, что int a, b, c, а затем даём высказывания с = 1; b = c + 1; a = b + 1.
Таким образом мы получаем своего рода "доказательство": c действительно является int, т.к. равна значению типа int, b действительно является int, т.к. равна значению типа int, получаемому как результат операции +: int * int -> int, и т.п.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>>>Это — чушь
FDS>>>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
S>>foo() { foo(); } S>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>1. Частный случай
Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
FDS>2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST
Концевая рекурсия — еще целый класс примеров, не требующих "памяти на рекурсию".
FDS>3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор.
При каждом не должен.
У меня вообще все время навязчивое впечатление, что все твои изречения определены в твоей голове на каких-то частных случаях типа язык без типа или неверифицирующий компилятор... Но выглядят-то они так, как будто они справедливы на все случаи жизни.
Вот поясни, откуда ты вообще взял что обсуждаемый компилятор верифицирующий или нет? Нет, не надо пояснять.
Здравствуйте, Temoto, Вы писали: T>Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Своими словами у меня плохо получается. Лучше почитать про изоморфизм Карри-Ховарда, хотя б тут, а лучше тут (сам пока в процессе). Грубо говоря, типы в программировании ведут себя подобно высказываниям в логике.
S>>>foo() { foo(); } S>>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>>1. Частный случай
S>Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
Наоборот, я привёл частный случай, когда дополнительная память необходима — а любая это рекурсия или нет — не важно, есть по крайней мере одна рекурсия (например, qsort) где память необходима и, значит, это не есть переход по дереву.
FDS>>2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST S>Концевая рекурсия — еще целый класс примеров, не требующих "памяти на рекурсию".
см. выше.
FDS>>3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор. S>При каждом не должен.
Должен. Например, транслятор это просто не может сделать иначе как
proc foo
call foo
RET
а значит, что при каждом вызове будет выделяться память. Вообще говоря, и интерпретатор должен делать аналогичные вещи, если только это программу не интерпретирует компилятор с ИИ, которого ещё не придумали или не интерпретирует человек (который сообразит всю бессмысленность таких манипуляций).
S>У меня вообще все время навязчивое впечатление, что все твои изречения определены в твоей голове на каких-то частных случаях типа язык без типа или неверифицирующий компилятор... Но выглядят-то они так, как будто они справедливы на все случаи жизни. S>Вот поясни, откуда ты вообще взял что обсуждаемый компилятор верифицирующий или нет? Нет, не надо пояснять.
Обсуждаемый компилятор неверифицирующий, т.к. верифицирующих компиляторов нет в связи с отсутствием ИИ. Пока ИИ не появится для рекурсии foo {foo();} компилятор будет вынужден выделять на каждый вызов место в стеке или преобразовывать концевую рекурсию в цикл.
Здравствуйте, samius, Вы писали:
S>Продолжаешь обсасывать передачу аргументов? Дальше сам с собой!
Ну, если ты признаешь наконец-то свою ошибку — то само собой.
FDS>>А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
S>Вот именно другого вопроса и касалось мое утверждение
А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных.
S>>>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
FDS>>И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
S>Теперь поделись секретом, как ты из моего утверждения сделал такой далекоидущий вывод? Нет, ну интересно просто.
Я уже писал выше, цитирую
Вы сказали о том, что тип процедуры не используется компилятором для получения информации о способе хранения данных, по крайней мере я так понял.
Понял я это из того, что вы стали возражать по поводу хранения, сказав "здесь есть варианты" так, как будто объявление процедуры не декларирует информацию о хранении данных.
Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>>>foo() { foo(); } S>>>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>>>1. Частный случай
S>>Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
FDS>Наоборот, я привёл частный случай, когда дополнительная память необходима — а любая это рекурсия или нет — не важно, есть по крайней мере одна рекурсия (например, qsort) где память необходима и, значит, это не есть переход по дереву.
Существование частного случая qsort не доказыват тот факт что дополнительная память необходима для всей рекурсии.
Раз это для тебя не очевидно, то я прекращаю спор
