Difference between revisions of "Wishlist"

From Clean
Jump to navigationJump to search
(Added improved import wish)
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
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.
 
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.
 
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.
 
  
 
== Improved imports ==
 
== Improved imports ==
I would like to see an improvement import system for modules which would allow 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 additional advantage, you no longer need to supply multiple paths in project or environment files.
+
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.
  
 
--[[User:Bas Lijnse|Bas Lijnse]] 14:11, 31 March 2008 (CEST)
 
--[[User:Bas Lijnse|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.
 +
 +
--[[User:Thomas van Noort|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).
 +
 +
--[[User:Raould|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)
 +
 +
== Compiler Option Check Overflow ==
 +
Could the IDE support a compiler option to have the executable check on numeric overflow? Just like you can have a program check on index out of range. And maybe there are more cases I dont know of where the executable currently continues with debatable intermediate results
 +
 +
--Erik Zuurbier 26 August 2010

Revision as of 15:06, 26 August 2010

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.

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)

Compiler Option Check Overflow

Could the IDE support a compiler option to have the executable check on numeric overflow? Just like you can have a program check on index out of range. And maybe there are more cases I dont know of where the executable currently continues with debatable intermediate results

--Erik Zuurbier 26 August 2010