Wishlist

From Clean
(Difference between revisions)
Jump to: navigation, search
(Improved imports)
(Improved imports)
Line 8: Line 8:
  
 
This is not an improvement per se. The hierarchy of a package is usually quite arbitrary. Its actual shape and distribution of modules over the package hierarchy could be different tomorrow while the packages' functions, types, etc. might change little. The whole idea of the current design is that hierarchy changes would not influence the imports in .dcl and .icl files, only the project files would need to change. If we want to solve the naming conflict issues of the current design, I think using the hierarchy paths would be the quickest and dirtiest solution. Instead, we should use pertinent information about functions, types etc., not volatile information such as the current package hierarchy.
 
This is not an improvement per se. The hierarchy of a package is usually quite arbitrary. Its actual shape and distribution of modules over the package hierarchy could be different tomorrow while the packages' functions, types, etc. might change little. The whole idea of the current design is that hierarchy changes would not influence the imports in .dcl and .icl files, only the project files would need to change. If we want to solve the naming conflict issues of the current design, I think using the hierarchy paths would be the quickest and dirtiest solution. Instead, we should use pertinent information about functions, types etc., not volatile information such as the current package hierarchy.
 +
 +
Erik Zuurbier
  
 
== Generic functions with multiple dependencies ==
 
== Generic functions with multiple dependencies ==

Revision as of 12:20, 14 September 2009

Clean is a continuous work in progress. If you have any ideas about what is missing in Clean or could be improved you can add them to this page. Adding something to the wishlist does not automatically mean that your great idea will be added to Clean. This list is just a place to collect ideas about how Clean could be improved.

Contents

Improved imports

I would like to see an improved import system for modules which allows hierarchic package names and qualified imports. When for example a definition module Baz.dcl in a directory foo/bar could be imported using the statement import qualified foo.bar.Baz, it becomes possible to create a large hierarchic repository of libraries without namespace conflicts. As an additional advantage, we no longer need to supply multiple paths in project or environment files.

--Bas Lijnse 14:11, 31 March 2008 (CEST)

This is not an improvement per se. The hierarchy of a package is usually quite arbitrary. Its actual shape and distribution of modules over the package hierarchy could be different tomorrow while the packages' functions, types, etc. might change little. The whole idea of the current design is that hierarchy changes would not influence the imports in .dcl and .icl files, only the project files would need to change. If we want to solve the naming conflict issues of the current design, I think using the hierarchy paths would be the quickest and dirtiest solution. Instead, we should use pertinent information about functions, types etc., not volatile information such as the current package hierarchy.

Erik Zuurbier

Generic functions with multiple dependencies

Currently, a generic function in Clean automatically depends on itself only. Often, a generic function is a complicated mixture of multiple tasks, which are normally handled by different generic functions. Because of the dependency restriction in Clean, this requires the developer to combine several generic functions into a single generic function, together with additional parameters which denote the current state/mode/function of the generic function.

If a generic function can depend on multiple other generic functions, we are able to define concise generic functions, each with a specific task. This improves the readability, maintainability, and usability of generic functions. Furthermore, specialization of a generic function becomes more fine-grained since we can choose to specialize a single generic function which performs a specific task, instead of specializing a generic function which performs multiple tasks.

--Thomas van Noort 09:49, 24 April 2008 (CEST)

Interactive Debugger

Personally I find interactive debuggers to be invaluable tools for really shipping software. It would be great if Clean grew to have one (cf. Haskell, Erglang, O'Caml).

--Raould 00:31, 23 August 2008 (CEST)

IDE on GNU/Linux

It would be nice to have Clean's IDE on GNU/Linux.

--LeandroMattioli 00:25, 23 November 2008 (CEST)

Personal tools