Wishlist - Revision history

Mart: Generic contexts are supported

2019-04-02T12:14:25Z

Generic contexts are supported

← Older revision		Revision as of 12:14, 2 April 2019
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.

	~~== 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 ==		== Interactive Debugger ==

Mart: hierarchical modules are already available

2019-04-02T12:13:45Z

hierarchical modules are already available

← Older revision		Revision as of 12:13, 2 April 2019
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 ==~~
	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)~~

	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 ==

ErikZuurbier at 14:06, 26 August 2010

2010-08-26T14:06:34Z

← Older revision		Revision as of 14:06, 26 August 2010
Line 28:		Line 28:

	--LeandroMattioli 00:25, 23 November 2008 (CEST)		--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

ErikZuurbier: /* Improved imports */

2009-09-14T12:20:36Z

Improved imports

← Older revision		Revision as of 12:20, 14 September 2009
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 ==

ErikZuurbier: /* Improved imports */

2009-09-14T12:19:49Z

Improved imports

← Older revision		Revision as of 12:19, 14 September 2009
Line 6:		Line 6:

	--[[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.

	== Generic functions with multiple dependencies ==		== Generic functions with multiple dependencies ==

LeandroMattioli: Now it's OK. (why haven't I used the preview button?)

2008-11-23T02:32:30Z

Now it's OK. (why haven't I used the preview button?)

← Older revision		Revision as of 02:32, 23 November 2008
Line 23:		Line 23:
	It would be nice to have Clean's IDE on GNU/Linux.		It would be nice to have Clean's IDE on GNU/Linux.

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

LeandroMattioli: I don't have much experience on Wiki...

2008-11-23T02:31:23Z

I don't have much experience on Wiki...

← Older revision		Revision as of 02:31, 23 November 2008
Line 23:		Line 23:
	It would be nice to have Clean's IDE on GNU/Linux.		It would be nice to have Clean's IDE on GNU/Linux.

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

LeandroMattioli: Link removed (I guess I won't put a page named LeandroMattioli on the Clean Wiki)

2008-11-23T02:30:30Z

Link removed (I guess I won't put a page named LeandroMattioli on the Clean Wiki)

← Older revision		Revision as of 02:30, 23 November 2008
Line 23:		Line 23:
	It would be nice to have Clean's IDE on GNU/Linux.		It would be nice to have Clean's IDE on GNU/Linux.

	--[[User:~~LeandroMattioli\|~~LeandroMattioli]] 00:25, 23 November 2008 (CEST)		--[[User:LeandroMattioli]] 00:25, 23 November 2008 (CEST)

LeandroMattioli: New item on wishlist

2008-11-23T02:26:40Z

New item on wishlist

← Older revision		Revision as of 02:26, 23 November 2008
Line 19:		Line 19:

	--[[User:Raould\|Raould]] 00:31, 23 August 2008 (CEST)		--[[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.

			--[[User:LeandroMattioli\|LeandroMattioli]] 00:25, 23 November 2008 (CEST)

Raould at 22:31, 22 August 2008

2008-08-22T22:31:08Z

← Older revision		Revision as of 22:31, 22 August 2008
Line 13:		Line 13:

	--[[User:Thomas van Noort\|Thomas van Noort]] 09:49, 24 April 2008 (CEST)		--[[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)