Oberon space

Цитата: Geniepro от Ноябрь 13, 2016, 09:24:29 pm

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

Я потому и предложил компилировать исходник интерфейса, что в нём содержатся и скрытые поля.

Это может быть невозможно в виду несуществования реализации модуля на момент раздачи разработчикам необходимых интерфейсов.

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

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

interface A {
    type S = struct {
        a int
    }
...

module A {
    type S = struct {
        a: int
        b: [16] char
        s: *S
    }
...

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

Как, имея только интерфейс A, транслятору собрать модуль B с эффективным размещением локального массива s из элементов структур S неизвестного размера.

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

Нет желающих rust добавить? :-)

Ну я добавил, и что, и где? 

Попробовал сделать на Rust'е, работает ну очень как-то медленно.
fn print_all(arr: &[i32]) {
    for i in 0..arr.len() {
        println!("{}", arr[i]);
    }   
}


fn main() {
    const N: usize = 40000;
    let mut arr: [i32; N] = [0; N];

    for i in 0..arr.len() { arr[i] = (N-i) as i32; }

    print_all(&arr);
    println!("-----");

    for i in 0..arr.len() {
        for j in 0..arr.len() - 1 - i {
            let tmp = arr[j];
            if  arr[j] > arr[j + 1] {
                arr[j] = arr[j + 1];
                arr[j + 1] = tmp;
            }
        }
    }
    print_all(&arr);
}

А если так:
let min_index a =
  let min i m =
    let m2 = if a.(i) < a.(m) then i else m in
    if (Array.length a) = (i+1) then
      m2
    else
      min (i+1) m2
  in
  min 0 0

      i, j, tmp: LONGINT;
      arr: ARRAY n OF LONGINT;

У тебя тут длинные целые (64 бита, видимо?), а у валексея и у меня просто целые (32 бита вроде). Это может влиять на скорость...

Вы уверждаете, что транслятор С++, написанный на Хаскелле вместе с программой на С++, всунутой в строку в исходнике на Хаскелле, не является программой, написанной на Хаскелле? Если нет, то что не так? Обратите внимание, что речь не о практической достижимости, а о принципиальной возможности. Конечно, такой принципиальной возможности можно достичь гораздо более простым путём, чем создание транслятора C++, но версия с транслятором веселей и наглядней.

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