Здравствуйте, alvas, Вы писали:

A>jvm = java virtual machine?

Да.

I>>А если дать трансляцию в Си, то можно будет запускать на самых разных платформах, чего Немерле уж точно никогда не сможет.

A>Почему?

С никогда я возможно и погорячился. В обозримом будущем не сможет. Компилить в нативный код — это вагон работы для каждой платформы. Другой вариант делать свою VM — опять вагон работы. Проще сделать транслятор в js или в Си.

Здравствуйте, Ikemefula, Вы писали:

I>Например если будет трансляция в js, то это сразу даёт возможность запустит код для той же jvm.

Дай ссылку на js для jvm

Здравствуйте, alvas, Вы писали:

I>>Например если будет трансляция в js, то это сразу даёт возможность запустит код для той же jvm.

A>Дай ссылку на js для jvm

http://tinyurl.com/3oewvsa

Здравствуйте, Ikemefula, Вы писали:

I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.

А можно генерировать Vala, который на выходе генерирует C + GObject

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

Здравствуйте, Ikemefula, Вы писали:

I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.

Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си.

Другой вопрос, что LLVM оправдывает свое название и реально низкоуровневая машина. К тому же регистровая. Ее поддержка может потребовать немалых сил.

Здравствуйте, catbert, Вы писали:

C>А можно генерировать Vala, который на выходе генерирует C + GObject
C>Или какое-то другое извращение вместо того, чтобы поставить mono.

Менеджед это не всегда самое лучшее решение.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, alvas, Вы писали:

A>>Здравствуйте, VladD2, Вы писали:

А>>>>тип как первоклассный. То есть разрешить передачу типа в функцию. Тогда возможен отказ от генериков. Уменьшение стадий макросов

VD>>>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.

A>>Приведи пример, пожалуйста

А>def astype(a, type){a:type}

А>так же хотелось бы получать аргументы с разделением константные или вариабельные

А>например macro power(a,b:int)
А>{

А>match constant(a)
А>| true // построение быстрого алгоритма
А>| false // генерирование метода деления на 2
А>}

Nemerle.Compiler.Parsetree.PExpr.Literal подойдет ?

А>хотелось бы иметь возможность узнать чистая функция или нет

Здравствуйте, Ikemefula, Вы писали:

I>Менеджед это не всегда самое лучшее решение.

Ну вот Vala не менеджед.

Здравствуйте, catbert, Вы писали:

I>>Менеджед это не всегда самое лучшее решение.

C>Ну вот Vala не менеджед.

Я про mono а не про Vala.

Здравствуйте, alvas, Вы писали:

VD>>Уже есть. Используй макросы и будет тебе счастье. В рантайме это == тормоза. В прочем, тоже никто не мешает Syste.Type передавать.

A>Приведи пример, пожалуйста

Пример чего? Макросов использующих информацию о типах? Ну, например, смотри макрос lock из стандартной библиотеки:

  macro @lock (lockOnExpr, body)
  syntax ("lock", "(", lockOnExpr, ")", body)
  {
    def typer = Macros.ImplicitCTX();
    def lockOnTExpr = typer.TypeExpr(lockOnExpr);

    typer.DelayMacro(lastTry =>
      match (lockOnTExpr.Type.Hint)
      {
        | Some(Class(typeInfo, _)) when typeInfo.IsValueType =>
          when (lastTry)
            Message.Error (lockOnExpr.Location,
              $"`$typeInfo' is not a reference type as required by the lock expression");
          None()

        | None =>
          when (lastTry)
            Message.Error (lockOnExpr.Location,
              "compiler was unable to analyze type of locked object, but it "
              "must verify that it is reference type");
          None()

        | _ =>
          def result =
            <[
              def toLock = $(lockOnTExpr : typed);
              System.Threading.Monitor.Enter(toLock);
              try { $body }
              finally { System.Threading.Monitor.Exit(toLock); }
            ]>;

          Some(result)
      }
    );
  }

А вообще, можно сделать поиск "TypeExpr" по всему каталогу макросов и посмотреть случаи его использования.

Ну, а лучше просто прочитать вторую часть Макросы Nemerle – расширенный курс

Автор(ы): Чистяков Владислав Юрьевич
Дата: 18.08.2011
Во второй части статьи о макросах Nemerle речь пойдет о макросах уровня выражения, о макросах, изменяющих синтаксис языка, а также о контексте компиляции, доступном в макросах, и тех возможностях, которые он предоставляет (типизации выражений, получении доступа к описанию типов проекта, информации о методах и т.п.).

. Там все подробно разбирается.

Здравствуйте, alvas, Вы писали:

A>Предлагаю в этой ветке обсудить какие возможности отсутствуют в Nemerle.
A>В общем чего людям в жизни не хватает

Не то чтобы абсолютно уверен, что это очень надо:
Упаковка юзингов, иногда они бывают надоедливые. Особенно если много файлов с одинаковым набором юзингов.

В отдельном файле, может быть с другим расширением (допустим *.usings) пишется:
(для примера напихал, может не из Немерла)

usings MyUsings
{
  using System
  using System.Collections.Generic
  using System.Data
  using System.Linq
  using System.Text
  using System.Windows.Forms
  using System.Xml.Linq
  using Microsoft.Office.Tools.Excel
  using Microsoft.VisualStudio.Tools.Applications.Runtime
  using Excel = Microsoft.Office.Interop.Excel
  using Office = Microsoft.Office.Core
}

Такие файлы считываются в первую очередь.

А потом в обычных файлах можно так:
usings MyUsings
using Somthing
.....
using ....

Здравствуйте, Silver_S, Вы писали:

S_S> Не то чтобы абсолютно уверен, что это очень надо:
S_S>Упаковка юзингов, иногда они бывают надоедливые. Особенно если много файлов с одинаковым набором юзингов.

S_S>В отдельном файле, может быть с другим расширением (допустим *.usings) пишется:
S_S>(для примера напихал, может не из Немерла)

Хорошая идея для макроса

Здравствуйте, dotneter, Вы писали:

A>>В общем чего людям в жизни не хватает
D>Компиляция в javascript

http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WUI.Reactive/Nemerle.WUI.Reactive/ViewModel.n#79

Здравствуйте, Ikemefula, Вы писали:

I>Но javascript это мало, нужно еще генерить код на Cи, вот это реальная тема — появится возможности херачить нативные аппликации.

Не появится. Точнее появится очень ограниченная возможность, так как в С много чего нет. Нет GC, нет библиотек. Для ограниченной задачи это решаемо. В общем случае объем работ таков, что проще использовать Mono.

Здравствуйте, Ikemefula, Вы писали:

I>Джаваскрипт может выполнять не только браузер. На ём и серверные приложения пишутся. Соответственно вместо написания N-бакэндов, можно написать один транслятор.

Ну, зачем жабаскрипт на колиенте — понятно. В броузерах только он и есть. А вот зачем он на сервере? Не, ну, я понимаю если там кто-то решил использоват Эрланг или Лисп. Но какой смысл в жабаскрипте на сервере? Не уж то в тормозах есть своя прелесть?

Немерле и так отлично на сервере работает. А преобрзование в жабаскрипт нужно исключительно для поддержки "легких" клиентов.

Здравствуйте, Ikemefula, Вы писали:

C>>А можно генерировать Vala, который на выходе генерирует C + GObject
C>>Или какое-то другое извращение вместо того, чтобы поставить mono.

I>Менеджед это не всегда самое лучшее решение.

Ну, да! Куда лучше интерпретация! Блин, я хренею дорогая редакция! (с)

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Для этого нужно генерить не код С, а поддерживать LLVM. Вот через LLVM как и раз будет нейтив. Это ИМХО куда более правильно, чем сразу хреначить какой-то там код на Си.

Вот только это ничем не проще и не быстрее.

ВВ>Другой вопрос, что LLVM оправдывает свое название и реально низкоуровневая машина. К тому же регистровая. Ее поддержка может потребовать немалых сил.

Главная проблема — это качественный GC. В прочем, у меня есть мысли по этому поводу.

Здравствуйте, alvas, Вы писали:

A>>Всего лишь тупой Script#?

A>Тогда уже лучше JavaScript -> JavaScript

Не такой уж тупой. Все же будет вывод типов и многие другие вкусности (например, $-строки). Если приложить услилия, то можно в жабасктипт конвертировать и более сложный немерловый код (паттерн-матчинг, вариантные типы, классы).

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

Если же эту идею совместить с идеей реактивного UI, то получится очень красиво.
Запусти прототип, погляди.

Мы планируем развить этот проект и сделать дин из самых интересных веб-фрэймворков. Все кому это интересно могут присоединиться.

Зачем так оверквотить?

Здравствуйте, Воронков Василий, Вы писали:

ВВ> Они просто более тормознутые, т.к. там нет специальной поддержки рантайма. Или по крайней мере не было раньше.

Ну там не только тормознутость накладывается рантаймом, а то что на самом деле не известно какой тип у нас и рантайм позволит присвоить

List<string> ls = new List();
List ll = ls;
List<Integer> li = (List<Integer>)ll;

а потом уже в рантайме во время использования метода get(index) выдаст ошибку .

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