| Re[62]: Динамические языки и переменные | |
 | От: | Воронков Василий | |
| Дата: | 18.03.10 12:55 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Что-то мне кажется, в юникоде нет понятия "буква". (Кстати, иероглиф — это буква?  А символ катаканы? )T>Я бы ожидал, что всё, что входит в любой алфавит, включая катакану, заматчится на \w. ВВ>>Да и парсер все же не на регекспах  T>Но лексер-то на регекспах? Нет, конечно. А что есть генераторы парсеров, у которых сканеры на регекспах? Регекспы штука небыстрая вообще. T>>>Что-то типа orderby (x, char.Max — y). Я не говорю, что это красиво, но комбинация есть. Может быть в хаскеле есть более удобное средство для сортировки по нескольким ключам, а может и нет. Когда мне надо было отсортировать по нескольким ключам — сортировка по туплу была вполне удобна. ВВ>>Сортировка по туплу тебе не поможет ведь никто же не знает, как именно надо рассматривать элементы твоего тупла — какой первичный, какой вторичный, какой ascending, какой descending и пр. T>Я тебе говорю, что это есть и работает, что я так делал и добивался целей, а ты говоришь, что не получится. T>Во-первых, у туплов есть порядок. T>Во-вторых, всё сортируется в одну сторону. Если какой-то элемент нужно отсортировать в обратном порядке, употребляется патерн Max — x. Вот этот момент уродлив, но это работает. Т.е. все-таки туплы нужны  Особенно, если нет возможности сортировать по нескольким полям.А ведь еще можно вспомнить, что сортировать можно по одному выражению, а выбирать по другому. T>Экономия отнюдь не на длине ключевых слов. В основном, экономия на том, что ты не пишешь типы. T>Про ключевые слова, да есть приятная экономия на их отсутствии, например public, protected, private, static, var, virtual, override, abstract, out, operator, ref, readonly, new, enum, explicit, implicit переименованы в более лаконичное ключевое слово "". T>Остальные ключевые слова если и лаконичнее, то это совершенно незаметно. Я про синтаксис питона, он короче моего просто потому что ключевые слова короче. А общий подход — тот же. Все равно нужны ключевые слова, и общие компоненты выражения совпадают. А ты приводил его как образец лучшего синтаксиса  ВВ>>Ага, тоже решение интересное. Вводим префиксы для переменных. Теперь у нас будут $x, @x и обязательно @@x. ВВ>>Причем знаешь, что самое забавное? Префикс префиксом, но this-то все равно передавать надо T>В Ruby, насколько мне известно, два префикса. Это @foo как сахар к this.foo и :foo синтаксис возвращающий атом (приблизительно const foo = "foo"). Ну и как-то не Perl, нормально с двумя префиксами. Вообще там же есть и "@@" префикс тоже. Хотя уже не помню, зачем он. T>Но ладно, я понял, тебе не нравится. Дело не в том, нравится или нет. Префикс никак не избавляет от необходимости неявно передавать this. Префикс альтернатива самой записи — вместо this.x пишем @x. Лучше это или хуже — неважно, ибо это вообще совсем другой вопрос. this-то все равно нужен, и его надо как-то передавать. Ты привел две альтернативы: 1. Питон. this передается неявно, но при этом указывается в сигнатуре, благодаря чему функция вызывается с одной сигнатурой, а описывается с другой. У меня есть серьезные сомнения в том, что это лучше. К тому же проблема неявной передачи this не решена. 2. Руби. Вместо this используется сигма. Но this все равно передается неявно (а откуда еще ему взяться?). Т.е. ты просто предложил альтернативный синтаксис вместо this. А разговор начинался именно с того, что неявная передача this — это плохо и с ней нужно как-то бороться. Ela 0.9 Dynamic, functional, strict and lazy |