языковой дизайн: неявные преобразования при сравнении двух значений - PullRequest
Новая
       36

языковой дизайн: неявные преобразования при сравнении двух значений

2 голосов
/ 03 февраля 2012

Вместе с другом мы создаем новый язык под названием Simp. Это должен быть простой, но современный язык сценариев с приятным и интуитивно понятным синтаксисом. Вот краткий пример: 

var sum = 0
for i in 3..999 {
    if (i % 3 == 0) or (i % 5 == 0) {
         sum += i
    }
}
say sum

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

# 1.
say (1 == '1')

# 2.
var x = 1
switch (x) {
    case '1': say true; break;
    case 1: say false; break;
}

# 3.
if ('1') say true;
else say false;

Если 1. выводит true, возможно, нам следует также включить оператор ===, который также проверяет типы. Но я не большой поклонник этого оператора.

Если выдается ошибка, поскольку сравниваются два разных типа, это нормально. Немного больше ввода (1 == int('1')) решает проблему и делает код более понятным. Но как в таком случае вести себя для 2. и 3.?

Какое решение вы рекомендуете?

1 Ответ

2 голосов
/ 03 февраля 2012

Очень субъективно.Если бы все на этом сайте ответили на этот вопрос, каждый ответ был бы другим.Зависит от того, что вы хотите.Похоже, вы создаете новый язык в качестве учебного опыта, а не решаете какую-то проблему с существующими языками.Ничего плохого в этом нет, но вы столкнетесь с этим "как вы думаете, это должно означать?"Это большая проблема, если вы не ставите перед собой какую-то цель.

Пол Грэм отстаивает философию, что лучший дизайн - это дизайн для себя.Язык программирования C был популярен, потому что изобретатели сначала разработали его для себя, а не для других.Между прочим, это сделало его популярным среди других.С другой стороны, COBOL был разработан комитетом, чтобы непрограммисты могли его понять, а программисты могли его использовать.В конце концов, непрограммисты все еще не могли прочитать его, а программисты ненавидели его.

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

В этом конкретном примере вы говорите, что неткак оператор ===.Тогда не включайте его.

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

...