shai_xylyd Jan 26 2009 at 20:32

Вычисление выражений на Nemerle и Mono.

2 min

1.5K

Programming*

+19

Comments 15

veitmen Jan 26 2009 at 20:45

Ох как красиво! Ну все, с выходных ищу время для «вкуривания» MONO.
Или все таки ждать C#4.0 — 5.0?

shai_xylyd Jan 26 2009 at 20:59

Если целевая платформа у вас .net, то имеет смысл использовать nemerle. А у моно сейчас есть проблемы, например, в сборке под windows nunit 2.4.8 падает с ошибками.

veitmen Jan 26 2009 at 21:01

Спасибо, приму к сведению. Просто у nemerle меня как то синтаксис смутил… :-(

alex_blank Jan 26 2009 at 21:04

там хороший синтаксис, в традициях ФП :)

а то всякие форки C (C++, Java) к дурному приучили…

pieceofsummer Jan 26 2009 at 22:03

А в шарпе это DynamicExpression.ParseLambda() :)

Thecentury Jan 26 2009 at 23:55

Что-то я не нашел такого. Это откуда? Какая версия C#? Какая сборка?
Или же это пока еще мечты? )

pieceofsummer Jan 26 2009 at 23:57

Это отсюда:
code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=csharpsamples&ReleaseId=8
LinqSamples\DynamicQuery

gaploid Jan 26 2009 at 23:39

привет javascript, flash и expression injection=)

darkk Jan 27 2009 at 02:00

Присоединяюсь к вопросу — создается впечатление, будто бы eval в C# не такое уж и абсолютное зло.
Мне кажется, если безопасность/надежность какая-либо нужна, то лучше всё-таки хотя бы проконтролировать формальной грамматикой выражение перед eval-ом (тогда не надо писать полноценный «интерпретатор» выражения).

shai_xylyd Jan 27 2009 at 11:05

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

pieceofsummer Jan 27 2009 at 11:50

По-хорошему, динамический код вообще можно грузить в отдельный AppDomain с ограниченным доступом куда-либо.

xonix Jan 27 2009 at 00:07

ну это не интересно, так и на питоне нетрудно

>>> add5 = eval('lambda a: a+5')
>>> add5(2)
7

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

Проблема такого подхода — мы завязаны на синтаксисе конкретного языка => не гибко

xonix Jan 27 2009 at 00:16

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

elw00d Jan 27 2009 at 22:21

Спасибо за интересный способ, позволяет несколько по-новому взглянуть на наш инструментарий ) Однако классические алгоритмы и умение их применять никто не отменял ) Тем более, если своя реализация может обеспечить более гибкий механизм для контроля каждой стадии анализа / вычисления. К примеру, в собственном парсере-велосипеде можно рулить как выражением в целом, так и отдельными его частями (например, оптимизировать выражение за счет предвычисления констант). В общем, проблема выбора между своей собственной разработкой и использованием готовых решений как всегда актуальна.

shai_xylyd Jan 27 2009 at 23:58

Это точно, но на некотором классе задач такой подход будет предпочтительней, например, на лабах по численным методам, при генерации кода на лету, etc…

Show the best of all time