LINUX.ORG.RU

[Scheme] Если бы Scheme можно было сделать заново, что бы вы изменили?

 


0

2

Хотелось бы увидеть какие-нибудь статьи на тему сабжа или около. Что-то не гуглится.

Впрочем мнение ЛОРа я тоже не прочь услышать.

Говоря «изменить» я имею ввиду: возможности макросов, введение каких-то дополнительных сущностей (например пространства имён) или наоборот, урезания возможностей (например, дабы уменьшить кол-во ошибок).

Разумеется, в стандартном Scheme до r6rs не было нормальных модулей (Кстати, нормальные в вашем понимании — это какие?), это учитывается.

Наверное неплохо бы ввести необязательную статическую типизацию — нет?

★★

Последнее исправление: vladimir-vg (всего исправлений: 1)

Стандартизированное ООП

anonymous
()
Ответ на: комментарий от Nakgidveef

> Да, прошлая Лисп-тема заглохла, надо новую начать.

На странице текущих тредов я не вижу ни одной лисп-темы, кроме этой.

Впрочем, разве есть что-то плохое в лисп-темах? Для ЛОРа это нормальное явление.

Стандартизированное ООП

А-ля CLOS?

vladimir-vg ★★
() автор топика

посмотрите в сторону racket/plt-scheme - там много есть, чего нет в стандарте

а так, хорошим примером является унифицированное api для работы с последовательностями, как это сделали в кложуре

ott ★★★★★
()

Ничего. Иначе это будет уже другой язык.

quasimoto ★★★★
()
Ответ на: комментарий от vladimir-vg

>А-ля CLOS?

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

anonymous
()

> осмотрите в сторону racket/plt-scheme - там много есть, чего нет в стандарте

Ок.

Ничего. Иначе это будет уже другой язык.

Другой и нужно.

Говоря, сделать Scheme заново, я имею ввиду такой язык, который будет такой же аккуратный, удобный и гибкий как Scheme.

лишь бы оно было адекватным и стандартным

Ок.

vladimir-vg ★★
() автор топика
Ответ на: комментарий от vladimir-vg

Говоря, сделать Scheme заново, я имею ввиду такой язык, который будет такой же аккуратный, удобный и гибкий как Scheme.

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

Кстати, насчёт Scheme и её разделения на «большую» и «малую» - http://www.linux.org.ru/news/doc/3978571. В том же racket даже статическая типизация есть с выводом типов (такой поддиалект языка).

quasimoto ★★★★
()

ничего. некоторые вещи в сравнении с CL чуть-чуть не нравятся, но они не завязаны на язык => можно и так сделать по-своему. единственно — раздельная статичная компиляция в отличие от CL'ной инкрементальной некоторые неудобство доставляет в написании макр, но думаю на то есть причины

korvin_ ★★★★★
()
Ответ на: комментарий от quasimoto

> Кстати, насчёт Scheme и её разделения на «большую» и «малую» - http://www.linux.org.ru/news/doc/3978571. В том же racket даже статическая типизация есть с выводом типов (такой поддиалект языка).

в racket даже аналог CLOS есть с некоторой поправкой на Scheme'овость =)

korvin_ ★★★★★
()

Наверное неплохо бы ввести необязательную статическую типизацию — нет?

Или контракты (см. в Racket). Они ближе к исходной Scheme, чем статическая типизация.

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

> Или контракты (см. в Racket). Они ближе к исходной Scheme, чем статическая типизация.

согласен, в «большой scheme» они были бы полезны

korvin_ ★★★★★
()

Я бы сделал CL.
А вообще, Scheme идеален для той цели, для которой он создавался - обучение. А когда идет навешивание костылей для применения где-то вне этой области(ну как в PLT том же, например), получается говно. В этом случае уже нужен другой лисп, типа, опять же, CL.

Ну еще, но это не совсем про схему - круто было бы иметь лисп для низкоуровневой разработки(т.е. достаточно низкоуровневый язык, с ассемблерными вставками, стандартизированным ABI, и в то же время еще лисп, с макросами, gc, etc., но без громадной стандартной библиотеки).

Love5an
()
Ответ на: комментарий от Love5an

> А вообще, Scheme идеален для той цели, для которой он создавался - обучение.

ну надо же, а Guy L. Steele и Gerald Jay Sussman думали, что для исследования Actor model...

atiyakkha
()
Ответ на: комментарий от atiyakkha

ну надо же, а Guy L. Steele и Gerald Jay Sussman думали, что для исследования Actor model...

Love5an'у лучше знать

Begemoth ★★★★★
()
Ответ на: комментарий от atiyakkha

Чо там осиливать то?

Не нужны потому, что как минимум препятствуют адекватной реализации действительно полезных вещей(unwind-protect).

Love5an
()
Ответ на: комментарий от Love5an

> Не нужны потому, что как минимум препятствуют адекватной реализации действительно полезных вещей(unwind-protect).

можно подробней? а то ты так говоришь, как буд-то Схема без unwind-protect просто жить не может

Ну еще, но это не совсем про схему - круто было бы иметь лисп для низкоуровневой разработки

http://losak.sourceforge.net/ не?

korvin_ ★★★★★
()
Ответ на: комментарий от vladimir-vg

>> Стандартизированное ООП

А-ля CLOS?

Я конечно далек от Scheme, но может TinyCLOS?

antares0 ★★★★
()
Ответ на: комментарий от Love5an

Ну и еще - continuations не нужны.

Вот еще! Иногда они незаменимы.

dave ★★★★★
()
Ответ на: комментарий от quasimoto

> В том же racket даже статическая типизация есть с выводом типов (такой поддиалект языка).

А этот поддиалект еще живой? Просто когда листал мануал по нему, то сложилось впечетление что это диалект для какой то очень старой весии racket-а. А в новом racket почти все из этого в коробке.

antares0 ★★★★
()
Ответ на: комментарий от Love5an

> Я бы сделал CL.

Ну так racket это оно и есть, с поправкой на scheme.

antares0 ★★★★
()
Ответ на: комментарий от korvin_

> можно подробней? а то ты так говоришь, как буд-то Схема без unwind-protect просто жить не может

А что в ней вместо unwind-protect?

Вот подробнее. Но за отсутствем времени так и не прочитал.

http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-origin al.html

http://www.ccs.neu.edu/home/dorai/uwcallcc.may.15/uwcallcc.html

http://repository.readscheme.org/ftp/papers/sw2003/Unwind.pdf

antares0 ★★★★
()
Ответ на: комментарий от antares0

А этот поддиалект еще живой? Просто когда листал мануал по нему, то сложилось впечетление что это диалект для какой то очень старой весии racket-а. А в новом racket почти все из этого в коробке.

Я не очень за этим слежу - мне интересен сам факт (то как они это сделали - но как они сделали я так и не дознался, так как большая часть исходников на Си - неинтересно копаться :). В документации по-прежнему стоят директивы:

#lang typed/racket

и

#lang typed/racket #:optimize
quasimoto ★★★★
()
Ответ на: комментарий от korvin_

Продолжения «не нужны» просто потому что их никто не сделал - есть cl-cont, но там неполноценные продолжения (как раз без поддержки некоторых вещей, вроде unwind-protect) т.к. это просто библиотека - для натуральных продолжений нужна поддержка в runtime. Так что всё как и с MP: было бы реализовано полноценно - было бы тогда и нужно.

quasimoto ★★★★
()

> не очень за этим слежу - мне интересен сам факт

Вот то-то и оно. У меня создается что все попугайски повторяют, но никтоне пользуется.

antares0 ★★★★
()
Ответ на: комментарий от quasimoto

> Так что всё как и с MP: было бы реализовано полноценно - было бы тогда и нужно.

МП - это что?

Если MOP то вроде ж реализовано и с помощью closer-mop почти унифицировано.

antares0 ★★★★
()
Ответ на: комментарий от Begemoth

>> А что в ней вместо unwind-protect?

dynamic-wind

Оно, насколько я понимаю,выполняет before и after на каждый вход и выход в окружение. Что применительно к файлам - странно и стремно.

Опять же насколько я понимаю если выолнение вылетит с ошибкой то выполнение after стадартом не гарантируется. Впрочем в racket этот момент учли и пол-опроблемы решили.

antares0 ★★★★
()
Ответ на: комментарий от antares0

Вобще применение продожений в scheme, в какой-то степени, выглядит как замена для CL-овских special и динамических переменных.

antares0 ★★★★
()
Ответ на: комментарий от antares0

MP - multi processing, в CMUCL есть такой пакет. Как лёгкие процессы в Erlang. Дело в том, что и продолжения вместе с CPS и MP - это два способа реализации конечно-автоматной организации обработки конкурентных запросов. Например - веб-сервер с моделью «поток-на-соединение» имеет экспоненциальные характеристики, и есть три варианта его улучшения: реализовывать автоматную обработку вручную (достаточно сложно - фиксированное количество нитей, epoll, очереди, есть один такой сервер в виде зарисовки для iolib), continuation-based модель (teepeedee2, dwim.hu - на cl-cont), и просто лёгкие процессы (ничего нет, ввиду отсутствия MP).

quasimoto ★★★★
()
Ответ на: комментарий от unC0Rr

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

Forth?

Нет // К.О.

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Если я правильно помню не то что бы легкие нити а скорее микропроцессы в смысле Pi-исчичления. А это уже собственная внутри-erlang-овская ересь с собственной парадигмой.

А легкие нити вобще. Как абстракция конечно имеют право на жизнь. Но учитывая возможности динамических переменных в CL не очень осмыслены. В каком-то смысле наличие явных нитей в языке показывает проблемы отсутсвие понятий окружения/контекста.

antares0 ★★★★
()
Ответ на: комментарий от antares0

Если я правильно помню не то что бы легкие нити а скорее микропроцессы в смысле Pi-исчичления.

Я и говорю - лёгкие процессы (и в Erlang и в CMUCL их процессами называют).

Как абстракция конечно имеют право на жизнь.

Всё-таки в первую очередь они превлекательны своими практическими качествами - эффективность, лёгкость, etc.

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

Ну так message passing в Erlang эту проблему и решает (нет разнообразных забот о блокировках).

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

> Я и говорю - лёгкие процессы (и в Erlang и в CMUCL их процессами называют).

Называют, а в CL есть СLOS-объекты, которые так сказать ОО-объекты, есть структуры и condition, похожие на ОО-объекты.. и всякие остальные объекты.

Что для Erlang процесс для всех остальных может быть и объектом. П оэтом с одинаковыми терминами надо быть осторжнее. Для Erlang-а лозунг : - «Плодите процессы на каждый чих» - осмысленен. Для легких процессов не факт.

Всё-таки в первую очередь они превлекательны своими практическими качествами - эффективность, лёгкость, etc

Эти качества существуют относительно тяжелых железных процессов пороженных проблемами C. Если же изменить точку взгляда то можно увидеть и то что легие нити это такая попытка облегчить бег на С-ишных костылях и «еще одна» абстракция..

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

Ну так message passing в Erlang эту проблему и решает (нет разнообразных забот о блокировках)

Проблему_отсутсвия понятий окружения/контекста? В каком месте? А блокировки это совсем другой вопрос.

antares0 ★★★★
()
Ответ на: комментарий от antares0

Проблему_отсутсвия понятий окружения/контекста? В каком месте?

Кстати - почему в MP среде должно быть что-то не так с этими понятиями?

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

Но в MP снабжённом message passing - с точки зрения кода выполняющегося в данном процессе есть всего две операции «принять сообщение» и «отправить сообщение» - просто две функции с побочными эффектами, они не могут разрушить понятие окружения также как его не может разрушить никакая другая функция с побочным эффектом.

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

> Кстати - почему в MP среде должно быть что-то не так с этими понятиями

Многопоточность не связана с окружением. Но в потоках (без разлия веса_) смешивается понятия потока исполнения и окружения. Результатом является «поток на соединение». На самом деле соединеие и поток исполнения пользвателя напрямую не связаны с потоком исполнения сервера. Если это понимать то и многопоточность будет немножко другой.

Но в MP снабжённом message passing - с точки зрения кода выполняющегося в данном процессе есть всего две операции «принять сообщение» и «отправить сообщение» - просто две функции с побочными эффектами, они не могут разрушить понятие окружения также как его не может разрушить никакая другая функция с побочным эффектом

Окружение не надо защищать или разрушать. Нужно иметь что бы окружение было полноправным (first-class) объектом.

antares0 ★★★★
()
Ответ на: комментарий от quasimoto

продолжения вместе с CPS и MP - это два способа реализации конечно-автоматной организации обработки конкурентных запросов.

Любопытно, что эрланговский message passing в F# реализован в конечном итоге через продолжения... (т.е. async workflow + MailboxProcessor)

dave ★★★★★
()
Ответ на: комментарий от quasimoto

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

ott ★★★★★
()
Ответ на: комментарий от antares0

Ну это всё понятно. Я на самом деле хотел спросить вот что - существует в природе такой пример (кода) - мол, вот у нас многопроцессорное окружение (или просто многопоточное), вот замыкание, и можно точно сказать что это замыкание в условиях MP (или MT) не является first-class объектом, и никак таковым не может быть сделано?

То есть - почему вы пришли к выводу, что:

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

Я не знаю Erlanga чтобы судить о том как там поживают замыкания, но вот в CL - вроде всё нормально, что при многопоточности (где угодно), что при MP (CMUCL).

quasimoto ★★★★
()
Ответ на: комментарий от ott

Название говорящее :) (как тот пример в Clojure для «муравьёв»). Нужно посмотреть - там хотя бы на целевом языке реализовано (на Scheme, а не на Си), можно по-разбираться.

quasimoto ★★★★
()
Ответ на: комментарий от Love5an

> круто было бы иметь лисп для низкоуровневой разработки(т.е. достаточно низкоуровневый язык, с ассемблерными вставками, стандартизированным ABI, и в то же время еще лисп, с макросами, gc, etc., но без громадной стандартной библиотеки).

goo? http://en.wikipedia.org/wiki/Goo_(programming_language) http://people.csail.mit.edu/jrb/goo/
оно объектно-ориентировано в стиле Dylan/CLOS, посмотри про bootstrapping: http://people.csail.mit.edu/jrb/goo/goo-boot.pdf — ассемблера нет, но есть прозрачная линковка с Си кодом

FONC/COLA/coke? http://piumarta.com/software/cola/ http://en.wikipedia.org/wiki/COLA_(software_architecture)
http://www.jquigley.com/files/talks/fonc1.pdf

точнее, coke и jolt из её состава: http://piumarta.com/software/cola/coke.html

jolt http://subvert-the-dominant-paradigm.net/blog/?p=25

Church/State http://subvert-the-dominant-paradigm.net/blog/?cat=10 http://subvert-the-dominant-paradigm.net/blog/?p=29

очень напоминает State http://subvert-the-dominant-paradigm.net/blog/?p=28

Lush? http://lush.sourceforge.net/ там ассемблера правда нет

anonymous
()
Ответ на: комментарий от quasimoto

> Ну это всё понятно. Я на самом деле хотел спросить вот что - существует в природе такой пример (кода) - мол, вот у нас многопроцессорное окружение (или просто многопоточное), вот замыкание, и можно точно сказать что это замыкание в условиях MP (или MT) не является first-class объектом, и никак таковым не может быть сделано?

Многопоточность слабо связана с конкретными фичами языка и в том числе не влияет на first-class-ность языка.

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

В CL нет явных нитей, есть нити как интерфейс ОС. А легкие нити это абстракция поверх CL.

antares0 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.