Здравствуйте, VladD2, Вы писали:
VD>Ну, и как расценивать эти слова? Не обращать на них внимания?
Форум публичный, никто никого силой читать его не заставляет. И принимать на веру или во внимание чьи-то слова так же. Поэтому ты можешь игнорировать мои сообщения так же спокойно, как я некоторые твои.
Чтобы уточнить о чем идет речь: в данной теме было не одно твое сообщение (в основном препирательства с AVK), в котором не было конструктива. Именно их я и имел в виду. И вообще у тебя есть привычка общаться с собеседником в духе "Ты ничего не понимаешь, попробуй, сам все увидишь". Многие твои сообщения в подобном тоне так же можно безболезнено игнорировать.
Вот о чем я говорил. Самого себя я так же не считаю образцом для подражания и подобные слова могут быть сказаны и в мой адрес. Вот только обижаться на них я не буду.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот представь себе библиотеку для работы, скажем, с серийным портом всю написанную на макросах. По суть вместо некого КОМ-порт АПИ у нас будет специальный язык под это дело, причем еще не факт что удачного спроектированный.
"Написанную на макросах" != "язык под это дело". Кто мешает пользоваться обычными макросами, которые не расширяют синтаксис? Потом, пихать макросы где только ни попадя не имеет смысла.
ВВ>И таких библиотек на большом проекте могут быть десятки. Причем в 90 случаях из 100 эти макросы не будут предлагать ничего по сравнению с обычным АПИ кроме другой формы записи.
Это, конечно, всё вопросы культуры кода. Тут, кстати, кто-то высказывал интересную мысль, что булшитеры не смогут писать макросы из-за их относительной сложности, а те, кто смогут, не будут булшитерами и будут макросы применять аккуратно
Re[28]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Это, конечно, всё вопросы культуры кода. Тут, кстати, кто-то высказывал интересную мысль, что булшитеры не смогут писать макросы из-за их относительной сложности, а те, кто смогут, не будут булшитерами и будут макросы применять аккуратно
Тебе не кажется, что где-то такое уже было?
И не случилось
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Vermicious Knid, Вы писали:
VK>Думаю да, я добавил этот самый partial modifier и вообще произошел ICE. Отправлю-ка я баг-репорт.
Не факт, что глюк. Команда Nemerle пишет в Macro Tutorial про Stages of TypeBuilder, и хитрое свойство TypeBuilder.CannotFinalize,
неправильная установка которого может привести к ICE.
... << RSDN@Home 1.1.4 stable rev. 510>>
ДЭ!
Re[20]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, eao197, Вы писали:
E>Тебе не кажется, что где-то такое уже было? E>И не случилось
Ты про Лисп? Там именно так и случилось, но только язык популярным не стал.
Или ты про шаблоны C++? Так их проще педалить, да и предназначены они имхо для совсем иных задач были. Они, собственно, и не позволяют делать всё то, что возможно с помощью макросов Nemerle.
Re[21]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladGalkin, Вы писали:
VG>Не факт, что глюк. Команда Nemerle пишет в Macro Tutorial про Stages of TypeBuilder, и хитрое свойство TypeBuilder.CannotFinalize, VG>неправильная установка которого может привести к ICE.
В 0.9.2 CannotFinalize почему-то internal... Наверное, потому, что теперь и без его использования всё работает.
Re[25]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Ты про Лисп? Там именно так и случилось, но только язык популярным не стал.
Еще и про макросы в C/C++.
O>Или ты про шаблоны C++? Так их проще педалить, да и предназначены они имхо для совсем иных задач были. Они, собственно, и не позволяют делать всё то, что возможно с помощью макросов Nemerle.
У меня вообще впечатление, что нынешние шаблоны в C++ это только начало длинного пути их превращения во что-то другое.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Vermicious Knid, Вы писали:
VK>Record это только для публичных полей(т.е. строго говоря для описания конструкторов структур). Accessor у меня использовать не получилось. Он его почему-то не опознает. Возможно это из-за того, что он обычно выполняется на более раннем этапе компиляции, или по другим причинам. Нужно спросить разработчиков языка.
Блин... я наконец-то понял Вот как у меня получилось:
def builder = ctx.Env.Define(<[ decl: [Record] public class $(className : name) { [Nemerle.Utility.Accessor] mutable test : int; } ]>);
Т.е. все макросы болжны быть в куске AST, переданном в env.Define. А Record не работал потому, что при вызове env.Define у класса ещё не было полей.
Т.е. надо просто собрать AST заранее
Re[31]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, eao197, Вы писали:
E>У меня вообще впечатление, что нынешние шаблоны в C++ это только начало длинного пути их превращения во что-то другое.
Возможно. Типа опробовали, теперь можно и посерьёзней забабахать. Только комитет чего-то долго возится...
Re[25]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Ну и кто будет писать на Форте в таком стиле?
Речь не только в стиле.
Форт в свое время покорил многих примерно тем же чем и Лисп. Форт — это не просто язык программирования, это СРЕДА программирования. Среда, в которой эксперимент, проектирование, кодирование, отладка и верификация гармонично совмещены. Любые твои наработки тут же становятся частью СРЕДЫ. В ней легко писать слова (подпрограммы), тут же запускать их в произвольной комбинации, тестировать, переписывать и снова запускать и т.д.
Никакой подход юнит-тестирования для совремнных языков и сред даже и близко не стоит по степени отдачи от программирования непосредственно в СРЕДЕ.
Представь, что ты на C# написал ф-ию или метод и тут же в некоем immediate окошке пару раз вызвал эту ф-ию с разными параметрами, либо запустил на пошаговую отладку именно этот метод. Понимаешь, это совсем другой стиль работы. Программы быстро пишутся и отлаживаются, и к тому же на выходе получаем приличную надежность, которая обусловлена самой постановкой процесса разработки/отладки/верификации.
Форт — это некая идеология. Изначально ты имеешь некую среду, затем в процессе нескольких итераций постепенно затачиваешь среду разработки и сам язык под конкретную прикладную область. Затем пишешь программу именно в терминах и на языке (на своем видении языка) целевой прикладной области. Таких сочных, надежных и компактных программ, которые мне удавалось писать на Форте я так и не научился писать ни на одном другом языке программирования (С++ отдаленно позволял приблжаться к терминам прикладной области, но в сравнении с Фортом — слишком отдаленно) . Иногда, читая про Smalltalk, мне кажется, что их идеология близка к только что описанной, с той лишь разницей, что там все с упором не на функциональную, а на объектную декомпозицию.
O>Это уже вопрос идеологии — никто не будет так писать на Форте, так же как никто не будет писать в императивном стиле на Лиспе (LOOP не в счёт — не всем нравится).
Вопрос в количестве выражений с польской или обычной записью далеко не принципиален для Форта, там принципиальны несколько другие вещи.
Re[10]: Снова о Nemerle или профанация не пройдет :)
СТ>Придерусь к записи. Макрос Accessor по умолчанию создает только геттер. Чтобы заставить его СТ>создать сеттер, надо так и сказать [Accessor(WantSetter = true)] (в названии проперти мог ошибиться)
Блин, столько писать... Да проще уже "по-честному" это проперти нарисовать. Можно подумать, что это — принципиально.
Re[26]: Снова о Nemerle или профанация не пройдет :)
[bla-bla-bla]
V>Форт — это некая идеология. Изначально ты имеешь некую среду, затем в процессе нескольких итераций постепенно затачиваешь среду разработки и сам язык под конкретную прикладную область. Затем пишешь программу именно в терминах и на языке (на своем видении языка) целевой прикладной области. Таких сочных, надежных и компактных программ, которые мне удавалось писать на Форте я так и не научился писать ни на одном другом языке программирования (С++ отдаленно позволял приблжаться к терминам прикладной области, но в сравнении с Фортом — слишком отдаленно) . Иногда, читая про Smalltalk, мне кажется, что их идеология близка к только что описанной, с той лишь разницей, что там все с упором не на функциональную, а на объектную декомпозицию.
Я знаю о том, что такое Форт, я писал код на Форте и даже писал свою Форт-машину. Не понравилось — с трудом представляю себе, как на Форте написать корпоративное приложение, например.
Резюме: видимо, я так и не научился писать на Форте.
Re[11]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
V>Блин, столько писать... Да проще уже "по-честному" это проперти нарисовать. Можно подумать, что это — принципиально.
Не принципиально. Но проще ли? Сравниваем:
// Делай раз
[Accessor(WantSetter = true)]
mutable _somePropery : int;
// Делай дваprivate mutable _somePropery : int;
public SomePropery : int
{
get { _somePropery }
set { _somePropery = value; }
}
А ещё "делай раз" рефакторить проще. Да и соглашения об именовании соблюдаются автоматически А если не нравятся такие соглашения, можно явно указать property name или взять сорсы Accessor и написать свой макрос по мотивам.
Кстати, а можно поинтересоваться — а как предварительно сформировать список полей, а потом его вставить в объявление класса? Я попытался поменять твой код, чтобы использовать макросы внутри. Код, естественно, не работает:
using Nemerle.Compiler;
using Nemerle.Collections;
using Nemerle.Macros;
using Nemerle.Utility;
namespace Oyster
{
macro metaclass(className, body)
syntax ("metaclass", className, body)
{
def ctx = ImplicitCTX();
mutable code = [];
match (body)
{
| <[ { .. $props } ]> =>
foreach(<[ $(n : name) : $(t : name) ]> in props)
{
code ::= <[ decl:
[Accessor]
mutable $(n.NewName("_" + n.Id) : name) : $(t : name) ;
]>;
}
| _ => Message.FatalError($"Invalid metaclass syntax, expected properties definition, got $body");
}
// Что надо писать тут?
def builder = ctx.Env.Define(<[ decl: [Record] public class $(className.ToString() : usesite) { .. $code } ]>);
builder.Compile();
<[ () ]>
}
}
Re[19]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>Ну, положим, от ошибки неверного формата (кстати, имеет ли это место быть в случае ToString()) этот макрос не спасет. Он всего лишь делает запись короче и не позволяет ошибиться с циферками в скобочках. Всё. После его прохода у компилятора оказывается примерно вот что:.
VD>Как же не спасет, если формата просто нет?! Ты подставляешь имена переменных которые контролируются в во время компиляции. Я кстати, совершенно случайно ошибся когда писал код и мой пример уже неверный!
А о каком формате идет речь в твоём примере?
--
Re[26]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, vdimas, Вы писали:
V>Представь, что ты на C# написал ф-ию или метод и тут же в некоем immediate окошке пару раз вызвал эту ф-ию с разными параметрами, либо запустил на пошаговую отладку именно этот метод. Понимаешь, это совсем другой стиль работы. Программы быстро пишутся и отлаживаются, и к тому же на выходе получаем приличную надежность, которая обусловлена самой постановкой процесса разработки/отладки/верификации.
Exploratory programming. С некоторой натяжкой сюда можно записать юнит-тесты — единственное средство доступное в майнстриме.
V> Иногда, читая про Smalltalk, мне кажется, что их идеология близка к только что описанной, с той лишь разницей, что там все с упором не на функциональную, а на объектную декомпозицию.
. Имелся в виду вариант со switch
