Несколько исходных файлов, структуры каталогов и пространства имен в функциональном программировании - PullRequest
7 голосов
/ 10 марта 2011

Я был удивлен, увидев, что исходный код Hacker News - это всего лишь один большой файл, содержащий простой список определений функций. Git Hub - news.arc

Это типично для функционального программирования? Необычно ли иметь источник в большом количестве коротких файлов в потенциально глубокой структуре каталогов, как это обычно бывает в проектах ООП?

Модули в FP - это то же самое, что и пространства имен в ООП?

Ответы [ 3 ]

5 голосов
/ 12 марта 2011

Существует много языков функционального программирования (FPL), и они очень разные. Как и диалекты Лисп (например, Схема, Common Lisp, Logo, Arc и другие).

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

В некоторых объектно-ориентированных языках программы состоят из множества классов, иерархия классов (или что-то подобное) отображается в структуре каталогов, и каждый класс представляет собой один или несколько файлов. Это приводит к программным системам, состоящим из множества файлов и среды IDE, которая просматривает эти файлы / классы в виде иерархии. (это отличается от оригинального Smalltalk, где код доступен браузерам, а не извлекается из файлов).

Например, в Common Lisp классы не являются пространствами имен, а методы не привязаны к отдельным классам (поскольку существуют мульти-методы). Существует отдельная конструкция, называемая «package», которая предоставляет пространства имен для символов Lisp. Там типичная программная система состоит из файлов, которые объединяют несколько связанных функций. Обычно большая функциональная единица получает свое собственное пространство имен.

Например, графический инструментарий может иметь несколько пространств имен: ui-backend, ui-user, ui-system, ui-drawing, ui-animation. Пространство имен ui-drawing может использоваться в нескольких файлах: ui-draw-2d-objects.lisp, ui-draw-3d-objects.lisp, ui-draw-macros.lisp и других. Один файл ui-draw-2d-objects.lisp объединит все классы, методы и переменные, необходимые для рисования 2d-объектов (линий, многоугольников, окружностей, растровых изображений, ...).

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

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

В LispWorks примитивы рисования находятся в пакете "GP" или "GRAPHICS-PORTS". Затем я могу попросить LispWorks сообщить мне все символы, которые содержат «draw-rect» в пакете «GP».

CL-USER 10 > (apropos "draw-rect" "GP")
GRAPHICS-PORTS::%DRAW-RECTANGLE (defined)
GRAPHICS-PORTS::DRAW-RECTANGLE-BOUNDS (defined)
GRAPHICS-PORTS::%DRAW-RECTANGLES (defined)
GRAPHICS-PORTS::DRAW-RECTANGLES-BOUNDS (defined)
GRAPHICS-PORTS:DRAW-RECTANGLES (defined)
GRAPHICS-PORTS:DRAW-RECTANGLE (defined)

Приведенный выше список говорит мне, что каждый из этих символов имеет определенную функциональность, а символы с одним двоеточием «экспортируются».

Затем я могу использовать эти символы для поиска дополнительной информации: список аргументов, исходный код, документация и многое другое. Common Lisp даже предоставляет стандартные функции, такие как DOCUMENTATION, DESCRIBE и ED.

Таким образом, развитие здесь основано не на множестве небольших файлов, организованных по некоторой иерархии классов, а в виде иерархии модулей и пространств имен, где каждое пространство имен объединяет больший объем функциональности, хранящейся в одном или нескольких файлах. В этом случае IDE отвечает за поддержку неиерархического просмотра и поиска.

4 голосов
/ 10 марта 2011

Нет, модульное программирование довольно распространено и в FP.Применяются те же общие принципы модульности.

Например, в Haskell вы можете сказать

import qualified Parsec as P

, что дает вам библиотеку синтаксического анализа Parsec в пространстве имен P.

То, являются ли модули и пространства имен «тем же, что и пространства имен в ООП», зависит от вашего функционального языка и вашего языка ООП.(Модули ML немного отличаются от других языков.)

2 голосов
/ 12 марта 2011

Язык реализации - Arc , в котором краткость является основной целью проектирования.news.arc входит в состав дистрибутива Arc и может быть задуман как демонстрация этой краткости путем упаковки полезного приложения в одном исходном файле.

Такая упаковка не обязательно свидетельствует о распространенной практике в функциональном программированиихотя, как указывает @ Rainer (+1), границы файлов часто менее важны в среде функционального программирования.

...