Oberon-07M

[DIzer]

Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе  07 ..

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

Что вы имеете в виду под фичиванием?
То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
Кроме того, никто не запрещает не пользоваться динамическими массивами, если вы не хотите, а программировать так, как будто их нет.

Это и называется фичиванием  - недостаток такого подхода заключается в том, что вы фичуете (добавляете особенности) изходя из текущих нужд - есть очень большая вероятность что они (фичи) будут неэффективными и малоиспользуемыми в предпологаемой области применения ЯП. Проще, вы можете ответить ДЛЯ ЧЕГО  и для КОГО вы создаете ЯП. Кроме того, описать  его общее место в области описания моделируемых систем общего вида... ну например, в контексте схемы предложенной в топике про "Многоуровневый ЯП на основе ОБЕРОНА".

[DIzer]

На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.

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

[valexey]

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

Наверно мну не правильно понял народ – я показал возможное решение данной очень конкретной задачи которое не использует массивы неизвестного размера на этапе компиляции. Вот эта задача:

требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.

Про нужность или не нужность оных массивов в языке я не говорил.

[DIzer]

Наверно мну не правильно понял народ – я показал возможное решение данной очень конкретной задачи которое не использует массивы неизвестного размера на этапе компиляции. Вот эта задача:

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

[Rifat]

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

На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.

Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.

[valexey]

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

Ну коль компилятор под винду, то встраиваемые решения отпадают, отпадает, по хорошему, и сервер. Остается десктоп, для десктопа такие задачи встречаются.

[valexey]

Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.

А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.

[igor]

Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы. 

Благодарю за приятную новость о выпуске Вашего компилятора! 

Раз язык изменился, то должно быть новое описалово. Планируется ли его публикация?
Не могли бы Вы по пунктам перечислить здесь все новшества, с короткими комментариями.

[DIzer]

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

Ну коль компилятор под винду, то встраиваемые решения отпадают, отпадает, по хорошему, и сервер. Остается десктоп, для десктопа такие задачи встречаются.

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

[Rifat]

Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.

А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.

На вскидку GetFileSecurity, есть еще много других, но надо их искать.

[Rifat]

Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы. 

Благодарю за приятную новость о выпуске Вашего компилятора! 

Раз язык изменился, то должно быть новое описалово. Планируется ли его публикация?
Не могли бы Вы по пунктам перечислить здесь все новшества, с короткими комментариями.

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

[valexey]

На вскидку GetFileSecurity, есть еще много других, но надо их искать.

Код: [Выделить]

BOOL WINAPI GetFileSecurity(
  __in       LPCTSTR lpFileName,
  __in       SECURITY_INFORMATION RequestedInformation,
  __out_opt  PSECURITY_DESCRIPTOR pSecurityDescriptor,
  __in       DWORD nLength,
  __out      LPDWORD lpnLengthNeeded
);

lpFileName [in]
A pointer to a null-terminated string that specifies the file or directory for which security information is retrieved.

RequestedInformation [in]
A SECURITY_INFORMATION value that identifies the security information being requested.

pSecurityDescriptor [out, optional]
A pointer to a buffer that receives a copy of the security descriptor of the object specified by the lpFileName parameter. The calling process must have permission to view the specified aspects of the object's security status. The SECURITY_DESCRIPTOR structure is returned in self-relative format.

nLength [in]
Specifies the size, in bytes, of the buffer pointed to by the pSecurityDescriptor parameter.

lpnLengthNeeded [out]
A pointer to the variable that receives the number of bytes necessary to store the complete security descriptor. If the returned number of bytes is less than or equal to nLength, the entire security descriptor is returned in the output buffer; otherwise, none of the descriptor is returned.

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

[valexey]

Поясню на всякий случай – мы тут размер не знаем ни на этапе компиляции, ни на этапе исполнения. Если после вызова функции нам оно скажет что "нишмогла, не поместилась в буфер даденого размера", то стратегия проста – удваиваем размер буфера и пробуем снова. Для удваивания буфера, как я заметил выше, массивы с размером неизвестным на этапе компиляции не нужны.

[Rifat]

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

[valexey]

А таки тормоз, да. Ведь обычный сценарий работы с этой функцией таков:

Код: [Выделить]

      //
      // STEP 2: Get security descriptor (SD) of the file specified.
      //
      fAPISuccess = GetFileSecurity(lpszFileName,
            secInfo, pFileSD, 0, &cbFileSD);

      // API should have failed with insufficient buffer.
      if (fAPISuccess)
         __leave;
      else if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) {
         _tprintf(TEXT("GetFileSecurity() failed. Error %d\\n"),
               GetLastError());
         __leave;
      }

      pFileSD = myheapalloc(cbFileSD);
      if (!pFileSD) {
         _tprintf(TEXT("HeapAlloc() failed. Error %d\\n"), GetLastError());
         __leave;
      }

      fAPISuccess = GetFileSecurity(lpszFileName,
            secInfo, pFileSD, cbFileSD, &cbFileSD);
      if (!fAPISuccess) {
         _tprintf(TEXT("GetFileSecurity() failed. Error %d\\n"),
               GetLastError());
         __leave;
      }

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

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

Делается это очень просто:

Код: [Выделить]

CONST
  unknown = 0;
...
VAR
  arr : POINTER TO ARRAY unknown OF CHAR;
...
arr := MALLOC(len); (* :-) *)