так же и регулярки и тд и тп

Text в твоем Path - не тип

кароч, кто-то хочет перегрузку по типу в языке, где её нет (к счастью)

override это адище) ещё и женерики

и если я сумирую типы, то эти конструкторы никуда не деваются, так?

нельзя матчить по конструкторам разных типов. Только через суппу этих типов

data Path = Text2 | Route2 - это РОВНО то же самое, что ты писал выше

и если я сумирую типы, то эти конструкторы никуда не деваются, так?

они будут внутри констукторов суммы

я не могу сумировать чужие типы?

можно, но нужна метка

ахмлять

почитай в вики про помеченую сумму множеств

Either Text Regexp - сумма чужих типов

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

я не могу сумировать чужие типы?

Оберни чужие типы в свои конструкторы и проссумируй. Получишь свой тип - сумму чужих. На этом типе объяви функцию. Всё.

data Path = Text Text | Route Route Text «123» :: Path - это значение Text с меткой Text, имеет тип Path

Так человеку хочется сумму без оборачивания в тип!

У нас в хаскеле такого нет

Так человеку хочется сумму без оборачивания в тип!

А, нее. :)

ух, мак еще и ковычки меняет, ужасно

f :: Text | Regex -> foo у нас нельзя

возможно, с flow пришел, там есть сумма множеств

больше я такого нигде не видел)

Ну, мы можем объявить тайпкласс. Но думаю выше предлагали

Предлагали

Даже семейки предлагали и прочие зависимости

Что с тайпклассом не так? :) Оно и будет. Полиморфная функция.

Не тратьте на него время, просто пусть осознает изоморфизмы в множестве и если не тупой, то больше не задаст таких вопросов

Что с тайпклассом не так? :) Оно и будет. Полиморфная функция.

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

Получится. Через RankNTypes

Ну меставми подхачить можно, канешн :)

data Path = Text Text | Route Route Text «123» :: Path - это значение Text с меткой Text, имеет тип Path

ок, щас так и сделаю

хотя выглядит как "масло масленое"

Конструкторы живут не в том неймспейсе, в котором живут типы, поэтому одно и то же имя у типа и у конструктора - это две большие разницы

на instance Match Route Path where p =~ t @ Text = t == p p =~ r @ Regexp = rmatch r p компилятор ругается как-то иначе)

просто мимо проходя хотел сказать что как мне кажется операторы в тайпклассах - плохо ящитаю лучше как в пурсовых стандартных либах, в тайпклассах функции с нормальными ascii-именами, а уже дальше для них можно прикрутить инфиксные алиасы

data Path = Text Text -- ^конструктор ^тип-параметр

просто мимо проходя хотел сказать что как мне кажется операторы в тайпклассах - плохо ящитаю лучше как в пурсовых стандартных либах, в тайпклассах функции с нормальными ascii-именами, а уже дальше для них можно прикрутить инфиксные алиасы

в этом что-то есть, так что соглашусь

первый Text может иметь любое имя

Not in scope: type constructor or class ‘Regex’ A data constructor of that name is in scope; did you mean DataKinds? Perhaps you meant ‘Regex.Regex’ (imported from Text.Regex.TDFA) | 19 | data Path = Text Text | Regex Regex deriving (Eq)

щас стол переверну

и как бы всё понятно и он прав, но какже зае

Какой тип у регулярок, кторые у вас используются?

Вот он то и будет параметром у конструктора Regex ваш_тип

Грубо говоря data ChiselkaIliStroka = Chiselka Int | Stroka String понятно, что Int и String долны быть известными типами

Вам сказали Regexp Regexp, полагая (из вашего же кода), что у вас где-то импортируется тип Regexp. Но это не так, судя по тому, что сообщает компилятор

Все эти тайпклассы лишь рекорды) почитайте Киселева

Как в кубике ща

> операторы в тайпклассах - плохо иногда бывает сложно придумать имя, вот и городят "загогулины" :) Проблема нейминга же

> операторы в тайпклассах - плохо иногда бывает сложно придумать имя, вот и городят "загогулины" :) Проблема нейминга же

с одной стороны да, с другой потом проще читать, ну если это не что-то совсем тривиальное типа == в Eq

lensUpdateStatefullyWithFunctionIfItImplementsMonoid

"Проще читать" :)

У линзооператоров есть неплохая мнемоника, так что это, наверное, плохой пример :)

&&& похуже в этом плане, ибо поабстрактнее

&&& похуже в этом плане, ибо поабстрактнее

я вот понятия не имею что это если честно

Так человеку хочется сумму без оборачивания в тип!

Чувак хочет юнион тайпы же, это что-то из области субтайпинга жеж

Вон я в эльмолибе с комбинаторами за немением тайпклассов и сл-но с невозможностью использовать Monoid замучился имена придумывать для пятка мономорфных mappend

я вот понятия не имею что это если честно

Это оператор из Control.Arrow

С абсолютно неговорящим названием :)

Это оператор из Control.Arrow

я уже захуглил (хех, забавное слово), да

Вон я в эльмолибе с комбинаторами за немением тайпклассов и сл-но с невозможностью использовать Monoid замучился имена придумывать для пятка мономорфных mappend

вооооооооот

я вот понятия не имею что это если честно

juxt для пары стрелок

вооооооооот

о чём я и говорю, без тайпклассов вообще уныло

правда, juxt мне говорит даже меньше, чем &&&

о чём я и говорю, без тайпклассов вообще уныло

я бы даже обменял возможность объявлять свои чисто-символьные операторы на тайпклассы!

Инфиксную форму записи a `foo` b там уже убрали. Без операторов И без тайпклассов жизнь будет вообще унылой...

там это в элме?

д

когда я последний раз на него смотрел там во всех примерах использовалась такая инфиксная запись..

ну шо, ещё пара лет, и из элма выпилят дженерики и haskell/ml-like синтаксис, и элм превратится в го

Там принято returnMaybe |> Maybe.andThen foo |> Maybe.andThen bar

В принципе это не натолько плохо. Но часто то, что выглядело бы сильно компактнее при хаскелевом синтаксисе, там выражается более громоздко. Зато единообразно

juxt для пары стрелок

Это вообще с кложуры оператор

Юкстапозиция - вполне себе "неизкложурный" термин

Там принято returnMaybe |> Maybe.andThen foo |> Maybe.andThen bar

ну не то чтобы это плохо, но все равно не понимаю зачем выпиливать инфиксный вариант что-то похожее на хаскелевскую инфиксную запись же даже во всяких более-менее мейнстримных языках впиливают типа скалы или котлина (емнип) в руби вроде тоже что-то похожее то есть это даже не какая-то такая задротская фича хаскеля

Они хотят "меньше синтаксиса". И любят пайпинг. Поэтому стремятся всё делать через него

Котлин достаточно годный

Котлин достаточно годный

Поддерживаю

Котлин достаточно годный

Он то тут причем? :) Или это наброс/попытка сменить тему? :)

Котлин достаточно годный

я как-то ни скалу ни котлин толком не пробовал, только простенькую аппу под андроид на котлине пробовал писать, но если бы мне нужно было выбрать язык под JVM, я бы наверное всё-таки выбрал скалу, там хкт, какие-то вроде даже зайчатки завтипов, в общем поинтереснее чем в котлине как мне кажется

в пурсе ещё и foo `bar baz qux` doo писать можно и вот это мне не очень нравится