Запрет на вызов функций функций, определённых ниже по тексту - за и против

З Ж Ж кнЗ

Если З — запись, то первое Ж — точно имя поля, а второе Ж — точно значение (символ от переменной у нас отличается?). То есть наличие функции с именем Ж не должно влиять.

Потом напишу.

З Ж Ж кнЗ

Если З — запись, то первое Ж — точно имя поля, а второе Ж — точно >значение (символ от переменной у нас отличается?). То есть наличие >функции с именем Ж не должно влиять.

А если З Ж1 Ж1 ... Ж24 Ж25 кнЗ (именно так и понимай как хочешь) - в SQL ведь по 25 полей сплошь и рядом? А на разделителях мы сэкономили.

Но это офтоп здесь.

Против - дизайн языка не должен оглядываться на какие-то мифические возможные IDE и прочую чушь. Наоборот, язык должен быть достаточно гибким чтобы вводить ограничения если надо, а не с ограничениями чтобы костыльно их обходить.

на какие-то мифические возможные IDE и прочую чушь

Попробуй любому программисту в бизнесе предложить язык без удобной IDE.

Наоборот, язык должен быть достаточно гибким чтобы вводить ограничения если надо, а не с ограничениями чтобы костыльно их обходить.

Я скажу, что ты неправ.

Во-первых, обычно в новом самолёте делают не больше одного нового нового решения - это правильно с точки зрения отладки. В Яре уже слишком много новшеств. Достаточно ошибиться один раз, чтобы самолёт упал. Свободу нужно ограничить, просто чтобы снизить вероятность, что винт зацепится за руль.

Во-вторых, добавить свободу потом можно, а убрать свободу потом не получится, потому что уже будет написан код, использующий эту свободу.

В-третьих, это западная механистическая философия говорит, что всё нужно поделить и рассматривать отдельно.

На самом деле в реальной работе мы имеем место с комплексом из языка, реализации, библиотек и IDE, все они влияют друг на друга, причём освобождая одно, сковываешь другое, а качество результата определяется по слабому звену. Дашь много свободы языку - не получится сделать нормальную IDE. Я ищу баланс.

Пример 1, почему свобода - это плохо: в лиспе можно любые идентификаторы. В расплату за это нельзя найти все вхождения идентификатора в исходный текст и даже нельзя отличить идентификатор от числа.

Пример 2: Многострочные строковые литералы - это хорошо? Казалось бы, да, свобода ведь. Зато я в лиспе ввожу в редакторе одну кавычку посреди файла и весь текст до конца файла тут же перекрашивается.

Пример 1, почему свобода - это плохо: в лиспе можно любые идентификаторы. В расплату за это нельзя найти все вхождения идентификатора в исходный текст и даже нельзя отличить идентификатор от числа.

В смысле, регулярными выражениями? Потому что если такого ограничения нет, то cl:read чётко отделяет идентификатор от числа и в получившемся дереве достаточно просто найти все вхождения идентификатора.

Пример 2: Многострочные строковые литералы - это хорошо? Казалось бы, да, свобода ведь. Зато я в лиспе ввожу в редакторе одну кавычку посреди файла и весь текст до конца файла тут же перекрашивается.

Здесь с любой многострочной конструкцией так. Кавычка от открывающей скобки в этом смысле мало отличается. Язык без единой многострочной конструкции, конечно, сделать можно (классический BASIC, например, или ассемблер), но пользоваться им будет очень неудобно.

Если вопрос про симметрию, то можно сделать кавычки `такими'.

Нельзя отличить вообще без чтения всех файлов, потому что вопрос о том, является ли ABCD сиволом или числом зависит от динамической переменной *read-base*. А чтение лисповых файлов может вызывать любые побочные эффекты, это делать опасно. Максимум, что можно, это во время чтения сохранять всё прочитанное.

Здесь с любой многострочной конструкцией так.

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

Если вопрос про симметрию, то можно сделать кавычки `такими'.

Про симметрию тоже. Строки не сделаны такими по двум причинам. Во-первых, все уже смирились с неудобством обычных строк, значит это не даст конкурентного преимущества, а любое нетрадиционное решение вызывает отторжение, даже если оно и лучше старого. Двойные кавычки есть в Русской раскладке. Я пользуюсь раскладкой Чистова, там есть «'», но отсутствует «`». И плюс к тому, у нас пока зарезервированы и «`» и «'», так что возможность сделать такие строки остаётся.

потому что вопрос о том, является ли ABCD сиволом или числом зависит от динамической переменной *read-base*

А если вспомнить про *readtable*, то текст на Common Lisp без частичного выполнения вообще прочитать нельзя. Но это не из-за того, что «в лиспе можно любые идентификаторы». В Racket идентификаторы такие же, но без выполнения программы они однозначно идентифицируется.

man (Java) интерфейсы

маразматично как-то

Да, по большому счёту нужно вспомнить именно про *readtable* . Одна из фишек Яра - *readtable* должен быть частью, общей между IDE и пользовательским кодом. Это накладывает ограничения на извращения, доступные при чтении, но зато даёт возможность обрабатывать исходный текст машиной. В целом при наличии МП с побочными эффектами обработать код машиной невозможно.

Потому что загрузчик системы может скачать код из интернета или из СУБД и сделать ему eval.

Но хотя бы можно будет распарсить имеющийся текст, не загружая программу. Если мы посмотрим на имеющиеся генераторы документации для CL, например, Tinaa, то они грузят все библиотеки в память (а не факт, что это вообще не опасно).

В Racket идентификаторы такие же, но без выполнения программы они однозначно идентифицируется.

#lang же перегружает

Понятно, что для очень многих синтаксисов (может быть, и для Си тоже) технически легко разрешить обращаться к функциям, определённым ниже по тексту.

народ голову ломает, а этому ... уже всё технически легко и понятно!

Но я вижу одно мощное «за» запрет такого обращения - проще сделать хорошую поддержку IDE.

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

Для собственно разработки мне кажется менее удобным требовать определения заранее.

тебе кажется

Красивая мода начинать с функции main и дальше вниз её детализировать. И не нужно повтора текста. Можно просто писать код и не отвлекаться на декларирование.

ты или откровенно лжёшь, или у тебя выдающаяся память - помнить все мгновенно-выдуманные сигнатуры

Приведите, пожалуйста, свои «за» и «против» необходимости декларировать ф-ии, к-рые будут использованы до места определения.

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

Я пишу почти всё время только на лиспе и уже не могу здраво оценить.

врача! срочно! тут очередное отравление Lisp`ом!