The world's smartest i/o device for Haskell
Described in: http://www.numeric-quest.com/haskell/smartest.html Jan
Hello! On Wed, Nov 01, 2000 at 02:40:39PM -0500, Jan Skibinski wrote:
Described in: http://www.numeric-quest.com/haskell/smartest.html
Neat. On page 2 (in lynx, 25 line display), I seemed to recognize it. The real name begins with Sq*** :-) Nice idea that a Haskell IDE could be based on "Smart". That idea were perhaps even better if/when HEP should come to life. Kind regards, Hannah.
Since I have noticed some moderate interest in this subject: several hundred visitors to the main page - some recurring, several dozens peeks at the module Hugs.st (some recurring again) and several encouraging private messages - including some from the pillars of this congregation (only one public message from Hannah though), I am posting this message as my final addendum: I had hesitated whether or not post my original message to this forum. But thanks to the encouraging messages (and they really count when one is not sure how stupid or not the subject is) I will be occasionaly doing some further work on some interfaces to Squeak. But I will not be bothering this list with any related announcements. If you are interested - check the pages from time to time: www.numeric-quest.com/haskell/smartest.html www.numeric-quest.com/haskell/Hugs.st (linked from the above anyway). But since I am still standing on the soapbox: In meantime, the first page has been decorated by a simple GUI example, a Hugs observer. The file Hugs.st has been also significantly upgraded to include several safety measures and multithreading support in order to be able to interrupt lengthy or non-terminating Hugs computations. Jan
Check http://www.numeric-quest.com/haskell/explorer/explorer.html and tell me what you think about it. The tool uses :browse command of Hugs. There is always a choice for this kind of work: + Parse the source modules. Pro: Tools are portable to other environments. Contra: source code is not type checked and might be buggy. + Be lazy and tap to work of others, such as Hugs. Pro: Modules are typed checked. Contra: tools are not portable. Jan
Check http://www.numeric-quest.com/haskell/explorer/explorer.html and tell me what you think about it.
The tool uses :browse command of Hugs. There is always a choice for this kind of work:
+ Parse the source modules. Pro: Tools are portable to other environments. Contra: source code is not type checked and might be buggy.
+ Be lazy and tap to work of others, such as Hugs. Pro: Modules are typed checked. Contra: tools are not portable.
Good work Jan. I have two comments/questions: 1) Why can't we do this sort of thing in a Haskell GUI tool such as FranTk? What is missing that would make it as easy as in Squeak? 2) Why can't we as a community create "front-end" tools such as this that can be used with several compiler back-ends? I must admit I was disappointed when the grand "Hugs/GHC merger" was abandoned (I'm not criticizing the decision, just expressing my disappointment). In fact, whatever happened to the effort to add Haskell to one of languages supported by Microsoft's Visual IDE? -Paul
On Fri, 10 Nov 2000, Paul Hudak wrote:
Good work Jan. I have two comments/questions:
Thank you, Paul (and all the others that responded privately).
1) Why can't we do this sort of thing in a Haskell GUI tool such as FranTk? What is missing that would make it as easy as in Squeak?
If you take the adverb "easy" away then my answer would be "nothing". I do not want to preach Squeak. I've done enough of it already. But the reality is that Smalltalk has excellent IDE tools, proven by 20 years of practice. What I have shown on the web pages is just a tip of the iceberg. And those tools can be easily adapted to other tasks, far from their original concept of usage. For example, the Object Inspector.. This is in fact one of debug tools. Had I chosen to use its original version you would have seen much more verbose printout on my web page - telling you what exactly you are looking at: strings, arrays, dictionaries; their full contents, etc. But for this application all of that would be irrelevant and unneceserily foggy. So I browsed several related classes (using of course Squeak's IDE) and finally found three methods to adjust. Instead of modifying the original classes, I subclassed - getting in effect quite different customized tool. That was quite inexpensive thing to do. From then on I could concentrate on the task on hand: understanding what I am receiving from Hugs and deciding on how to structure and present the data. Anyone could have done it easily. It's just that one day I was struck by a thought: what's so sacred about interlanguage marriages? Do they really have to be close in spirit to qualify? Like C and C++? Maybe this is why we still do not have any decent front end tools for Haskell? And then another thought: How about an unlikely aliance of the purest functional language with the purest object oriented language? No compromises! And do not worry, Haskell could not possibly get polluted - after all it has monads standing on guard! :-)
2) Why can't we as a community create "front-end" tools such as this that can be used with several compiler back-ends? [cut]
A gui-less universal support would be quite useful too, so GUI tools from any toolkit, could tap to something common for all Haskell environments, not necesserily Hugs. Jan
participants (3)
-
Hannah Schroeter -
Jan Skibinski -
Paul Hudak