Re[12]: [Голосование] Почему я не использую Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 12.04.10 16:14
Оценка: 26 (2)
Здравствуйте, Mr.Cat, Вы писали:

MC>Зато удобная. И тот же питон тильды умеет разворачивать.

MC>В общем объяснять отсутствие фичи тем, что это типа чужой и нестандартный функционал — несерьезно. Лучше уж честно признаться что лень/нет денег/...

Я, как обычно, перестарался и реализовал чуть больше, чем было надо. Поэтому оно не только разворачивает тильду, но и также имена спец.папок и переменные окружения:

namespace Nemerle.IO
{
    public macro PathExpander(path)
    syntax ("~", path)
    {
        <[
            def getEnvironmentVariable(name) {Environment.GetEnvironmentVariable(name) ?? throw Exception($"Environment variable $name is not defined")}
            
            match ($[x | x in $path.Split(IO.Path.DirectorySeparatorChar)])
            {
                | headNode :: tailNodes =>
                    ((regexp match (headNode)
                    {
                        | @"^~$"          => Environment.GetEnvironmentVariable("USERPROFILE")
                        | @"^#(?<sf>.*)#" => Environment.GetFolderPath(Enum.Parse(typeof(Environment.SpecialFolder), sf, false) :> Environment.SpecialFolder)
                        | @"^%(?<ev>.*)%" => getEnvironmentVariable(ev)
                        | _               => if (!IO.Path.IsPathRooted(headNode)) IO.Path.Combine(IO.Directory.GetCurrentDirectory(), headNode) else $"$(headNode)$(Path.DirectorySeparatorChar)"
                    }) :: tailNodes).Fold(headNode, fun(node, path)
                    {
                        IO.Path.Combine(path,
                            regexp match(node) 
                            {
                                | @"^%(?<ev>.*)%" => getEnvironmentVariable(ev)
                                | _ => node
                            }
                        )
                    })
            }
        ]>
    }
}


Использование:

WriteLine(~"Nemerle.dll");
WriteLine(~(@"~\Links\desktop.lnk"));
WriteLine(~"#ProgramFiles#\\Nemerle\\docs");
WriteLine(~"%SystemRoot%\\System32\\drivers\\etc\\hosts"));
WriteLine(~"C:\\Temp\\%PROCESSOR_ARCHITECTURE%");
def path = @"~\desktop.ini";
WriteLine(~path);


Результат:

C:\Users\VKochetkov\Documents\Visual Studio 2008\Projects\PathExpansion\PathExpander\bin\Debug\Nemerle.dll
C:\Users\VKochetkov\Links\desktop.lnk
C:\Program Files\Nemerle\docs
C:\Windows\System32\drivers\etc\hosts
C:\Temp\x86
C:\Users\VKochetkov\desktop.ini


Я хз, как оно будет работать под линуксом (подозреваю, что нужно допиливать, с учетом особенности реализации в Mono членов Environment), но сам макрос занял у меня от силы час, да и то, потому что только-только осваиваю язык
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[13]: [Голосование] Почему я не использую Nemerle
От: WolfHound  
Дата: 12.04.10 16:25
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Я, как обычно, перестарался и реализовал чуть больше, чем было надо. Поэтому оно не только разворачивает тильду, но и также имена спец.папок и переменные окружения:

А зачем тут макрос?
ИМХО просто функции достаточно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: [Голосование] Почему я не использую Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 12.04.10 16:26
Оценка: :))
Здравствуйте, WolfHound, Вы писали:

WH>А зачем тут макрос?

WH>ИМХО просто функции достаточно.

Уж очень хотелось куда-нибудь в синтаксис тильду воткнуть

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[11]: [Голосование] Почему я не использую Nemerle
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 12.04.10 17:30
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я ведь сказал посмотреть в сторону библиотек Хаскеля — они представляют из себя предобработанный исходник, а не бинарник (сравни с либами того же дотнета).


У меня нет дотнета. Что ты понимаешь под библиотекой? hi-файл? Или объектник?

L>>Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi.

V>Мде... Вообще-то именно порождается функция для конкретного параметра a.

С чего ты это взял? List имеет kind * -> *, т.е. принимает только боксовые значения, ну и сам является боксовым само собой. Размер у него всегда будет один. Зачем генерить, скажем, для map кучу реализаций, если достаточно одной?

L>>В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера.

V>Инстанциирование типов из шаблонов C++ тоже ничего не генерит, кроме случаев явного указания такой генерации. Код генерится в месте использования шаблона.

По барабану. В Haskell при использовании map f [1,2,3] и map f "abc" не будет сгенерено двух новых функций. Оптимизатор, конечно, может это сделать, или мы с помощью SPECIALIZE, но это необязательная вещь (в ghci, о котором мы говорим, оптимизатор отключён).

L>>Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код?

V>Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.

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

L>>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.

V>Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...

Да я кроме GHC ни с чем и не работаю. Так что кроме Hugs больше сказать ничего не могу, да и не уверен, что есть. Однако я не вижу причин, почему это сделать невозможно. В любом случае отсутствие никак не подтверждает твоего утверждения о наличии шаблонов в Haskell.

V>>>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался.

L>>Что такое "представление библиотек Хаскеля"?
V>Ну открой их каким-нить текстовым редактором да посмотри.

Кого их? Ты про hi? Или про объектники? Открыл все, ничего полезного не увидел. Ткни пальцем, зачем загадками говоришь

На всякий случай — unboxed values нельзя использовать как применение полиморфного типа в функциях. Это чтобы разговор в сторону не уходил
Re[13]: [Голосование] Почему я не использую Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 17:34
Оценка: 14 (1)
Здравствуйте, kochetkov.vladimir, Вы писали:

Небольшой совет. Генерировать исключения из макросов — это плохой подход.
Вмест этого нужно использовать методы Message.Error() или Message.FatalError().
Последний генерирует специальное исключение перехватываемое в коде раскрытия макроса.
Message.FatalError можно применять так же как ислючение в твоем коде.
Ну, и вообще не стоит нигде и никогда генерировать исключение типа Exception. Это верный путь к проблемам.

KV>[c#]

KV> <[
KV> def getEnvironmentVariable(name) {Environment.GetEnvironmentVariable(name) ?? throw Exception($"Environment variable $name is not defined")}
KV>[/code]
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Голосование] Почему я не использую Nemerle
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 12.04.10 18:24
Оценка:
Здравствуйте, nikov, Вы писали:

N>Сколько вариантов бинарного кода порождается для такой функции (как должен считать я, как программист) ?

N>
N>foo :: a -> b
N>foo x = foo [x]
N>


Можно представить реализацию, где будет порождено столько вариантов, сколько есть разных типов в вызовах этой функции. Я так делал в одном своем компиляторе.
Re[12]: [Голосование] Почему я не использую Nemerle
От: vdimas Россия  
Дата: 12.04.10 18:28
Оценка:
Здравствуйте, nikov, Вы писали:

N>Сколько вариантов бинарного кода порождается для такой функции (как должен считать я, как программист) ?

N>
N>foo :: a -> b
N>foo x = foo [x]
N>


Не смеши. Вот тебе аналогичный вопрос: сколько вариантов бинарного кода порождается в рантайм для такого класса (C#):
class A<T> {
    public A<T> Value { get; set}
}

И почему я не могу заменить 'class' на 'struct' в своем примере?

Ответ на твой вопрос, как и на мой, зависит исключительно от реализации, т.е. никого не интересует.
Re[9]: [Голосование] Почему я не использую Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 20:56
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>

ANS>Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.

ANS>Десятое правило Гринспена

Вывод компилятор Common Lisp и любая достаточно сложная программа написанная на Common Lisp — это неспецифицированная, глючная и медленная реализация половины языка Common Lisp.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Голосование] Почему я не использую Nemerle
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.04.10 05:55
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ответ на твой вопрос, как и на мой, зависит исключительно от реализации, т.е. никого не интересует.


?!?! А я думал мы говорим конкретно о GHCi.
Re[14]: [Голосование] Почему я не использую Nemerle
От: vdimas Россия  
Дата: 13.04.10 12:11
Оценка:
Здравствуйте, lomeo, Вы писали:

V>>Ответ на твой вопрос, как и на мой, зависит исключительно от реализации, т.е. никого не интересует.


L>?!?! А я думал мы говорим конкретно о GHCi.


Даже в нем, в режиме оптимизации, насколько я знаю, он порождает отдельные реализации ф-ий для нерекурсивных типов, т.е. типов-аналогов value-type из дотнета. Понятное дело, что все указатели совместимы по размеру, поэтому физически для боксированных типов может и быть одна реализация. Тоже самое происходит и в С++ при компиляции шаблонов (бинарно-эквивалентные реализации "схлопываются" в одну в процессе оптимизации), но, повторюсь, это подробности реализации и оптимизации бинарного представления. Ты же каждый раз должен считать, что работаешь с конкретно порожденной для данного набора типов-параметров реализацией, особенно при наличии явной специализации обобщенных ф-ий (как и в С++).
Re[14]: [Голосование] Почему я не использую Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 13.04.10 13:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kochetkov.vladimir, Вы писали:


VD>Небольшой совет. Генерировать исключения из макросов — это плохой подход.


Дык там же из макроса генерится не исключение, а код, кидающий исключение в рантайме?

VD>Вмест этого нужно использовать методы Message.Error() или Message.FatalError().

VD>Последний генерирует специальное исключение перехватываемое в коде раскрытия макроса.
VD>Message.FatalError можно применять так же как ислючение в твоем коде.
VD>Ну, и вообще не стоит нигде и никогда генерировать исключение типа Exception. Это верный путь к проблемам.

Угу Поленился свой класс исключения сделать
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[15]: [Голосование] Почему я не использую Nemerle
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.04.10 14:23
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты же каждый раз должен считать, что работаешь с конкретно порожденной для данного набора типов-параметров реализацией, особенно при наличии явной специализации обобщенных ф-ий (как и в С++).


Ты так и не ответил, почему я должен так считать

И насчёт "представления библиотек Haskell" — пни меня в нужном направлении, я честно не нашёл там то, о чём ты говоришь.
Re[15]: [Голосование] Почему я не использую Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 01:12
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Дык там же из макроса генерится не исключение, а код, кидающий исключение в рантайме?


А, тогда не понял. Приношу свои извенения.

KV>Угу Поленился свой класс исключения сделать


Ну, хотя бы тогда какой-нить АпликэшонЭксцешон, что ли... А то ведь вообще отловить нельзя будет. Да и объявление класса — это же две строки если с использованием атрибута Recor.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [Голосование] Почему я не использую Nemerle
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 19.04.10 12:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>С целью сбора информации прошу ответить на вопрос:

VD>

VD>Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?

VD>В следующем голосовании:
VD>http://rsdn.ru/poll/2558.aspx
Автор: VladD2
Дата: 05.04.10
Вопрос: Почему я боюсь/не хочу/не могу использовать Nemerle в своей работе?


потому-что я использую F#
Re[2]: [Голосование] Почему я не использую Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.10 14:30
Оценка: -1
Здравствуйте, Lazin, Вы писали:

L>потому-что я использую F#


Уважаемый, для этого есть пунк в голосовании. Не нужно засорять форум бессмысленными сообщениями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Голосование] Почему я не использую Nemerle
От: Lazin Россия http://evgeny-lazin.blogspot.com
Дата: 30.04.10 16:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


L>>потому-что я использую F#


VD>Уважаемый, для этого есть пунк в голосовании. Не нужно засорять форум бессмысленными сообщениями.


Могу ответить и по существу. Самое слабое место, на мой взгляд — вовсе не в фичах языка и не в реализации, а в том, что убедить начальство в разумности этого шага — крайне сложно
В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература. Это все отличные аргументы для не программистов. Nemerle, на данный момент, этим не может похвастаться. Все остальное, по сути — мелочи.
Re[4]: [Голосование] Почему я не использую Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.10 17:48
Оценка: -2
Здравствуйте, Lazin, Вы писали:

L>В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература.


Что за примеры?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Голосование] Почему я не использую Nemerle
От: nikov США http://www.linkedin.com/in/nikov
Дата: 30.04.10 17:57
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>В случае F# — все просто, есть примеры использования, положительные отзывы, известный вендор, литература.


VD>Что за примеры?


Здесь, раздел Industrial applications
Почему я не использую косметику Mary Key?
От: minorlogic Украина  
Дата: 30.04.10 19:48
Оценка: :)
С целью сбора информации прошу ответить на вопрос:

Почему я боюсь/не хочу/не могу использовать косметику Mary Key в своей работе?

Отвечайте без стеснения, не бойтесь, откройте душу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Почему я не использую косметику Mary Key?
От: l33thaxor  
Дата: 01.05.10 00:31
Оценка: :)
Здравствуйте, minorlogic, Вы писали:

M>С целью сбора информации прошу ответить на вопрос:


M>Почему я боюсь/не хочу/не могу использовать косметику Mary Key в своей работе?


Mary Kay — польская кустарщина. Я пользую только C#vergirl.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.