Возможно у вас склеены понятия "Наступило событие нажатия клавиши" и "В данный момент клавиша нажата", обычно в современных ОС их разводят, при этом при нажатии клавиши сначала генерируется 1 событие "нажата клавиша", потом пауза и потом с меньшим равным интервалом по времени начинают генерится события "клавиша нажата".

Если не прав - извините

Вы совершенно правы. Я бы даже сказал, что они не склеены, а есть только обработка события "в данный момент нажата клавиша".



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



GameLogo не транслятор. Это интерпретатор.



Это очень спорно с методической точки зрения.

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



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

Мелкая поправка, "В данный момент клавиша нажата" - это не событие, это свойство.

Для клавиши - свойство. Для среды исполнения - событие (исполнителем выступает черепаха).
В GameLogo нет целостной объектной модели. Есть только черты объектного подхода, необходимые для знакомства с методами, свойствами и событиями.
При этом возникновение какого-либо события в результате изменения каких-либо свойств пока не реализовано. В дальнейшем, возможно, программно неизменяемое свойство черепахи "датчик" будет связано с событием изменения значения датчика. Но пока не ясно, стоит ли это делать в рамках GameLogo.

Ну если события не реализованы - значит просто всё через свойства.

ИМХО - детей только путать на будущее, если свойства называть событиями...

Рад продолжению дискуссии.

Рассуждая про свойство клавиши "нажата" и событие "нажата клавиша", ушли в сторону от понимания описанной проблемы. А именно, при нажатии на клавишу обработчик ли события или черепашка, анализируя свойство клавиши, должен выполнятся некий код. В данном случае код - уменьшение значения переменной на 1. Клавиша не удерживается нажатой, это однократной нажатие. Текущий код исполнения программы прерывается обработчиком события, после обработки, указатель выполняемой инструкции снова возвращается на следующую команду после прерванной. На деле выглядит так, что код обработчика события выполняется несколько раз, так как не происходит возврата к другим инструкциям (хм, честно говоря, это надо проверить точно, но визуально это так).

Возникает вопрос, что является окончанием многих повторов выполнения кода обработки?
Если это некий промежуток времени, в течение которого проявляется свойство нажата ли клавиша, то такой подход не корректен с точки зрения предсказуемости и повторяемости. Раньше под ДОС, да и сейчас под любую ОС этому служил буфер ввода клавиатуры. Т.е. обработчик прерывания клавиатуры операционной системы помещал в некий буфер коды нажатых клавиш и, уверяю вас, при однократном нажатии там будет одна порция (2 байта для одного нажатия клавиш-стрелочек).
Дальше на усмотрение программиста: обрабатывать ли весь буфер или только часть, а остальное стереть.

В данном случае, мне непонятно как работает обработчик.

-------------------------------- -------------------------------- -------------------------------- ---------
Ну а про скобки и = ...
Меня скобки не напрягают, какие символы выделения блоков должны быть и не вижу в СИшности чего-то отторгающего. Меня привлекает в этом языке, то, что он легко воспринимаем детьми и не перегружен модулями, инкапсуляцией, библиотеками, прямым доступом к hardware ... В простоте - гениальность.

Кстати, если говорить о последнем пожелании, "потерянном символе", то это должна быть возможность повторять код, т.е. функции и процедуры. Предвидя возможные возражения со стороны разработчика, могу сказать что макросы очень даже подойдут. Т.к. это не требует изменения интерпретатора вообще - добавляется лишь пред-стадия обработки (замена объявления макросов в коде в текст макросов). Что-то типа:

МАКРОС ААА
<текст>
КОНЕЦ МАКРОСА

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

Если в языке есть функция получения времени, то можно самому написать правильную обработку нажатий, аналогичную генерации нажатий клавиш в современных ОС (первое нажание сразу, второе через некоторое время и потом частые нажатия с интервалом).

Это как?



А Вы как предлагаете называть то, что возникает (имеет быть) в случае нажатия на клавишу?



Отпускание клавиши.



Данный код наглядно демонстрирует принцип обработки.

повторить пока 1 = 1 {

          пиши 1

          пауза 100

          пиши 2

          пауза 100

}



событие нажата клавиша 39 ' стрелка вправо

          направо 90

          пауза 500

конец события



событие нажата клавиша 38 ' стрелка вверх

          вперед 100

          пауза 500

конец события

Да, это важная вещь, по мере возможностей она будет добавлена.

Скорее всего то, что у вас есть - это свойство "нажатости" конкретной клавиши клавы

Т.е. System.getIsPressed("A" - Это извлечение свойства "нажатости" клавиши "А".

А на события нужно регистрировать обработчики. Cкажем, если бы у вас было:

System.registerEventHandler(btn_Pressed, &my_Handler)
и при этом &my_Handler это ссылка на функцию типа "my_Handler(char btn)", и она бы потом вызывалась при нажатии любой кнопки - вот тогда нажатие кнопки было бы событием

Это если не делать полноценный ООП и перегрузку методов

PS: И почему если закрывающую скобку ) написать после кавычки ", то она становится смайликом?
(Добавление)
PPS: А вообще я уже занудствую

То, что реализовано в GameLogo в конструкции вида

событие нажата клавиша N



- - - - - 



конец события

называется обработчиком события.




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

хм, странно, ну тогда это наверное почти полноценные события, а как часто вызывается этот код?

С момента нажатия клавиши и до момента ее отпускания. Количество вызовов при этом лимитируется скоростью выполнения кода в обработчике события. Если необходимо реализовать одиночный вызов, то в конец кода в обработчике события можно добавить команду пауза <число миллисекунд>.

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

Для программирования простого управления объектами-картинками на экране способ, который выбран в GameLogo, является наиболее удобным. А именно, повторный вызов кода обработчика события наступает после завершения выполнения предыдущего вызова. Это обеспечивает отсутствие неприятной дискретности в управления картинкой-объектом на экране. При этом количество различных видов событий сведено всего к одному. Выбор этого способа продиктован общей концепцией GameLogo - упрощением программирования простых динамических игр (отсюда и название).

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