Форум » » AkUrq2 » Ответить
AkUrq2
Акела: AkUrq 2.12 beta 8 Потихоньку пишется новая акурка2, основанная на идее Sfeli и содержащая не малую долю его кода. Возможности пока довольно скромные, но это вопрос времени. требует только IE5 (Windows 98+) Что мы имеем:[quote]Операторы: ;комментарий :(локация) p (текст без кавычек) pln (текст без кавычек) goto (локация) proc (локация) btn (локация),(описание) (оператор)&(оператор) cls instr (переменная)=(текст без кавычек) (переменная)=(значение) if (условие) then (оператор) [else (оператор)] inv+ [число,]предмет inv- [число,]предмет invkill [предмет] perkill play (имя_файла)[.wav] input (переменная) end _ (продолжение предыдущей строки) (<= >= <> > < = - + * / ==) Системные метки: :Сommon[_номер] :use_(предмет)[_действие] Конструкции: #/$ ##(код символа)$ #%(имя переменной)$ #(имя переменной)$ Системные переменные: previous_loc current_loc last_btn_caption common music count_(метка) rnd[число] inv_(предмет) [/quote] Краткое описание языка (Выборочно использовалась помощь от Корвина) [more][quote]Операторы: ;комментарий - Помогает разработчику не запутаться в своём коде. Всё после ; игнорируется интерпретатором (до конца строки) Пример: pln Это будет напечатано.;А этот комментарий - до конца строки, напечатан не будет. :(локация) - Оператор обозначения меток. Пример: :локация Отличие от досурки - в метках поддерживаются конструкции #$, #%$, ##$. Если вы хотите сохранить совместимость с dos_urq не используйте в метках такие символы х) p (текст без кавычек) - Выводит на экран текст. pln (текст без кавычек) - Выводит на экран текст и переносит строку. goto (локация) - Переходит на указанную локацию. Если метки не существует, - оператор игнорируется. Пример: goto tower proc (локация) - Передает управление на указанную метку, но когда встречается end, - возвращает управление обратно, оператору, следующему за proc. Допустима вложенность. Если метки не существует, - оператор игнорируется. Пример: proc tower btn (локация),(описание) - Создает кнопку для выбора вариантов действия с надписью на ней (описание), при клике на ней будет осуществлен proc на системную метку Common (если такая есть), затем переход на (локация). Пример: btn tower,Взобраться на башню (оператор)&(оператор) - объединение нескольких операторов. Пример: cls&pln Текст&btn tower,Взобраться на башню cls - Очищает экран instr (переменная)=(текст без кавычек) - Устаревший оператор. Присваивает переменной текстовое значение. Всё что после "=" заносится в переменную (переменная), поэтому писать следует без кавычек. Пример: instr time=время - 17:42 (Альтернатива time="время - 17:42") (переменная)=(значение) - Присваивает переменной (значение). Пример: time="время - 17:42" min=42 В первом случае присвоили строку, во втором число. Для совместимости с досуркой, которая некорректно понимает кавычки, крайне не рекомендуется присваивать строки таким способом, желательно использовать для этих целей устаревший оператор instr. if (условие) then (оператор) [else (оператор)] - Оператор условия. Можно делать сложную конструкцию, используя &, and, or, not и скобки. Допустимость любой степени вложенности if'ов сохраняется, else всегда соответствует последнему if'у. Пример: if inv_Спичек>=50 then btn buildHouse, Построить домик из спичек inv+ [число,]предмет - Добавляет в инвентарь предмет(ы). Если [число,] не указано, добавляется 1 предмет. Пример: inv+ Жемчужина inv+ 5,Жемчужина В первом случае добавится одна Жемчужина, во втором пять. inv- [число,]предмет - Удаляет предмет(ы) из инвентаря. Если [число,] не указано, удалится 1 предмет. Пример: inv- Жемчужина inv- 5,Жемчужина Количество предметов не может быть отрицательным. invkill [предмет] - Без параметров - удаляет все предметы из инвентаря, Если [предмет] указан, то удаляет только предметы типа [предмет]. Пример: invkill invkill Жемчужина В первом случае удаляются все предметы, во втором только все жемчужины. perkill - Очищает все ранее присвоенные переменные. play (имя_файла)[.wav] - Однократно проигрывает из папки квеста указанный файл. Если расширение явно не указано, то по умолчанию ищется .wav файл. Пример: play 05 - Forsaken.mp3 play 05 - Forsaken В первом случае проиграется файл "05 - Forsaken.mp3", во втором - "05 - Forsaken.wav" input (переменная) - Просит пользователя ввести строку, значение которой будет присвоено указанной переменной. Пример: input x Для совместимости с досуркой, которая некорректно понимает присвоенные в input строки, перед воодом строки следует делать так: instr x= input x end - Оператор конца локации. На этом месте выполнение квеста обычно прерывается для ожидания дальнейших действий игрока (например нажатие на кнопку). Или же происходит возврат к следующему после proc`а оператору, если до этого встречался proc (смотри подробнее proc). _ (продолжение предыдущей строки) - Оператор склеивает строку с предыдущей. Пример: pln Текст в этой строке слишком длинный, поэтому мож _ет следует перенести его сюда? (<= >= <> > < = - + * / ==) - Используются в операторе if и операторе присваивания. Подробнее о ==: == Дает истину при сравнении строковой переменной со строкой по правилам сравнения регулярных выражений, т.е.: Пример: if "aBBBa"=="a*a" then ;Верно if "F"=="[A-Z]" then ;Верно. if "F"=="[!A-Z]" then ;Неверно. if "a2a"=="a#a" then ;Верно. if "aM5b"=="a[L-P]#[!c-e]" then ;Верно. if "BAT123khg"=="B?T*" then ;Верно. if "CAT123khg"=="B?T*" then ;Неверно. Верно значит что условие даст истину и выполнится then Неверно - условия ложно, и выполнится else (если он есть). На самом деле это несложно. Описание: ? Любой одиночный символ * Ноль или более символов # Любая одиночная цифра (0-9). [charlist] Любой одиночный символ в классе символов (списке) [!charlist] Любой одиночный символ не принадлежащий классу символов Примечание: в Досурке этот оператор работает по другому. За подробностями к Виктору. Системные метки: :Сommon[_номер] - Локация вызывается после каждого нажатия на кнопку. Зависит от системной переменной common, (при common=0 вызывается "common", при common=12 уже "common_12", и так далее) Пример: :Сommon pln Если вставить этот кусок кода в большой квест, то к его концу всем точно надоест эта надпись х) end :use_(предмет)[_действие] - Системная локация, если она существует, то с предметом можно совершать действия. Если действие опущено, то по умолчанию оно будет "Осмотреть". Таких локаций может быть несколько, но они не должны называться одинаково. Конструкции: Конструкции которые заменяются при выполнении кода значением. #/$ - Заменяется на перенос строки. ##(код символа)$ - Заменяется на аски символ с указанным кодом. Обычно используется для вывода служебных символов (";", "$"..) #%(имя переменной)$ - Устаревшая конструкция. Используется вывода строковых переменных в досурке. #(имя переменной)$ - Оператор для вывода переменных. В досурке - только числовых. Для совместимости всегда выводите строки с помощью #%(имя переменной)$ пустые конструкции типа #$ заменяются на пробел Системные переменные: previous_loc - Содержит имя предыдущей локации current_loc - Содержит имя текущей локации last_btn_caption - Содержит описание последней нажатой кнопки. common - Переменная управляющая работой системной локации Сommon (смотри подробнее "системная локация Сommon") Пример: common=1 music - зацикленно проигрывает из папки квеста указанный файл. Если расширение явно не указано, то по умолчанию ищется .mid файл. Пример: music=5 music="5.mid" instr music=5.mid Во всех случаях проигается файл "5.mid" count_(метка) - Переменная хранит в себе число заходов на метку. rnd[число] - Если число опущено, то при обращение генерирует случайное число от 0 до 1. Если обозначено, то случайное целое число от 1 до число. inv_(предмет) - Системная переменная для управления инвентарём. Пример: inv_жемчужина=50 if inv_жемчужина<5 then pln Что-то у тебя мало жемчужин! Возьми-ка ещё одну!&inv+ Жемчужина В первом случае, сколько бы у вас не было жемчужин, их станет 50, во втором - если жемчужин меньше пяти, то выводится текст и в инвентарь добавляется ещё одна жемчужина. Существует устаревший вариант проверки вещей в инвентаре, для совместимости с RipUrq: Пример: if 2 жемчужина then pln Хмм, у тебя есть две жемчужины (или даже больше)! Ладно проходи! if Жемчужина then pln Хмм, у тебя есть жемчужина! Ладно проходи! В первом случае проверяется есть ли у игрока две жемчужины. Проверка пройдет успешно если у игрока две или больше жемчужин. Альтернатива if inv_жемчужина>=2 then .... В втором случае проверяется есть ли у игрока предмет жемчужина. Проверка пройдет успешно если у игрока одна или больше жемчужин. Альтернатива if inv_жемчужина>=1 then .... Дополнения приветсвуются.[/quote][/more] очень короткий FAQ:[quote]В1: Тут слишком мало возможностей для моих извращённых идей :) где синусы, вычисление корня, тысячи картинок, xbtn, и вообще где первая акурка? (привет Суд :) О1: Думаю первая акурка дорабатываться больше не будет. Новые операторы в квотерое появятся со временем, но не так как они появлялись в первой акурке: операторы будут появляться только после того как их синтаксис утвердят большенство метров, к которым я отношу: Евгения, Сфели, Виктора, Корвина. Уважаемый Борщевский разумеется тоже метр, но поскольку он ненавидит урку, я боюсь его спрашивать :) В2: Где инвентарь? Месяц найти не могу уже. (привет Хлом :) О2: Клавиши I и F6 открывают инвентарь. В3: Как теперь закрыть инвентарь? (привет Гор ) О3: Теми же клавишами. В4: Как закрыть текущий квест и начать новый? О4: F2 выводит в меню. В5: Что можно настроить в ини файле? О5: Можно изменить шрифт (Goraph) и включить/отключить управление кнопками на цифрах. Если результат вас не устроит, а как было вы не запомнили х) то удалите ини файл[/quote] Ну и выражаю благодарность Sfeli который написал добрую половину функций. Их легко вычислить - если чтото в квотерое работает без проблем - это писал Сфели) Если глючит - то Акела) Сообщения в этой теме буду периодически удалять
Ответов - 73, стр:
1 2 3 4 All
p_alex:
Акела: 2.12 beta 8 (первый пост обновлён) *поправлен оператор input (Goraph) *можно уменьшать и увеличивать шрифт [+ -] (Евгений) *по умолчанию убраны цифры с кнопок (Евгений) (можно сменить в ини файле) *по умолчанию подсвечивается первая кнопка (Goraph) *добавлена системная переменная inv_<предмет> *подправлен интерфейс *добавлена поддержка дос кодировки (Goraph) *вернул возможность шифровать файлы *invkill [предмет] *переменная music= previous_loc current_loc last_btn_caption *== *_перенос в ней даже работает кукла х)
Platov: Шикарно. Проверил на паре квестов, работает без глюков. )
Акела: м... ну у меня иногда наблюдаются странные вылеты из программы, если особо усердно кликать мышкой) причина ищется...
Platov: Приятно что вернули шифрование, теперь не будет больше прохождения игр в блокноте. )
Акела: написал небольшое описание по urql (только те операторы которые поддерживают на данный момент и досурка и акурка2, с комментариями) (в первом посте нажмите на "Скрытый текст")
fireton: (задумчиво) Хм. Может, для урки еще не все потеряно...
Хломидоманад: Ура! С новой жизнью и избавлением от richtx'а!=)) Толком пока не играл ни во что (как раз, наверно, опробую на игре Platov'а), но первые впечатления от тестовых запусков в целом положительные. Есть пока две сравнительно несложно реализуемых (надеюсь)) просьбы: вернуть инвентарь по правой кнопке (потому что в лом тянуться до клавиатуры каждый раз) и сделать, помимо досуркиных, ргбшные настройки для цветов фона и текста. И не забудь сделать urq_type=2 =) Вива Квотерой=))!
Korwin: Platov пишет: Приятно что вернули шифрование, теперь не будет больше прохождения игр в блокноте. ) Не в этом счастье... поверь мне дружище... чиет (xbtn) хоца... а по рукам!!! по рукам!!! А все равно хоца...
Korwin: Бумеранг-Урка (Урка возвращается)=BURQ - оно же расшифровывается как вторая попытка (A(эй) - первая, B(би) - вторая. А размер шрифта регулируется из главного меню? В смысле вижу, что нет, но это как-то не совсем удобно. Особенно для начинающих игроков, которые ини-файлы не умеют редактировать. Порадовало очень, что справился с шифровкой .qs2 - свои же Крылья запустил. Но с проблемами - там у меня часы есть, так квотерой выдает Время 7: 0 5 А надо разумеется Время 7:05 Еще - при попадании в локацию, где есть btn - пустышка а других btn нет - Квотерой вылетает. :( А так - отличная программа! Жду развития совместимости в первую очередь.
Акела: Korwin пишет: Еще - при попадании в локацию, где есть btn - пустышка а других btn нет - Квотерой вылетает. :( подробнее?..
Platov: Korwin пишет: Не в этом счастье... поверь мне дружище... чиет (xbtn) хоца... а по рукам!!! по рукам!!! А все равно хоца... Та верю Корв, верю. А почему все так против xbtn? Ну да, несовместимость со старыми версиями. Но если будет хорошая новая версия, все ведь перейдут на неё? Отпадёт проблема с поиском нужного интерпритатора, и xbtn будет.
Korwin: "Все против" это сильно сказано. Просто есть проблема синтаксиса, доставшаяся нам в наследство от первого автора. Это определение оператора в URQ. Оператор состоит из собственно оператора и параметров, отделенных запятыми. Концом оператора является или конец строки, или '&'. Отсюда проблема - каким образом интерпретатор определит, что закончился составной оператор xbtn? Та реализация, которая есть в первой AkURQ, насколько я помню, выглядит не по-урковски.
Александр Граф: А почему бы Вам не сделать xbtn не совсем так, как задумано было. т.е. не переход и выполнение, а просто выполнение кода. А запятые и & можно будет экранировать ##$?
Korwin: Александр Граф пишет: А почему бы Вам не сделать xbtn не совсем так, как задумано было. т.е. не переход и выполнение, а просто выполнение кода. А запятые и & можно будет экранировать ##$? Какой синтаксис предлагаешь? А то мы в свое время голову сломали - ветка до сих пор на форуме висит. Свой пример, пожалуйста:
Александр Граф: xbtn (код),(имя) Примеры: xbtn goto abcd,hhh xbtn goto abcd##28$p здесь у нас текст##44$ даже с запятой, а тут у нас название кнопки или даже xbtn (метка), (код), (имя) Примеры: xbtn abcd, p здесь у нас текст##44$ даже с запятой, а тут у нас название кнопки Правда я не помню как заменяются ##$ по-моему уже при выводе, а не при парсинге, но для xbtn можно свое правило создать. Только запутаться можно жестоко.
Korwin: Не все так легко, Граф. Код может иметь вставки в виде других операторов с запятыми, те же кнопки, да и #%строковая переменная$ тоже штука непредсказуемая. В свое время я предлагал xbtn метка, название, где метка это имя proc, но не понравилось
Александр Граф: А если запятые в конструкции #%$, то они там и должны оставаться, не может быть такого, чтобы конструкция начиналась и не заканчивалась, т.е. запятые в таких конструкциях должны автоматически игнорироваться, а не то будет ошибка. xbtn goto abcd##28$p здесь у нас текст##44$ даже с запятой #%asd,$ а тут у нас название кнопки Тут будет ошибка, от того, что "goto abcd##28$p здесь у нас текст##44$ даже с запятой #%asd,$ а тут у нас название кнопки" воспринимается одной строкой(должна быть по идее). А если в самой переменной(не в названии) содержатся запятые и &, опять же можно создать правило, что они все в xbtn заменяются на конструкции ##$. Хотя получается слишком много правил.
Chicago1920: Акела, может стоило из пре 1 и пре 6 сделать стабильную 1.3, а потом заниматься второй акуркой? И второй вопрос:в чем отличие 1 и 2 акурки?
Александр Граф: Кажется, я сглупил: при таком подходе не возможны вложенные xbtn. Придумал другое: создать конструкцию, которая заменяется на текст конструкции. т.е. #@abc$ заменяется на abc. Причем, замена происходит только на первом уровне. Вот: xbtn #@goto ass&proc xyz$,назв. #@goto ass&proc xyz$ должно замениться на goto ass&proc xyz и выполниться. По идее.
Nex: о, какие страшные конструкции.
fireton: Идиотизм, по-моему. URQL ущербен, по определению. Синтаксис языка не продуман совершенно. Поэтому постоянно приходится подставлять костыли...
Александр Граф: Знаю... зато можно будет в метках локаций использовать запятые и & :) Они хотя-бы похожи на конструкции URQL...
Chicago1920: Chicago1920 пишет: Акела, может стоило из пре 1 и пре 6 сделать стабильную 1.3, а потом заниматься второй акуркой? И второй вопрос:в чем отличие 1 и 2 акурки? Chicago1920 пишет, но никто не отвечает)
Акела: как никто не отвечает) я каждый день заглядываю на форум и стараюсь отвечать даже на лс) мне просто страшно читать эту тему х) акурк2 на хтмл, первая на рич, основное отличие в этом Nex пишет: о, какие страшные конструкции. +1)
Korwin: Акела пишет: Nex пишет: цитата: о, какие страшные конструкции. +1) А что если все же как я предлагал? :лока1 ... xbtn метка_проц,Название кнопки ... end :метка_проц операторы end Мне кажется не слишком уродливо и сочетается с принципами URQL Какая разница - внутри локи операторы лежат или рядом?
frodo: А может так? :лока1 ... xbtn метка_проц,лока2,Название кнопки ... end :метка_проц операторы end где лока2 -- локация, выполняемая после :метка_проц, т.е. xbtn выполняет proc метка_проц&goto лока2
Korwin: frodo пишет: :лока1 ... xbtn метка_проц,лока2,Название кнопки ... end :метка_проц операторы end где лока2 -- локация, выполняемая после :метка_проц, т.е. xbtn выполняет proc метка_проц&goto лока2 Тогда надо оставить возможность пустой метки xbtn метка_проц,,Название кнопки
MixeratoR: 2Akela: Не мог бы ты ввести в Акурку (опционально) отображение названия текущей локации?
СантиМЭТР: Могут быть проблемы при переходах в локацию по goto. Может лучше сделать системную переменную для отображения заголовка окна? Или ничего не делать?
Акела: Системные переменные: previous_loc - Содержит имя предыдущей локации current_loc - Содержит имя текущей локации
Korwin: Акела пишет: Системные переменные: previous_loc - Содержит имя предыдущей локации current_loc - Содержит имя текущей локации Это понятно. Речь шла об отображении в заголовке окна не названия программы, а имени локации. Т.е. например системная переменная instr win_capture="" - отображается имя программы интерпретатора, instr win_capture=current_loc - - отображается название текущей локации. instr win_capture="Дом" - заданное название окна. Лично я не уверен, что это надо делать.
Акела(w): MixeratoR пишет: 2Akela: Не мог бы ты ввести в Акурку (опционально) отображение названия текущей локации? Корв чтото ты мудришь, тут ничего такого я не нашёл. ну делать в любом случае не стану.
Korwin: Акела(w) пишет: Корв чтото ты мудришь, тут ничего такого я не нашёл. Может это я неправильно понял? MixeraroR, поясни свою мысль? Акела(w) пишет: ну делать в любом случае не стану Ну, меня ты не расстроил. :)
MixeratoR: Korwin, ты всё правильно понял. Да, это в принципе не сильно нужная функция : pln Название Локации pln Только придётся сделать вывод названия в виде отдельной метки, чтобы отображать ТОЛЬКО при переходе с другой локации.
Хломидоманад: Ну, это не такая большая жертва. Можно, кстати, и без отдельной метки сделать. Только не нужно Согласен, что функция слишком специфическая, чтобы добавлять ее в ближайшие несколько десятков акурок.
frodo: А вот что меня интересует: в предыдущей акурке если во время выполнения оператора pause кликнуть по инвентарю, то идущие следом операторы не выполняются. Нельзя ли сделать так, чтобы после операций с инвентарем игра возвращалась к вышеназванному оператору?
hi: К слову, а как на ней вставлять картинки?
noname: 1) Korwin, frodo - молодца! xbtn локация_процедуры, локация_перехода, название_кнопки идеально! 2) xbtn метка_проц,,Название кнопки - совершенно излишне. разве не лучше: xbtn метка_проц,текущая_локация,Название кнопки ? ведь после выполнения чего-угодно хорошо бы отобразить чё-то на экране, а не так, что юзер жмёт чего-то и ничего не меняется... или ты, Корв другое имел ввиду? p.s. только сегодня серьёзно взялся за куспель, так нате- урка возвращается! прямо издевательство какое-то :)
Korwin: noname пишет: 1) Korwin, frodo - молодца! xbtn локация_процедуры, локация_перехода, название_кнопки идеально! 2) xbtn метка_проц,,Название кнопки - совершенно излишне. разве не лучше: xbtn метка_проц,текущая_локация,Название кнопки ? ведь после выполнения чего-угодно хорошо бы отобразить чё-то на экране, а не так, что юзер жмёт чего-то и ничего не меняется... или ты, Корв другое имел ввиду? Ну, можно и так (с) И.Сталин Ты прав... только кто же это будет реализовывать в интерпретатор?
hi: Вам мо квешн плиз обана: Картинки 2-я акурка поддерживает? Так сложно ответить? Да / Нет / Не понял вопроса
Nex: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.
hi: Nex пишет: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда. А здесь проверял? http://urq.plut.info/soft Если хочешь пришлю 2-ю. Но у меня не получилось применить к 2-й версии акурки ни один из картинковых методов 1-ой... А списке операторов в самом верхнем посте вобще ничего такого нет. Наверное всё-таки 2-я идёт без картинок. Не успелось...
noname: hi пишет: Вам мо квешн плиз обана: Картинки 2-я акурка поддерживает? Так сложно ответить? Да / Нет / Не понял вопроса лично я ничего про картинки во 2-й акурке ничего не знаю. а про саму эту 2-ю акурку узнал только на днях- тогда же и сообщение в эту тему написал.
Victor: Nex пишет: Можно скачать и проверить. Было б где скачать, а то ссылка в верхнем посте, по доброй урковской традиции, ведёт в никуда.Обновил ссылки в закрепленном посте "urq_dos, Akurka, текущие версии".
ghoest: xbtn локация_процедуры, локация_перехода, название_кнопки идеально! Бред. чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? Гениальное изобретение велосипеда, в котором руль приколочен прям к колесу, для удобства Ну, то есть, нафига придумывать команду, вызывающую последовательно две (три, насколько) локаций, если это преспокойно решается стандартными методами языка? Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода. Либо как сейчас в АкУРКе, (хотя точно не помню место для указания фигурных скобок): xBtn {переменная=значение}, Локация, Кнопка (), чтобы потом переменную обработать в локации. Причем достаточно только такой, жесткой конструкции (одна_переменная=одно_значение), а далее можно творить чудеса. Например, передать в переменной целый список значений (и разбить его с помощью token), или с помощью #$ передать кусок кода. либо что то вроде xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально end :Локация [Параметр] Параметр = Параметр+Параметр.... и т.д. end Но второй вариант более принципиально изменяет концепцию языка URQL, по сути предусматривается возможность задания параметра/списка параметров для метки, которая в данном случае приближается по функциональности к процедуре
Korwin: xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] Номер не пройдет, так как по синтаксису языка URQL только в последнем параметре оператора может быть несколько запятых. Название кнопки должно быть последним, следовательно, только: xbtn локация перехода,{параметр(ы)},название кнопки, в котором могут быть запятые
ghoest: ну да, ну да. Второй вариант это конечно уже не URQL, а более другой язык :) Однако, вопрос о том, КАКИМ быть xBtn, кажется, по прежнему открыт? То что БЫТЬ должен - это однозначно, так как Btn, как простого перехода, явно не хватает. Однако xBtn в текущем варианте АкУРКи 1: xBtn {Произвольный_код}, Локация, Название кнопки действительно выглядит не по УРКовски. Но: кто сказал, что ОБЯЗАТЕЛЬНО нужен _произвольный код_? Поверьте, вполне достаточно определить значение какой либо переменной, а там уже творчески подключать мозги и делать с ней (переменной) все что угодно. Например, так: xBtn_VAR - системная переменная, устанавливаемая при нажатии кнопки xBtn. синтаксис xBtn : xBtn Значение, Локация_Перехода, Название кнопки //где Значение (или указывать здесь переменную?) как раз и устанавливается в xBtn_VAR. Пример :question pln 2х2=? xBtn 3, Answer, Три xBtn 4, Answer, Четыре xBtn До фига, Answer, Пять btn NoAnswer, Не знаю end :NoAnswer pln Я не знаю end :Answer pln Мой ответ #xBtn_VAR$ p Это if xBtn_VAR = 4 then p правильный else p неправильный pln ответ end Сие более по УРКовски - дешево и сердито. Естественно, это черновой вариант ЗЫ. Подумалось, что уже сейчас можно реализовывать _что-то вроде_ этого, ибо доступна переменная LastButtonCaption, однако это не совсемь есть гут, потому что Caption у Button относится уже к внешним элементам квеста и не очень хорошо приспособлена для внутрикодовых нужд. ЗЗЫ Не. все таки, если быть совсе точным, то синтиксис должен быть таким: xBtn Вычисляемое_Выражение, Локация_Перехода, Название кнопки
fireton: [pre]:Answer pln Мой ответ #xBtn_VAR$ p Это if xBtn_VAR = 4 then p правильный else p неправильный pln ответ end [/pre] Фигню ты написал. Кнопок может быть переменное количество, отдельные кнопки могут определяться в proc-ах и локации-счетчике. И как следить за этим зоопарком чтобы вычислить нужную кнопку? Самой правильной xbtn будет xbtn вообще без локации. Только название и список операторов. А переход можно сделать и с помощью goto. Правда тогда начинается гимор с системными переменными, но можно отслеживать goto внутри xbtn...
ghoest: fireton пишет: Фигню ты написал НЕА. Сие как раз задумывалось для ДИНАМИЧЕСКОЙ генерации кнопок. Поверьте, ОДНОЙ ПЕРЕМЕННОЙ запросто хватит, для того, чтобы обработать все возможные излишества :). Честно-честно. Приведенный пример, конечно не показатель, но поверьте, мне приходилось с СУЩЕСТВУЮЩИМ xBtn обходиться всего-навсего одним оператором в фигурных скобках {переменная=значение} До этого можно дойти чисто абстрактно, без приведения примеров. Введение даже единственной ПЕРЕМЕННОЙ в xBtn УЖЕ убирает жесткую статичность, присущую указанию метки перехода в обычном Btn, и этого достаточно(!) ДОСТАТОЧНО - в том смысле, конечно, что можно и огороду нагородить с более сложными конструкциями, что (возможно) будет и несколько удобнее, но уже не так принципиально. В принципе, самый правильный xBtn возможен и без локации ВООБЩЕ, с одной только переменной :-D (точнее, нужна предопределенная локация типа Common) - но тут уже да, будет пахнуть извращениями ЗЫ И как следить за этим зоопарком чтобы вычислить нужную кнопку? Я так думаю - раз уж мы ГДЕ-ТО вставляем кнопку, то именно там-то мы ее и обозначим. опять же - ОДНОЙ переменной. Ибо (опять же, абстрактно) - ОДНА кнопка = ОДНО событие, пусть даже следствием этого события будет изменение миллиона переменных и выполнение миллиона строк кода:) Важен принцип - переменная, в отличие от метки, НЕ СТАТИЧНА, она не определяется (как метка) при написании кода, она может изменяться - а это главное. Только название и список операторов. А переход можно сделать и с помощью goto И все это внутри фигурных скобок? Хммда... Будет весело смотреть на такой код... Вообще, конечно, если бы изначально в URQL был бы реализован такой принцип - то есть изначально btn выполнял бы список операторов, а не goto-переход, то это да, такой подход являлся более правильным, тут я согласен. Но URQL сейчас именно такой, какой он уже есть. Я всего лишь предложил НАИБОЛЕЕ МИНИМАЛИСТСКИЙ способ решения проблемы ограниченности Btn, согласующийся с уже существующей идеологией языка.
noname: ghoest пишет: Вообще, потребность в xBtn возникла из-за того, что обычный btn является всего лишь модификацией оператора goto и не способен передать ПАРАМЕТР в целевую локацию, что и не позволяло вешать на кнопку какой-то обработчик событий, кроме собственно перехода. это один из вариантов xbtn локация_процедуры, локация_перехода, название_кнопки идеально! в процедуре можно и соотв переменной значение присвоить, если тебя именно это волнует, а можно и любые другие операторы использовать. т е это- наиболее универсальный вариант. чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? а вот этим: xbtn #%локация_процедуры_ПАРАМЕТР$, #%локация_перехода_ГЛАГОЛ$, #% составное_название_кнопки$ т е ДО перехода передаются значения аргументов через соотв переменные (арг1, арг2, арг3, ... ) в соотв процедуре. ПОСЛЕ выполнения процедуры выполняем переход на локацию- обработчик. в случае 6-ти глаголов и 20-ти предметов при такой организации достаточно всего 6-ть локаций-обработчиков, обрабатывающих переданные аргументы, а не 120. т е, как ты верно заметил, потребность в xbtn возникла из-за потребности в передаче параметров. НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным. не вижу никакого смысла специально ограничивать себя ТОЛЬКО передачей параметров. предложенная конструкция поможет решить и насущные и будущие проблемы, и даёт дополнительные, ещё неисследованные возможности. p.s. поясню различие ещё раз: чем это лучче конструкции в стандартной УРКе: btn локация_процедуры, название_кнопки end :локация_процедуры goto локация_перехода end ???? здесь локация перехода жёстко привязана именно к этой локации процедуры. бывает же необходимость передачи одного из возможных параметров одной из доступных локаций-обработчиков. независимых параметров может быть и более одного, но все эти случаи с составлением и передачей наборов параметров можно решить в процедуре. важно, чтоб выполняемая ДО перехода процедура НЕ была жёстко привязана к конкретной локации перехода. иначе- действително, можно было бы обойтись и без xbtn.
ghoest: noname пишет: НО введя конструкцию xbtn локация_процедуры, локация_перехода, название_кнопки мы заведомо делаем язык более универсальным. Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. Если же под [локация_процедуры] имеется в виду обычная URQL-овская метка (пусть и вызываемая как бы через proc), то ничего не меняется. Но сделать такую новую локацию-процедуру - это более жестокое изменение URQL (Кстати, в первом посте я и предлагал что то вроде (гипотетически) возможности описывать метку с возможность опционального указания у нее ПАРАМЕТРА, то есть метка становится как бы процедурой. Извращение еще то, конечно, но весь URQL весьма похож на извращение (не бить - это добрая шутка) Поясню смысл моего xBtn c переменной. Существующий механизм Btn предполагает в описании кнопки указание жестко и заранее известной метки, уже прописанной в код. То есть тут затруднено использование динамически создаваемых кнопок, плюс к тому, для того чтобы различать нажатие разных кнопок, необходимо указание в разных операторах btn разных меток. xBtn в моем варианте позволяет при указании одной и той же метки в разных операторах xBtn все же различать их, как раз путем установления значения переменной. И этого уже хватит для того чтобы построить обработку этих различий В ОДНОЙ локации Вариант же с подвешиванием на Btn (или xBtn) целого списка операторов, вообще каких то действий - принципиально БОЛЕЕ ПРАВИЛЬНЫЙ, но URQL изначально не пошел по этому пути, и теперь уже трудно что то сделать без принципиального изменения языка. Теперь конкретно, как передать ПАРАМЕТР+ГЛАГОЛ в моем примере: (Динамически создаваемая кнопка) (не уверен насчет корректности оператора конкатенации строк, но пусть будет пока так) Instr РАЗДЕЛИТЕЛЬ = #$ [пробел или запятая или еще какой нить разделитель] Параметр1, Параметр2 - ранее рассчитанные выраженрия If <условие> then instr ПАРАМЕТР = Параметр1 + РАЗДЕЛИТЕЛЬ+ Параметр2 & xBtn ПАРАМЕТР, ОБРАБОТЧИК, Название кнопки
ghoest: noname пишет: в процедуре можно и соотв переменной значение присвоить, если тебя именно это волнует, а можно и любые другие операторы использовать. т е это- наиболее универсальный вариант. Блин . Я все пытаюсь додолбиться, и чувствую, что просто плохо объясняю... Дизлексия блин... В общем, как бы коротко.... На Btn должен висеть КОНЕЧНО же обработчик событий, где можно делать все что угодно. Но он НЕ ВИСИТ. И не будет висеть, по крайней мере в рамках концепции современного URQL. В URQL нет процедур, а есть только куски кода, обозначенные метками. Вариант, когда в xBtn запихивается кусок кода - безусловно РАБОЧИЙ вариант, но просто очень неудобно запихнуть сколько нибудь значительный набор операторов в часть строки, заключенную в фигурные скобки. Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки. В моем же варианте xBtn реально позволяет при указании одной и той же метки-обработчика в разных xBtn разграничить эти разные xBtn разными переменными, и выполнить РАЗНЫЕ (в зависимости от значения переменных) варианты кода в ОДНОЙ локации-обработчике.
ghoest: --
ghoest: БОЖИЙ СУД :) Проще один раз показать, чем нудно описывать. Вот вам пример кода, ИМИТИРУЮЩИЙ конструкцию xBtn ВЫРАЖЕНИЕ, Локация_Обработчик, Название кнопки. Написан с использованием ТЕКУЩЕГО варианта xBtn, в AkURQ 1.28pre6 Кнопок может быть произвольное количество. Локация обработчик - одна. С использованием моего варианта xBtn следующая строка: xBtn Answer,{xBtnVAR=#I$},Answer N #I$ поменялась бы на: xBtn #I$, Answer, Answer N #I$ ------------------------------ :Start pln enetr quantity of buttons input Max I=0 :CycleBegin I=I+1 Array#I$=rnd xBtn Answer,{xBtnVAR=#I$},Answer N #I$ if I < Max Then Goto CycleBegin end :Answer pln It's a #Array#xBtnVAR$$ btn Start, Again end --------------------------- Описание - код генерит массив заданного пользователем размера, заполняет его случайными числами и формирует необходимое число кнопок, по нажатию на которую сообщается число, находящееся в массиве под выбранным (кнопкой) номером Не представляю, как записать подобный алгоритм с использованием конструкции xBtn Локация_Процедуры, Локация_Перехода, Название кнопки. Предлагаю 1. Записать мой алгоритм с использованием конструкции xBtn Локация_Процедуры, Локация_Перехода, Название кнопки. 2. составить какой нить алгоритм с использованием этой конструкции, который было бы НЕВОЗМОЖНО решить моим методом Для имитации, наверно, можно использовать следующую конструкцию с нынешним xBtn: xBtn Локация_Перехода, {proc Локация_Процедуры}, Название кнопки )
noname: ghoest пишет: Да, если [локация_процедуры] станет именно ПРОЦЕДУРОЙ, новым типом в языке, а не просто локацией, меткой, как сейчас. ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем: 1) переход, аналогичный переходу по urq- овской команде proc на локацию локация_процедуры 2) выполняем всё что там автор понаписал, включая переходы на другие локации и любые другие хитрости до первого end - аналогично урковскому proc 3) встретив end выполняем переход на локация_перехода аналогично урковскому обычному баттону. 4) вот и всё. просто и хорошо. p.s. осталось ответить на два возражения: 1) Само собой напрашивается вариант - вынести эти операторы куда то отдельно, пометить их меткой и обратиться к этой метки из xBtn... Гениально? да нет, ибо мы тут неявно, но вернулись к ОБЫЧНОМУ Btn, просто вместо одной метки в этом операторе указали две... вдумайтесь в это. Ну и что что первая метка в этом наборе является как бы процедурой и мы там можем выполнить различные операторы - все равно метка этой процедуры, предполагаемого обработчика, ЖЕСТКО указывается в xBtn, и соответственно, в ней будет выполняться ТОЛЬКО ОДИН вариант обработки и 2) - последний пост ghoest. щазз попробую объяснить...
noname: итак, отвечаю на возражение первое: не знаю, было ли для ghoest существование в urq proc новостью, но вот фразы о том, что в кахих-то urq-шных командах чего-то ЖЁСТКО указывается не соответствуют действительности однозначно. рекомендую перечитать учебник по urq под редакцией Korwin-а, особенно про #такие$ и #%вот_такие$ вставки. возможно, это сразу снимет все вопросы и разногласия. в урке возможна такая конструкция: :#%переменная_1$ pln urq рулит! btn #%переменная_2$, жми сюда, неверный end где в текстовых переменных переменная_1 и переменная_2 указаны соотв имена локаций. никто специально такую конструкцию не придумывал- в урке многое возможно просто исходя из логики языка. возможно, я просто не понял суть твоего возражения. тогда- поясни. ИМХО это как раз тот случай, когда добавляя в кнопку название ещё всего одной локации получаем на одну бесконечность возможностей больше. делать xxbtn с бОльшим числом параметров уже будет незачем.
noname: отвечаю на возражение второе: действительно, замечательная конструкция сделана в Акурке. не пишу на ней т к мне нравится дос-окно. пробовал как-то под настроение, но добили отличия от синтаксиса досурки. твоя задумка xbtn тоже неплоха, но заведомо тесна. не вижу смысла заранее ограничивать авторов в средствах. с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено. твоим методом, т е с помощью xbtn, реализованного в соответствии с твоим предложением ИМХО возможно реализовать любой алгоритм, который можно реализовать с помощью xbtn сделанным по другим принципам, НО в некоторых случаях это будет гемор страшный. вот например, любой массив можно впихнуть в одномерный, НО представь, что ты пишешь игру, которая начинается в центре мира, а затем может постепенно дописываться во все стороны (вполне разумный вариант!). делаем координаты первой локации (0,0,0) на всякий случай (вдруг мы потом ещё подвал или башню где-нить поставим). и растим тихонечко мир во все стороны -> в одни стороны с "+" координатами, в противоположные- с "-". впихнуть всё это в одномерный массив ВОЗМОЖНО, но геморно. и это далеко не единственный случай (бывает нужно ещё списки предметов в карманах персонажей хранить, а для предметов- списки свойств). так же и с твоим xbtn всё возможно, но можно составить случай, когда это будет геморно. мне даже в простом случае (когда надо передать всего два параметра: отркыть замок отмычкой) будет неприятно пользоваться твоим xbtn, так как он в этой ситуации предполагает использование каких-то выкрутасов. это нехорошо для читаемости и расширяемости кода. и просто нехорошо.
fireton: А хотите так: [pre] :локация ... btn кноплок(10, 15), Вот такая вот кнопень end ... :кноплок if (кноплок_пар1 = 10) then ... ... [/pre] Можно реализовать. Довольно нетрудно.
ghoest: noname пишет: ёперный бабай! локация_процедуры - просто локация. при вызове xbtn локация_процедуры, локация_перехода, название_кнопки делаем: Еперный бабай! А Я ЧТО ПЫТАЮСЬ СКАЗАТЬ? Вот вы сами и сказали о том, что конструкция xBtn Локация1, Локация2, Кнопка практически ЭКВИВАЛЕНТНА комбинации из стандартных Btn и Proc (Да, я знаю и что такое proc, и что такое #$ - удивительно блин.) Насчет #$ и ЖЕСТКОСТИ. Согласен, #$ позволяет делать вообще все что угодно. И у вас в коде, благодаря #$, могут появиться команды, которых вы сами никогда не писали. Но у вас НИКОГДА не появится МЕТКА, которую вы заранее, ручками, нее вбили в тело кода. Вот именно то обстоятельство, что любой оператор, имеющий в качестве своих операндов ИМЯ МЕТКИ, обязан обращаться к конечному набору заранее определенных меток, я и называю жесткостью. В моем формате xBtn есть имя метки - указание на локацию-обработчик - и это ЖЕСТКИЙ, ИНВАРИАНТНЫЙ* ОПЕРАНД, но там же присутствует и выражение, значение которого передается в переменную, а значение может при обработке кода оказаться любым - и это ВАРИАНТНЫЙ ОПЕРАНД. В защищаемом же вам формате xBtn- два ИНВАРИАНТНЫХ операнда и ни одного вариативного. Именно поэтому он менее функционален и не эквивалентен моему. *инвариант - программный объект, не изменяющийся в процессе выполнения. В данном случае я имею в виду, что операнд ссылается на такой инвариант - метку Поясню на примере (noname): :#%переменная_1$ pln urq рулит! btn #%переменная_2$, жми сюда, неверный end Насчет #%Переменная_2$ - здесь, конечно же, к моменту нажатия на кнопку мы можем получить РАЗНЫЕ значения выражения #Переменная_2% и соответственно перейти на различные метки - но эти значения ВСЕГДА должны соответствовать какой либо ЗАРАНЕЕ определенной метке, иначе возникнет ошибка. А вот насчет возможности указания метки в виде :#%Переменная_1$ не уверен (ни в AkURQ, ни в DOS_URQ эта хрень не работает ;), но если это и можно, то мы здесь имеем фактически одну и ту же метку с переменным именем. Поясните на каком нибудь рабочем примере практический смысл необходимости в переменном имени метки. Разумеется, этот пример не должен сколь-нибудь простым способом реализовываться БЕЗ переменного имени твоя задумка xbtn тоже неплоха, но заведомо тесна. не вижу смысла заранее ограничивать авторов в средствах. ХА-ХА! Я утверждаю ровно обратное - тесна задумка с ВАШИМ вариантом. Уж точно теснее моей, а соответственно, и нынешнего xBtn {} с xBtn Локация_Процедуры, Локация_Перехода, Название кнопки будет всё тоже самое, только вместо {xBtnVAR=#I$} будет стоять имя локации, в которой это присвоение будет выполнено. НЕ БУДЕТ! - посмотрите мой код в БОЖИЕМ СУДЕ и сделайте такой же Кстати, все, описанное ниже - действительно, описывает невероятный геморрой, с которым столкнется кодер, если вместо существующего xBtn {} будет иметь только xBtn Лока, лока, Кнопа. C моим же xBtn он столкнется только с необходимостью конкатенировать n-ное количество необходимых к передаче параметров в один и последующему разбору его снова на n-номе количество. По пунктам. Формат оператора xBtn, используемый сейчас в AkURQ, с указанием произвольных операторов в фигурных скобках - отличный оператор по функционалу, но неудобный. Раз уж возникают мысли сменить формат - хорошо, но НЕ НАДО ИСПОЛЬЗОВАТЬ ФОРМАТ xBtn Л_Проц, Л_Перехода, Кнопка. ЭТО УБЛЮДОЧНЫЙ ЭРЗАЦ. Да, он будет несколько функциональнее обычного Btn - тем, что при нажатии можно будет вызвать дополнительную локацию через proc, но он НИКОГДА не приблизится по функционалу к существующему сейчас стандарту xBtn. Говоря человеческим языком - он не позволит реализовать некоторое количество алгоритмов, реализованных с помощью существующего xBtn (с фигурными скобками). Это я доказал абстрактно выше, когда отметил, что данный формат не имеет ВАРИАНТНОГО операнда. Мой же вариант ЭКВИВАЛЕНТЕН существующему формату xBtn. То есть позволяет (возможно более длинным путем) полностью реализовать любой код, написанный с использованием существующего формата xBtn. Попробую и это доказать абстрактно. С точки зрения программы нажатие пользователем на кнопку является ОДНИМ и только одним СОБЫТИЕМ. Как следствие, конечно же, может генерироваться еще множество событий, но все они будут иметь источником одно-единственное событие - нажатие на кнопку. Следовательно, описать это событие можно одним-единственным изменением данных, которыми оперирует программа - и это изменение и происходит при присвоении какого-то значения одной и только одной переменной. предложение по БОЖИЕМУ СУДУ еще в силе. Могу дополнить условия вызова: вызываюсь привести любой код, написанный с использованием xBtn {произвольное количество произвольных операторов} к коду с использованием только xBtn {переменная=значение (один оператор)}, а оппонент пусть сделает то же самое то же самое, приведя код к использованию только xBtn {proc Локация} Как было написано выше, данные конструкции имитируют соответственно мой вариант формата xBtn, и формат xBtn Локация1, Локация2, Кнопка Имеющий мозги - ДА ВЪЕДЕТ, а не учит меня тому, что я и так знаю ------------------------------------------------------------------ Fireton! Обалденная вещь! Вы как раз и предлагаете ИМЕННО ТО, что я имел в виду высказывая (возможно, невнятно) следующее (в первом своем посте здесь): либо что то вроде xBtn Локация, Кнопка, [Значение_передаваемое_в_параметр] //[] - значит, что применение опционально опционально end :Локация [Параметр] Параметр = Параметр+Параметр.... и т.д. end Но второй вариант более принципиально изменяет концепцию языка URQL, по сути предусматривается возможность задания параметра/списка параметров для метки, которая в данном случае приближается по функциональности к процедуре то есть, вызов локации, КАК ПРОЦЕДУРЫ С ПАРАМЕТРАМИ ;) И, раз уж вы говорите, что реализовать такой формат: xBtn (Пар1, ..., ПарN), Лока, Кнопа несложно, то я с радостью откажусь от ограничения на использование в xBtn ТОЛЬКО одной переменной (хотя и продолжу утверждать, что одной переменной достаточно - в математическом смысле этого слова) Тогда, как я понимаю, нужно будет предусмотреть в URQL следующее: Либо возможность описывать метку как процедуру, то есть после ее названия каким то образом перечислить все аргументы, которые могут быть переданы в метку как параметры ее вызова :Лока Арг1, ... АргN Либо предусотреть какое то глобальное хранилище для передачи параметров, к которым можно обрашаться в локации (вроде нынешнего глобального массива, который хранит части строки при разбиении ее на токены) То есть, при вызове xBtn (Пар1, ..., ПарN), Лока, Кнопа присваивается значение системной переменной КоличествоАргументов = N, а также набору типовых переменных Аргумент1 = Пар1...АргументN = ПарN, к каковым переменным мы и будем (при необходимости) обращаться в локации обработчике.
fireton: Не, парсить названия параметров и присваивать - это гимор. :) Пусть лучше будет так. При нажатии на кнопку, определенную как [pre]btn локация(зн1, зн2), Текст кнопки[/pre] произойдет переход на локацию "локация". При этом переменной локация_пар1 будет присвоено значение зн1, переменной локация_пар2 - значение зн1 и т.п. Количество значений-параметров - не ограничено. Так нормально? (а чего мы делаем в теме про акурку?)
ghoest: fireton! Абсолютно согласен! Единственное - при возможности использовать в общем виде неограниченное количество передаваемых параметров - переменная, хранящая общее число переданных параметров все-таки нужна. А вдруг мы не будем знать заранее количество параметров, которые нам передадут в обработчик. Пока в голову не приходит пример такой ситуации, но мало ли? Повторяю - я не настаиваю на использовании ТОЛЬКО ОДНОЙ переменной, передаваемой как параметр. Это самоограничение родилось исключительно от мысли, что реализация подобная вашей окажется сложной и несогласующейся с парадигмой URQL. Суть моих рассуждений можно свести только к одному - НЕ ИСПОЛЬЗОВАТЬ предлагаемый здесь (и возникший явно в запарке) формат xBtn Лока_Проц, Лока_Переход, Кнопа. НЕ ИСПОЛЬЗОВАТЬ потому, что функционал этого формата гораздо беднее существующего сейчас в Акурке. Не все это понимают, но это именно так. А обсуждаю в этой теме, потому что такое предложение (по формату) возникло именно здесь. Авторы Акурки справедливо отметили неудобность нынешнего формата xBtn {} (Хотя эта неудобность - исключительно неудобность чтения кода человеком. С машинной точки зрения нынешний xBtn идеален) - и, не совсем подумав, предложили в качестве замены набора произвольных операторов в фигурных скобках использовать ссылку на локацию, содержащую этот набор. С первой точки зрения кажется, что это абсолютно равноценная замена, однако это не так, что я и пытаюсь объяснить. Согласен, что мое утверждение об ОДНОЙ переменной (что все таки вполне сработает) было излишним и сбивающим с толку, уводящим от основной темы, которую мне хотелось затронуть. Не подумав, запихнул в одну кучу две разные темы :)
Nex: БОЖИЙ СУД, ААА
ghoest: ну блин, или иначе поединок, дуэль, брошенная перчатка, вызов. БОЖИИМ СУДОМ в средние века называлась крайняя степень разбирательства, когда анализ аргументов сторон заходил в тупик и невозможно было иначе доказать/опровергнуть чью-то правоту. Поскольку я видимо страдаю формой дизлексии, а именно, неспособностью выражать свои мысли в форме, понятной оппонентам, я предлагаю произвести доказательство практическими действиями.
fireton: Единственное - при возможности использовать в общем виде неограниченное количество передаваемых параметров - переменная, хранящая общее число переданных параметров все-таки нужна. А вдруг мы не будем знать заранее количество параметров, которые нам передадут в обработчик. Пока в голову не приходит пример такой ситуации, но мало ли? Если будет ситуация, когда понадобится передавать нефиксированное количество параметров, передавай первым параметром их количество. :)
noname: fireton пишет: (а чего мы делаем в теме про акурку?) эта тема- про акурку-2, автор которой ещё не определился с синтаксисом xbtn в этом языке (я так понял). пишет: btn локация(зн1, зн2), Текст кнопки ОК! мне это нравится больше любого из предложенных до этого вариантов. а, например, локация_парN будет хранить кол-во передаваемых параметров. to ghoest: кажись, я тебя понял. понял, что неверно тебя понимал, но ты и сам выражался не больно-то ясно. теперь- порядок! НО остался ещё один малюсенький момент: xbtn локация_процедуры, локация_перехода, имя кнопки, работающая так, как я описывал, математически ровно настолько же функциональна, как и твой xbtn. минутку, щазз поясню...
ghoest: fireton пишет: Если будет ситуация, когда понадобится передавать нефиксированное количество параметров, передавай первым параметром их количество. :) ААААААААААААААААААААААААААААААЯТОРМОЗ Вот это действительно, гениально ЗЫ (чет на форуме цитирование хреново работает - вместо автора цитаты вставляется мое имя, приходится править UPD noname Извините, что не жду вашего объяснения. Для начала уточню: я понимаю механизм действия формата xBtn Лока_Проц, Лока_Переход, Кнопа как ПОЛНОСТЬЮ эквивалентный нынешнему оператору xBtn Лока_Переход, {proc Лока_Проц}, Кнопа. Если я неверно вас понял, смоделируте то, как вы видите этот формат использую нынешний формат xBtn, если это невозможно - то объясните его действие подробнее. Если же я верно понял - то обещаю, конечно, сильно подумать над вашим разъяснением, однако чувствую, что все-таки прав я, однако объяснить не могу - не хватает мощности преобразовать мысль в текст :)
noname: ghoest пишет: я понимаю механизм действия формата xBtn Лока_Проц, Лока_Переход, Кнопа как ПОЛНОСТЬЮ эквивалентный нынешнему оператору xBtn Лока_Переход, {proc Лока_Проц}, Кнопа. вроде бы так, хотя я могу ошибаться насчёт особенностей работы xbtn в Акурке. по логике вещей- именно так. стираю начатый текст объяснений за ненадобностью, готовлю вариант 'Божий суд'. для этого придётся качать акурку. не уверен, что она у меня выжила на винте. UPD АГА! понял окончательно и бесповоротно! действительно, ТЫ ПРАВ! суть в чём: предложенный в этой теме xbtn (в споре с тобой нагло названный мной 'моим') был значительно более удобен старого btn и давал возможность обойтись значительно меньшим числом локаций там, где с btn пришлось бы использовать переменное либо очень большое кол-во локаций. на форуме мне не раз говорили, что без xbtn можно обойтись, и я не раз приводил контрпримеры. на этот раз Вы(раз уж Вы на Вы, но вроде бы в нете принято на ты?) предложили ещё более удобный и простой вариант, а я проявил узость и не гибкость мышления, и продолжил отстаивать предыдущий. СПАСИБО за проявленное терпение и подробные разъяснения. мне было сложно врубиться, так как не мог использовать xbtn на практике- в досурке его, к сожалению, нет. p.s. под занавес хочу ещё раз поддержать вариант, предложенный fireton-ом.
noname: НО есть одно НО, смотрим тему сначала: Korwin пишет: Не все так легко, Граф. Код может иметь вставки в виде других операторов с запятыми, те же кнопки, да и #%строковая переменная$ тоже штука непредсказуемая. В свое время я предлагал xbtn метка, название, где метка это имя proc, но не понравилось другими словами, нехорошо, что в предложенном fireton-ом xbtn разделяются запятой название кнопки(которое может содержать запятые) и передаваемые параметры(разделённые запятыми). на этом мозг отключается. иду спать.
ghoest: noname пишет: редложенный в этой теме xbtn ... был значительно более удобен старого btn и давал возможность обойтись значительно меньшим числом локаций там, где с btn пришлось бы использовать переменное либо очень большое кол-во локаций АГА :). И все таки лучший вариант предложил fireton (строго говоря, вариант предлагавшийся мной является лишь частным случаем варианта fireton'а) - с чем я и согласн. Главное - то, что к лучшему для УРКи. нехорошо, что в предложенном fireton-ом xbtn разделяются запятой название кнопки(которое может содержать запятые) и передаваемые параметры(разделённые запятыми). на этом мозг отключается. иду спать 1. fireton предлагает заключать список параметров в скобки 2. разделять можно точками с запятой 3. можно по прежнему использовать фигурные скобки, по любому оператор вида xBtn {пар1; ...; парN},Лока, Кнопа будет более стройным по построению и человекочитаемым, чем оператор xBtn Лока, {pln Куча_текста; if Укуренное_Условие then; и_прочая_чертова_куча_операторов}, Кнопа 4. В конце концов можно все-таки склониться к минимализму, и обойтись ОДНОЙ переменной :-D А теперь, раз опасный камень с предлагавшимся ранее нефункциональным форматом xBtn обойден (надеюсь) - просто соображение в порядке бреда. Касательно использования метки вида :#%Переменная$. Сейчас объявить такую метку невозможно (проверил лично на имеющихся у меня УРКах). Но если бы это было возможно (а почему бы и нет?) - то это, друзья, БОМБА. Представьте, что действительно можно описать метку, составная часть имени которой является переменной и определяется на этапе выполнения кода. Это вполне реально - ведь URQL является интерпретируемым языком, и текст программы, с которым работает плеер вполне можно динамически обновлять. Что мы имеем? А мы имеем неявно задаваемый параметр, который можно использовать при вызове метки! Проще объяснить на куске кода (он не рабочий, но мог бы работать): :loca input UsrData btn Say#%UsrData$, Answer end :Say#%UsrData$ pln You said #%UsrData$ end Данный пример, конечно мало показателен (он вполне может быть изменен с применением обычной метки - но важно следующее - мы смогли передать в вызываемую локацию некий параметр. Если эту возможность реализовать, то URQL станет единственным претендентом на самый бредовый язык в мире :-D
fireton: ghoest пишет: Касательно использования метки вида :#%Переменная$. Мой мозг отказывается это воспринимать. :(
ghoest: fireton пишет: ghoest пишет: цитата: Касательно использования метки вида :#%Переменная$. Мой мозг отказывается это воспринимать. :( Во-первых, такую метку употребил noname, см. в постах выше. Во-вторых, это в порядке бреда, просто для разминки мозгов :). В-третьих, это вполне в духе URQL :) ЗЫ. Хотя размышлять над таким извращением трудно. (Для меня метка вида :loc#%VAR$ примерно то же самое, что файл c именем file*name.??? :-D) - но тем не менее, легкость, с какой noname применил эту конструкцию заставляет предположить, что она вполне ожидаема кодером (в духе URQL)
ghoest: Перечитал еще раз участок ветки с моими рассуждениями - действительно, невнятно, и уводит от темы :( Предлагаю резюмировать итоги обсуждения - чтобы не забивать голову как вновь пришедшим, так и людям, непосредственно причастных к созданию Акурки2 и в частности, к определению окончательного формата xBtn. МАНИФЕСТ xBtn. 1. Необходимость введения оператора xBtn (либо расширения синтаксиса оператора Btn) признается и более не обсуждается. [для противников xBtn предлагаю кусок кода из поста о Божием Суде - этот код написан с применением существующего варианта xBtn из 1-й Акурки и, смею утверждать, не может быть реализован с помощью стандартного Btn - ни более длинным/трудным способом, ни каким либо другим - вообще никак] 2. За основу синтаксиса для нового xBtn (либо для расширения синтаксиса Btn) принимается вариант firetona, записываемый в общем виде как Оператор_Btn [список_выражений], Локация, Название кнопки - окончательный синтаксис следует в дальнейшем уточнить Данный вариант xBtn понимается, как вариант, математически эквивалентный существующему формату xBtn из 1-й Акурки, а так же как вариант, математически эквивалентный вызову процедур в других языках программирования. 3. Вариант синтаксиса xBtn Л_Проц, Л_Перехода, Название кнопки (а также любой другой синтаксис, который использует в качестве операндов только метки) - признается неудовлетворительным с функциональной точки зрения и далее не обсуждается.
полная версия страницы