конечно. фактически это в TAPL и написано

А под каким углом нужно читать TAPL, чтобы там что-то подобное вычитать?

никаких элементов в дизайне го, которые способствовали бы написанию более-менее сносного кода нет. го просто (идейно) старый

Там есть отсутствие богатых возможностей и линтер, который по рукам бьёт.

в книжке Харпера другой подход (который дана скотт придумал) излагается, что в "динамических" "языках" тип один

Everything e?

Кто-нибудь уже написал что Erlang это ООП, ибо message passing?

Одмены, спасите от китайского спама, он вернулся.

Кто-нибудь уже написал что Erlang это ООП, ибо message passing?

Армстронг (главный в Эрланге) такое любит говорить

А под каким углом нужно читать TAPL, чтобы там что-то подобное вычитать?

> A type system is a tractable _syntactic_ method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. выделено мной > Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.

Здрасти. А вы пробовали литературу вообще читать какую-нибудь о типизации, о языках программирования?

Тапл почитайте, он начинается с определения типа. Всё-таки логично предоставить определять понятия не абы кому, а соответствующим специалистам

Я даже цитату найду

Там есть отсутствие богатых возможностей и линтер, который по рукам бьёт.

для написания плохого кода богатство возможностей не требуется

http://newstar.rinet.ru/~goga/tapl/tapl003.html#toc1 Система типов — это гибко управляемый синтаксический метод доказательства отсутствия в программе определенных видов поведения при помощи классификации выражений языка по разновидностям вычисляемых ими значений.

> A type system is a tractable _syntactic_ method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. выделено мной > Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.

Неплохо неплохо, а что там динамически чекают? Не соответствие типов ли?

Неплохо неплохо, а что там динамически чекают? Не соответствие типов ли?

тэгов

Иногда слово <<статический>> добавляется явным образом — например, говорят о <<языках программирования со статической типизацией>>, — чтобы отличить тот анализ, который производится при компиляции, и который мы рассматриваем здесь, от динамической (dynamic) илилатентной (latent) типизации в языках вроде Scheme (Sussman and Steele, 1975, Kelsey, Clinger, and Rees, 1998, Dybvig, 1996), в которых теги типов (type tags) используются для различения видов объектов, находящихся в куче. Термин <<динамически типизированный>>, по нашему мнению, неверен (его следовало бы заменить на <<динамически проверяемый>>), но такое употребление уже общепринято. Т.е. Пирс подчёркивает, что "динамическая типизация" это фразеологизм, не оч. связанный с типами собственно

А подскажите кто-нибудь по либе streaming. Мне нужно написать след стрим, типа: retrierStream :: Monad m => (a -> HandleResult) ->Stream (Of a) m () -> Stream (Of a) m () Он работает так: 1. Ждет значение переданного стрима 2. Запускает на нем функию handle 3. Если handle возвращает ok, то он просто делает yield этого значения 4. Если handle возвращает not_ok, то я жду n секунд и ухожу в рекурсию

я так понял что использовать конструкторы из Streaming.Inernal плохо, но как без них это сделать (да и с ними честно говоря) не понимаю

Иногда слово <<статический>> добавляется явным образом — например, говорят о <<языках программирования со статической типизацией>>, — чтобы отличить тот анализ, который производится при компиляции, и который мы рассматриваем здесь, от динамической (dynamic) илилатентной (latent) типизации в языках вроде Scheme (Sussman and Steele, 1975, Kelsey, Clinger, and Rees, 1998, Dybvig, 1996), в которых теги типов (type tags) используются для различения видов объектов, находящихся в куче. Термин <<динамически типизированный>>, по нашему мнению, неверен (его следовало бы заменить на <<динамически проверяемый>>), но такое употребление уже общепринято. Т.е. Пирс подчёркивает, что "динамическая типизация" это фразеологизм, не оч. связанный с типами собственно

легаси термин вроде "электродвижущая сила", которая вовсе не сила

легаси термин вроде "электродвижущая сила", которая вовсе не сила

Норм аналогия

А подскажите кто-нибудь по либе streaming. Мне нужно написать след стрим, типа: retrierStream :: Monad m => (a -> HandleResult) ->Stream (Of a) m () -> Stream (Of a) m () Он работает так: 1. Ждет значение переданного стрима 2. Запускает на нем функию handle 3. Если handle возвращает ok, то он просто делает yield этого значения 4. Если handle возвращает not_ok, то я жду n секунд и ухожу в рекурсию

чтобы ждать, наверняка понадобится IO

ну пусть будет MonadIO, вместо Monad)

в pipes есть await, а как тут? потому что next тебя сразу уводит из стримов

тэгов

Я всё ещё не вижу принципиальной разницы. Т.е. звучит просто так будто хотят на языки с тайпчекерами навесить дополнительный налёт элитарности сказав что "Нет тайпчекера и типов тогда у вас тоже нет". Да типы служат для того, чтобы гарантировать с какой-то точностью корректность валидной программы. Но если в условном Erlang ты пытаешься сложить слона с звездолётом и он тебе выйдёт ошибку о несоответствии типов во время выполнения, то это тоже проверка и тоже гарантия того, что у тебя не будет выполняться откровенная лапша.

А подскажите кто-нибудь по либе streaming. Мне нужно написать след стрим, типа: retrierStream :: Monad m => (a -> HandleResult) ->Stream (Of a) m () -> Stream (Of a) m () Он работает так: 1. Ждет значение переданного стрима 2. Запускает на нем функию handle 3. Если handle возвращает ok, то он просто делает yield этого значения 4. Если handle возвращает not_ok, то я жду n секунд и ухожу в рекурсию

в рекурсию — это с самого начала? брать следующее значение со входа?

Я всё ещё не вижу принципиальной разницы. Т.е. звучит просто так будто хотят на языки с тайпчекерами навесить дополнительный налёт элитарности сказав что "Нет тайпчекера и типов тогда у вас тоже нет". Да типы служат для того, чтобы гарантировать с какой-то точностью корректность валидной программы. Но если в условном Erlang ты пытаешься сложить слона с звездолётом и он тебе выйдёт ошибку о несоответствии типов во время выполнения, то это тоже проверка и тоже гарантия того, что у тебя не будет выполняться откровенная лапша.

вопрос терминологический, разница есть, вот я и называю по-разному. я человек простой, пирс пишет "Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,”" - я заменяю

в pipes есть await, а как тут? потому что next тебя сразу уводит из стримов

боюсь, в стриминге нет втстроенной рекурсии, и именно next надо использовать retrierStream :: MonadIO m => (a -> HandleResult) -> Stream (Of a) m () -> Stream (Of a) m () retrierStream handle input = do e <- lift $ next input case e of Left () -> pure () Right (a, input') -> do case handle a of Ok -> yield a NotOk -> liftIO $ threadDelay $ 2 * 1000 * 1000 retrierStream handle input'

вопрос терминологический, разница есть, вот я и называю по-разному. я человек простой, пирс пишет "Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,”" - я заменяю

Ещё раз. Я полностью согласен с тем, что динамически типизированный это очень странный термин, он непонятный, он легаси и т.д., но чекаются динамически таки типы и более менее пофиг называешь ты их типами или тегами типов(если есть теги типов то логично, что должны быть где-то типы, нет?)

совсем не логично. у АлгТД есть теги конструкторов которые в рантайме чекаются, никакого отношения к типам не имеют, например. точно так же и в скриптах

А подскажите кто-нибудь по либе streaming. Мне нужно написать след стрим, типа: retrierStream :: Monad m => (a -> HandleResult) ->Stream (Of a) m () -> Stream (Of a) m () Он работает так: 1. Ждет значение переданного стрима 2. Запускает на нем функию handle 3. Если handle возвращает ok, то он просто делает yield этого значения 4. Если handle возвращает not_ok, то я жду n секунд и ухожу в рекурсию

Подскажите, где прочитать о (Of a)

Можно обобщить наверное. Интерпретируемый ЯП -- не язык вовсе.

Как дин типы не типы

Можно обобщить наверное. Интерпретируемый ЯП -- не язык вовсе.

Ещё один

Ещё раз. Я полностью согласен с тем, что динамически типизированный это очень странный термин, он непонятный, он легаси и т.д., но чекаются динамически таки типы и более менее пофиг называешь ты их типами или тегами типов(если есть теги типов то логично, что должны быть где-то типы, нет?)

Ну просто странно называть по разному устроенные вещи одним словом, не находите? Даже если обе эти вещи являются аналогом другого понятия из другой предметной области

Стикеры тут не приветствутся, выражайте эмоции буковами

Подскажите, где прочитать о (Of a)

это просто пара строгая слева data Of a b = !a :> b

"Динамические типы" и "Статические типы" только тем общи, что это CS аналоги множества

Но интенсионального, определяемого в рамках CS, единства между ними нет

это просто пара строгая слева data Of a b = !a :> b

? пасиб!!

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

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

Это ведь тип, да? Пытаюсь найти библиотеку..

он в streaming и объявлен

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

Так тупл же не строгий по первому элементу

да это не особо важно, так для удобства сделано

он в streaming и объявлен

http://hackage.haskell.org/package/streaming-0.2.1.0/docs/Data-Functor-Of.html ?

@qnikst, а спор о понятиях, кстати, в этом чате разрешается? По-моему это тема для блах :)

хз

"Динамические типы" и "Статические типы" только тем общи, что это CS аналоги множества

Выглядят одинаково, предназначены для одного и того же, с некоторыми оговорками изоморфны множествам, но при этом СОВЕРШЕННО РАЗНЫЕ ВЕЩИ.

Они устроены по разному

в pipes есть await, а как тут? потому что next тебя сразу уводит из стримов

можно через mapM (если ещё не решено)

Выглядят одинаково, предназначены для одного и того же, с некоторыми оговорками изоморфны множествам, но при этом СОВЕРШЕННО РАЗНЫЕ ВЕЩИ.

Всегда важно не практическая применимость, не внешний вид, а устройство. Иначе бы стоило признать колибри более близкими бабочкам, чем орлам

Ну и множествам ни то, ни другогое не изоморфно. Слава проблеме останова

@beizero может возьмешь тайм-аут на перечитывание первых двух глав пирса?

а то как-то по кругу пошло, тем более ты попросил определение, тебе привели, а ты дальше говоришь "как ты видишь", и хочешь чтобы согласились? и все по кругу идет

(я может конечно не внимательно прочитал, что выше было)

чот я токсичный сегодня

Они устроены по разному

У Пирса к слову, определение системы типов даётся по предназначению, а не по устройству. Из устройства там только говориться о том, что это синтаксический способ, но даже в том же JS ты объекты разных типов(или называйте это как хотите) синтаксические описываете по разному. Я из Haskell могу выкинуть декларацию типов у функций и оставить только определения их поведения, а компилятор мне всё выведет, код будет выглядеть так будто у меня типов вообще нигде нет от этого они в общем-то никуда не денутся.

чот я токсичный сегодня

По моему, не только сегодня

А вообще спать надо

нет, я всегда добрый и пушистый, даже сегодня

хз

а мог бы и бритвой полосонуть

так что да, добрый

нет, я всегда добрый и пушистый, даже сегодня

Не бреешься?

ERROR: S client not available

У Пирса к слову, определение системы типов даётся по предназначению, а не по устройству. Из устройства там только говориться о том, что это синтаксический способ, но даже в том же JS ты объекты разных типов(или называйте это как хотите) синтаксические описываете по разному. Я из Haskell могу выкинуть декларацию типов у функций и оставить только определения их поведения, а компилятор мне всё выведет, код будет выглядеть так будто у меня типов вообще нигде нет от этого они в общем-то никуда не денутся.

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

Не бреешься?

а то, уже лет 10(?)

D:

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

Why? Если у меня не JS или что настолько же типобезумное, то язык всё ещё даёт гарантии того, что не будет исполнять бред, что и является предназначением системы типов, нет? Про то, что всё должно чекаться во время компиляции в определении даже у Пирса нет.

язык не даёт гарантии что твоя программа, которая хочет делать бред - будет принята

типы в js это flow и вот это все

а не то, что внутри самого js

точно так же если бы в Haskell была только одна ADT: data Q = I Int | T Text ...

то ты бы мог написать: plus (I i) (I j) = I (I+j) plus _ _ = error "bad tags"

это бы не были типы, а была бы проверка тегов

тоже самое происходит в динамических языках

причем нельзя сказать что это ПЛОХО, это просто есть

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

так ты можешь в рантайме гарантировано узнать теги типов и в зависимости от тегов выполнить или сгенерировать определенный код

причем мощность тегов может быть достаточно большой

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

механизм достаточно мощный, переизобретать который типами может быть сложно

это бы не были типы, а была бы проверка тегов

ADT по определению это сумма типов произведений. I Int, T Text, I, T таки будут являться типами по определнию ADT, насколько сильно это бы не ломало гарантии корретности программы написанной в таком стиле.

типами по определению ADT?! WUT?

какому к черту определению?!

давай ты уже тоже ссылками на статьи и книги общаться будешь?

ADT это тип равный сумме типов-произведений, разве нет?

у нас есть Q - конструктор типа и I, T - конструкторы данных

промоушн немного ломает эту аккуратную вещь, но можно его игнорировать пока

так I :: Int -> Q, принимает параметр типа Int и создаёт данные типа Q

типа I нигде нету

это тег который говорит как из типа суммы получить проекцию на одно из слагаемых

типа I нигде нету

Ок. Тут я прогнал, I не тип.

для лучшего понимания пирса наверное подойдёт пример js и flow

для Erlang тоже же был какой-то линтер, который пытался типы притащить