имена экспортируемых функций в Racket

3. If two modules export two different values with the same name, you must use (require (except-in modulename name)) in order not to import name (but import everything else)

An alternative for #3 is (require (prefix-in foo: some-module))

Взял из логов irc http://pastebin.com/1ayJbFeC

невозможность одновременно импортировать racket/contract и ffi/unsafe (в обоих есть ->).

(require racket/contract
         (except-in ffi/unsafe ->)
         (rename-in (only-in ffi/unsafe ->) [-> -->]))

Я это и имел в виду. В CL тоже есть shadow...

Когда столкнулся один символ — пережить можно. А вот если их десяток. Например, сделали бы в ffi/unsafe такую же развесистую систему стрелочек, то что делать...

Кроме того вот это ошибка:

#lang racket

(provide (contract-out (foo (-> integer? integer?))))

(define (foo x) x)

(require ffi/unsafe)

;; unsaved editor:3:28: ->: should be used only in a _fun context in: (-> integer? integer?)

Предположим такой пример: надо сделать библиотеку: двусвязный список. Очевидно, что нужны типовые операции: first, last, rest, ...

Как будет наиболее корректно назвать функции, выполняющие эти операции?

Получается, в данном случае, идентификатор определен на уровне языка (выше) и при импорте модуля перекрывается. А когда идентификатор содержится в нескольких одновременно импортируемых модулях, тогда конфликт. Еще один плюс в использовании raket/base. Ну а в случае своего языка, получается, надо осторожно использовать require других модулей, а лучше их вообще не использовать.

Вопрос кстати интересный. Ты вроде в рассылке общаешься. Задай его там, интересно, что ответят.

Наверное с префиксом, а как еще можно?

Нашёл два примера:

С префиксом: http://www.mail-archive.com/users@racket-lang.org/msg07771.html

Без префикса: http://planet.plt-scheme.org/package-source/krhari/pfds.plt/1/5/planet-docs/f...

Вот и думаю, что для потенциального пользователя очевиднее/удобнее.

Наверное с префиксом,

Здесь есть проблема. Из-за чего в CL крайне не рекомендуется использовать префикс.

Предположим, я сделал библиотеку для двусвязных списков. Использую префикс dll- (double-linked- слишком длинно). Потом кто-нибудь делает библиотеку для работы с *.DLL файлами. С тем же префиксом. А потом в программе конструкции типа

(dll-cons (dll-open lib1) (dll-rest libraries))
; здесь dll-open открывает файл DLL, а остальное -- строит список

Читать такое почти невозможно.

Можно делать префиксы длиннее, но тогда быстро появляются имена наподобие command-line-read-remaining-arguments-for-partial-command (это из стандарта CLIM).

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

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

Спасибо. Похоже, это действительно лучший вариант.

Лучший вариант - предоставить пользователю установить свой префик через prefix-in, это же в любом случае занимает всего одну строку. Какие проблемы?

Google style guide

Не нужно.

Лучший вариант - предоставить пользователю установить свой префик через prefix-in, ... Какие проблемы?

имена экспортируемых функций в Racket (комментарий)

Google style guide

Не нужно.

Есть лучшие альтернативы?

Какие проблемы?

В смысле, если явно не указать в документации, что пакет перекрывает функции Racket, могут быть странные ошибки (особенно, если вдруг у перекрытой функции контракт всё-таки совпадёт, а поведение — нет).

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

Или в Racket принято всегда добавлять префикс для всех пакетов, кроме racket/* ?

В смысле, если явно не указать в документации, что пакет перекрывает функции Racket

А кто мешает указать?

А кто мешает указать?

1. в racket новые функции добавляются с версиями
2. Их просто много, могу не заметить, как перекрыл что-нибудь типа set (который racket/set).

вот если их десяток. Например, сделали бы в ffi/unsafe такую же развесистую систему стрелочек, то что делать...

А накатать свой «импорт», который бы пробегал по всем «публичным» именам библиотеки и приклеивал бы указанный префикс?

ну это упадет в любом случае на первом же тесте и будет понятно что что-то не так

А накатать свой «импорт», который бы пробегал по всем «публичным» именам библиотеки и приклеивал бы указанный префикс?

Так это и есть упомянутый выше prefix-in. Или в экспорте prefix-out.

Пока, по итогам обсуждения, склоняемся к варианту prefix-in + упоминание в документации, если какое-то имя из racket перекрыто осознанно.

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

ну это упадет в любом случае на первом же тесте

Не всегда на первом

#lang racket
(module m racket/base
  (provide my-range test)
  (require (planet krhari/pfds:1:5/catenablelist))

  (define (my-range n)
    (reverse (let inner ([n (sub1 n)] [acc null])
               (if (< n 0) acc
                   (cons n (inner (sub1 n) acc))))))
  
  (define (test)
    (and (= (first (my-range 5)) 0)
         (= (first (rest (my-range 5))) 1))))

(require 'm)

;; запускаем
> (test)
#t

;; все тесты пройдены, используем
> (= (first (my-range 5)) 0)
. . first: contract violation
  expected: (and/c list? (not/c empty?))
  given: #<List>

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

В CL с такой идеей тоже носились :-)))

Пришли к выводу, что так делать нежелательно, так как если у тебя есть кусок кода типа

#lang racket
(require lib)

(define (my-foo x) (foo x)) ;; здесь foo из lib

то, если в очередной версии racket вдруг появится foo, программа должна продолжать работать, а не переименовывать тот foo, который нужен в lib:foo

На самом деле, если действительно ответственность переложить на пользователя библиотеки, то проблем нет: есть prefix-in если надо импортировать всё и есть (require lib name1 name2 ...) для явного импортирования того, что нужно с перезаписью поверх.

то, если в очередной версии racket вдруг появится foo, программа должна продолжать работать, а не переименовывать тот foo, который нужен в lib:foo

Речь не о том, чтобы автоматом переименовывать, а о том, чтобы кинуть варнинг. Ну а дальше пользователь уже сам решит что ему надо - переименовать идентификатор, сделать prefix-in или еще что. Проблема то не в том что идентификаторы перекрываются, а в том, что это происходит незаметно. Подобный макрос решит проблему.

Проблема то не в том что идентификаторы перекрываются, а в том, что это происходит незаметно.

Согласен.

еще есть вариант сделать минимальный #lang, в котором _ничего_ уже не будет добавляться, а добавляться будет в библиотеки. у require же незаметного перекрывания нету.

сделать минимальный #lang, в котором _ничего_ уже не будет добавляться

Угу. И заставить _всех_ пользователей им пользоваться. Они будут счастливы.

Ещё есть вариант блокировать символы из #lang, но тогда будет как в CL: локальный (define list ...) будет вызывать ошибку компиляции. А (except-in ...) или (prefix-in ...) у lang нету.

Речь не о том, чтобы автоматом переименовывать, а о том, чтобы кинуть варнинг.

Кстати, идеальный вариант — даже не макрос, а кнопка в DrRacket. Зачастую перекрытие символов сделано намеренно и осознанно. И при каждой компиляции получать предупреждение неприятно.

ну удобнее всего сделать свой #lang и добавлять кавкой-нибудь ключ. типо #lang racket check - проверяется, без check - не проверяется. Надо подумать как конкретно макрос должен выглядеть.

типо #lang racket check

Нет. Надо явно указывать список перекрываемых позже. Как в expect-in. Иначе никто эту проверку почти нигде использовать не будет (перекрывают хоть что-нибудь многие стандартные пакеты)

Иначе никто эту проверку почти нигде использовать не будет (перекрывают хоть что-нибудь многие стандартные пакеты)

Да нет, для стандартных пакетов если один два символа -перекрывается - это уже редкость и исключение из правил. В 99% случаев вообще ничего не перекрывается.

Я как раз про ситуацию «один два символа». Значит использовать «lang racket check» уже нельзя. Или надо в нём как то эти один-два символа явно указать как исключения.

А так:

ffi/unsafe: ->
srfi/1: assq, assv, car, ... 
srfi/13: string?, string-ref, ...

Их все будет нельзя использовать в #lang racket check (а srfi даже в lang racket/base check)

Так стрелочки в #lang racket и так нету. А srfi тут как раз исключение, т.к. оно повторяет стандартную библиотеку.

-> provided from racket/contract/base, racket/contract, racket

-> provided from typed/racket/base, typed/racket

А srfi тут как раз исключение, т.к. оно повторяет стандартную библиотеку

Вот только в srfi/13 есть string-count, string-skip, ... В srfi/1 — break, span, ...

Поэтому не повторяет, а расширяет.

Ну так это в typed, а не в #lang racket.

Я имел ввиду, что повторяет в перекрываемых идентификаторах.

Ну так это в typed, а не в #lang racket.

-> provided from racket/contract/base, racket/contract, racket

Последний в списке просто racket. Он же в lang racket.

Ну ладно. Это уже придирки. По существу: идеальный вариант — просто инструмент (tool) показывающий список перекрытых идентификаторов (+ кем перекрыты). Добавлять что-то типа check малополезно, так как тогда придётся что-то делать с использованием srfi (не использовать — не вариант, использовать всегда с префиксом... srfi/13:string-count как-то не впечатляет).