- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
[Record] variant ItemPatternMatched: PatternMatchedBase, IPatternMatched
_matchByLexemeValue:option[string]
public Match(source:SourceLexemes, namedLinkDictionary:NamedLinkDictionary):MatchResult
match(source)
|[] => MatchResult.EndOfLexemes(source, namedLinkDictionary)
|lexeme_::lexemes_=> def updatedNamedLinkDictionary = updateNamedLinkDictionary(lexeme_::[], namedLinkDictionary);
def failure = MatchResult.Failure(source, namedLinkDictionary);
def success = MatchResult.Success(lexemes_, updatedNamedLinkDictionary);
match(_matchByLexemeValue)
|None | Some(lexemeValue_) when (lexemeValue_==lexeme_._value) =>
match(this, lexeme_._type)
|(Symbol, SourceLexeme.Type.Symbol) | (Identificator, SourceLexeme.Type.Identificator) | (Number, SourceLexeme.Type.Number) =>
success
|_ =>
failure
|_ =>
failure
|Symbol
|Identificator
|Number
Начальник, посмотрев на код, сказал, что NemerleGovno. Я не знаю, что ему ответить?
Follow us!
Фактически тут 3 конструктора:
Symbol|Identificator|Number
Каждый из них имеет один параметр _matchByLexemeValue:option[string], а ещё, хоть в данном случае их нет, но могут быть дополнительные параметры (также как в Scala или Haskell), свойственные конкретному из 3х конструкторов.
Это выглядело бы как-то:
Подозреваю, что не в Scala, не в Haskell такой красотки нет?
А ещё поддерживается наследование ADT от класса или от интерфейса, как мы видим в коде выше.
Такого уж точно нигде нет.
> Такого уж точно нигде нет.
Scala: Haskell
Тк, _matchByLexemeValue содержится во всех конструкторах ItemPatternMatched, то к нему можно обратится без матчинга, например:
def a = ItemPatternMatched.Symbol(None(), 'Y');
А дальше мы обращаемся к a._matchByLexemeValue как к обычному полю структуры и матчить, чтобы вытащить _matchByLexemeValue не нужно. Матчить понадобится только когда c или s или n захочется вытащить. А в Хаскеле в данном случае в любом случае придется матчить, не говоря уж о копипасте (Maybe String) в каждый конструктор и отсутствия именованности полей.
Да. Можно, конечно функцию написать, или определить варианты через синтаксис записей (что лишит нас возможности паттерн-матчинга), но это не так удобно.
С другой стороны, в Haskell есть typeclasses, что гораздо лучше интерфейсов
Здесь соглашусь. Сильнейшая штука. Жаль в Скале typeclasses эмулируют и реализуют только как паттерн-проектирования и в отличии от Хаскеля оно не встроено в язык (приходится многословить).
Внутри все равно матчить придется. О(n) взамен O(1), но согласен, хоть многословно и не расширяемо, но решает.
Что-то мне подсказывает, что O(log n), где n - число конструкторов
А вообще в Хаскеле порядок case of вроде важен.
И подумай над тем, что O(log n) требует Ordering. Хотя... это глупость.
Наглая ложь, минусуйте меня, минусуйте меня полностью! Для записей есть аж два синтаксиса паттерн-матчинга!
Вообще если спросите, то пясню любую хрень.
Кстати, поправил так: [lexeme_]
сохраню и себе полный список статей и видео на тему nemerle
http://liveworkspace.org/
Гип гип Ура! Снова поднялся!
http://85.25.109.216/
http://liveworkspace.org/code/description
1)Поддержка ввода вывода на файловую систему пока до 1 мб.
2)Много языков, в том числе последний хацкел, D, gcc и clang
http://liveworkspace.org/code/requests
- здесь можно оставить просьбу на добавление языков и библиотек, типа буста в язык.
3)ввод\вывод на сокеты
4)параметры командной строки компилятора и программы и ввода пользователя
5)снипеты
6)личный кабинет
7)в перспективе поддержка файлов-проектов
8)инклудинг других исходных кодов в разрабатываемый код
9)форум
>p.s.
>IE не состоит в списке поддерживаемых браузеров. не сообщайте о IE-specific багах.
Не боится, что станет платформой для рассылки спама или запуска эксплойтов?
И это... Нужно сотню акков зарегать, и потом продавать за большие деньги, тк порты скоро закончатся. Там говорит каждому свой выдается.