At 11:58 -0800 2001/02/28, Johan Nordlander wrote:

The MacOS specifics in the Hugs Feb2001 version are actually quite new; they are directly taken from the latest version I got from Hans in December last year. However, for reasons I'll return to below, many aspects and features of that version didn't make it into the distribution. This explains the lack of drag-and-drop launching. The font size problem Richard O'Keefe reports is however a mystery to me, I'll have to pass on this one for the moment since I'm not able to recreate the bug.

My main objectives as the Hugs maintainer have been fixing bugs and incorporating interesting enhancements, while at the same time making sure that the source base stays maintainable. These objectives aren't always compatible, and in the Mac Hugs case this essentially means the following:

- The meat of the Mac additions have previously been provided as a separate source distribution, with a stucture totally different from the main sources. I've only merged in things that could be transferred to the main repository without too much effort.

Well, I gave the explanation why: The Hugs team has never before bothered paying any attention to it at all after MPJ left. You seems to be the first one. :-)

- The AppleEvent handling in Hans' and Pablo's version is indeed interesting, but it introduces asynchronous concurrency into the interpreter itself, something which it just isn't built to handle.

Well, it is not complete asynchronous concurrency, because it stacked, not separate threads. But you are right, there is a potential for breaks if a program is executing and global data somehow is shared. (See below for a possible fix.) On the other hand, one thing that makes MacOS unique is the presence of high-level events. And the code is safe if no AppleEvent's are received, or some unfortunate circumstances described above do not happen. Anyway, that is what I have on my computer, and I do not have the option stripping it out. -- Maintaining more than one version is a bother, and I think that high level events (interprogram communications) and Haskell have a potential together.

This is of course unacceptable for a software package that aims at being stable across multiple platforms, and the AppleEvent support was therefore edited out.

So the stability problems are not all that bad, I think. -- A more prudent move would be to leave it in, and see if people experience problems. (also see below for a possible fix.) After all, there might arrive a thread safe successor to Hugs, GHCi, and then this input with AppleEvent's experience will be important. -- The thing is that AppleEvent's are awfully complicated, so you will not find somebody willing to start working on the topic if the code is stripped out.

Unfortunately, this also took away the drag-and-drop facility, which is something that definitely could be implemented in a safe way. I just simply didn't have time to do that for the Feb release.

So the DropUNIX package was eliminated, and AppleEvent's was implemented from scratch.

- The Mac sources I was given also contained some stack space management enhancements which I didn't understand, and which also made the interpreter crash on a program that ran just fine on the Feb 2000 version of Hugs. They were hence removed.

Well, the stack check makes sure that Hugs does not bomb due to stack overflow, so perhaps the problem is elsewhere. -- Perhaps you din't implement all components correctly in your editing. Also note that the stack check is not perfect: If you have stripped out the STACK_CHECK from some recursively functions, or introduced more such functions, Hugs may still bomb. But the problem does not become better with the stack check out, it increases the hazards. -- Without the stack check, the stack will merely write into the heap until the program or probably the whole computer bombs.

- The Mac sources also contained a complete redistribution of MetroWerks' SIOUX sources, for no apparent reason. If some enhancements were buried in there somewhere they are now lost as well, since I didn't want to include code in the distribution that might clash with a standard MacOS C library. Furthermore, the reliance on a binary-only version of a library called AEGizmos(modified) is obviously not optimal from a maintainability point of view, so all such dependencies are also gone.

No, all the altered SIOUX sources (the console package) have new names. However, Metrowerks has substantially altered the SIOUX package CW Pro 5 -> 6, so the complete set of sources will (or may) be needed if one switches to CW Pro 6. There is one guy using CW 6 & MacHugs, which is why the stuff is included. The next step would be to write a whole new GUI, but it is probably better waiting for MacOS X. -- And I do not have time for that, so let's hear from any interested candidates.

So this leaves us with a Feb 2001 Hugs that provides what could be called just basic MacOS support.

You actually succeeded in stripping out nearly all the features that makes the MacOS GUI convenient I think. :-)

On the othere hand, the MacOS support that's there is now fully integrated into the main Hugs source tree.

I hope you will repeat it with the stuff I just sent you: It is the modified Feb 2001 sources, so you do not have to check what it is doing.

I can see the following ways forward from the current state:

- Someone (Hans? Pablo? me?) implements the basic AppleEvent handling that's needed to get back the drag-and-drop functionality. This code should preferably be self-contained, and should be put in the machugs directory.

Well, that is the point of integrating the stuff I have sent you: While the Hugs team somehow did not implement the changes, I started making the MacOS code & the Hugs kernel source as orthogonal as possible. -- Incidentally, this includes moving out the code that you once wrote from the Hugs kernel. :-)

Ideally it should continue to respond after hugsmain() has been called, but only if the Open events can be made to appear as ordinary :load commands to the intepreter.

Well, this is the behavior of the stuff I sent you. -- Somehow you succeeded to strip that out. Specifically, if I recall the details right, if one drops a file onto the Hugs icon while it is executing, it should {Interrupt} what is executed, and then :l(oad) the new files. -- The very point of stripping out the DropUNIX package and implement AppleEvent's from scratch is to make such thing possible. Once this has been done, it is not difficult to implement new AppleEvent's features. -- All that is needed someone interested having the time to do it. And if people experience problems with the receiving of AppleEvent's while executing, one can always throw in an {Interrupt} to make it safe.

- AppleEvent handling on the Haskell level (i.e., Events.hs et. al.) could preferably be provided by Hans and Pablo as a standalone library that's only implemented on the Mac (just like the Win32 Graphics lib, although it has been ported to X-windows as well).

Well, the reason it is hard coded was that the Hugs foreign interface was to primitive.

However, I must strongly suggest that whoever undertakes this task will take the time to ensure proper integration with the Hugs' sequential execution machine.

You know, this is not really possible without rebuilding the Hugs kernel from scratch to be concurrent. Better to hope that GHCi will be concurrent, and then move the AppleEvent's code to that version when it becomes available.

I think Alastair Reid can be a good source of information on how this is achieved.

The current implementation was chosen after discussions with Alastair Reid. It would be simpler for some of the fellows on the current Hugs kernel development team to: First put in the Mac modifications, and then ask themselves, "what does this mean for the Hugs kernel". The modifications needed are not dramatic for a foreign interface: I needed to be able to convert between lazy and strict strings, and to be able to implement four new primitives. One can implement such stuff as a DLL (except that loading plugins under pre-MacOS X is complicated), but given what was needed it would have been overkill.

- Any other enhacements or suggestions are gratefully received; just bear in mind that diffs must be relative the Feb 2001 source base in order to be considered. Together with the other Hugs authors I will also continue to issue some form of "editor's discretion" when it comes to deciding what the distributed version of Hugs should look like.

Please do not forget to put up the name of the guy who made the version (not me, because I may get email about stuff I do not know anything about) in case you make an independent version :-). Also, it should probably have a different MacOS creator code, in order to not confuse the MacOS in case someone uses both versions, and a new icon. I doubt that anybody is running the "Basic Hugs" in our distribution, so you can take over that one if you so want. (Its creator code is then registered with Apple, so you do not have to do it.) Hans Aberg

At 15:56 -0800 2001/02/28, Johan Nordlander wrote:

With all due respect, but here's some reasons why the previous Hugs maintainers might have been reluctant to let your variant of Hugs into the main source tree: it's big, it's unstructured, it's a mix of various unrelated features, and it carries some serious implications to the overall program reliability that I know no maintainer would accept (read unsafe asynchrony).

One could think that you are describing the Hugs kernel sources themselves. :-) My guess is that you simply didn't understand it at the first glance, and it will take more than a first glance to for anybody to understand it: I and Pablo over some years gradually merged and added a series of features to produce that version.

We now have basic MacOS support included in the distribution.

My guess that version you produced will produce some intense traffic on the Hugs_Bugs list, due to its limitations.

What I'm offering you and anybody else interested is to submit extension proposals, one at a time, and I'll add them to the main sources if they seem to be useful, well-written, and free of unwanted side-effects. I'm not interested in buying a whole package. And if I'm to spend time understanding/fixing (say) a stack-checking extension, I'd rather do that if it would benefit all Hugs users, not just those who run the Mac version. The same holds for profiling.

Well, you seem to be a guy with a lot of time. -- I do not have that much time.

So please see if you can find the time to break down your additions into more manageable units, that are based on the Feb 2001 sources. I'll seriously consider each one of them.

It would take too long time trying to baby-feed you with all those details. Please understand that this MacOS programming is extremely time-consuming, and I found those pieces interesting at the time I did them, but I am not interested in spend all that time explaining the code, simply because somebody is too lazy to read the code itself.

In their absence I'll probably try to add some simple drag-and-drop support, but not much more.

I hope you noticed that the DropUNIX package you once implemented isn't safe, as strange things happen when dropping files on Hugs while running. I think you are in for a long haul if you want to redo the GUI we so far have implemented. Hans Aberg

At 15:35 -0700 2001/02/28, Alastair Reid wrote:

2) Events cause direct calls into Haskell code. (It's pretty easy to do this nowadays using the foreign export dynamic feature of the ffi.) The only trick here is that, because Hugs doesn't support preemption, events must only be delivered at certain safe points. For example, the program might contain a main loop which queries for events, dispatches a call into Haskell code to handle the event and then returns the result of the event handler to the C world. Or, if events appear as asynchronous calls into a C thread, the Haskell program might run with events disabled in most of the code and only enable them by calling into a C function which enables events, waits for the program to complete (during which time it is handling events, of course), and then disables events again.

Right. This is the way to do it. As for the AppleEvent's, it is simpler still, because they are not completely asynchronous (asynchronously independent threads), but stacked: First, let's define what an AppleEvent is. It is a high level event, that is, binary structures that programs use to communicate with each other. (They are iterated typed binary structures, like that can be produced by a C++ polymorphic hierarchy, except that they are largely passive, that is, do not contain function pointers.) If a program should be able receive an AppleEvent, it must make up its mind which ones. So at startup-time, one registers which ones. When a registered AppleEvent arrive, the OS looks up which registered function pointer to call. This selected function pointer may or may not engage the Hugs kernel when executed. So there are some standard AppleEvent's which do not engage the Hugs kernel at all, as they are intercepted. Now, the way I hooked it up, not handled AppleEvent's are translated into a string. Hugs then looks for a primitive in a module Event. If the module is not present, then the Hugs kernel is not engaged. (Thus, only those that load this module Event may experience any problems with asynchronizity.) If, on the other hand, the module Event is loaded, the suitable primitive is activated. -- There are in fact two primitives, depending whether a reply is expected or not (which gives rise to different Haskell typing). Now, when the primitive is executed, it will, if no global data is used, merely use some additional stack space, and after termination, the stack will be restored to what it was before. The only trick needed is to make sure execution does not start at an unfortunate moment (middle of a stack maintenance function or something).

I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of these approaches (i.e., without requiring substantial internal changes to Hugs).

So there is some tweaking needed. The reason I did not do it, is that I am not at all at home with the Hugs kernel and its workings. I was hoping someone familiar with the Hugs kernel would do it in the future. But it seems that with a little tweaking, one could produce something reasonably safe. -- In addition, I can remark that AppleEvent's are said to unique to the MacOS, and some say that in some industries, like graphics, the use of AppleEvent's has made the platform a preferred one. The connection with Haskell is roughly this: Functional languages translate code into "functional covers", that can later execute. I built such a functional cover which understands lambda calculus using a C++ polymorphic hierarchy. The AppleEvent's are similar to such a hierarchy, except that they are passive data. But this gives me the hunch that there ought to be a closer relation between Haskell and AppleEvent's. -- I do not, however, have the time, to explore this in detail myself. (AppleEvent's are quite complicated. Each program can have its own dictionary, and so there might be different ways to express the same thing, depending which program should receive the event.) But I think it is might be an interesting computing topic. Hans Aberg

At 15:35 -0700 2001/02/28, Alastair Reid wrote:

I'm yet to hear of a reason why AppleEvents cannot be dealt with using one of these approaches (i.e., without requiring substantial internal changes to Hugs).

In view of that the high-level AppleEvent events are interrupts, one ends up the same kind of problem of atomizity (code which cannot be interrupted by other threads) as in a pre-emptive environment. Here are some problems: 1) If the Hugs code is sloppily written, this can cause problems. For example, Hugs uses its own stack, so if it first writes the stack and then increases the stack pointer, this would cause a problem if the interrupt occurs between the write & the pointer increment. Similar problems can occur if a variable is temporarily used for something else than its intended use. For example, the console package that came with the Mac CW compiler uses the cursor position for something else while reading a character, which means that if an interrupt happens then, the cursor position value becomes wrong. 2) Some operations may not allow the Hugs engine to compute at all, say a GC cleanup. 3) If Hugs code is impure, that is, using global temporary registers (as I think it does), this is a problem if the interrupt happens in the middle of the execution of an impure function. The remedy for 1), is to rewrite the code so that it becomes semantically correct (disregarding simplifications that might work in a single-threaded environment). And as for 3), it is best to rewrite the code so that it becomes pure. However, there is an interesting way in which the Hugs kernel might be made to simulate simple form of concurrency, even though the kernel is not written for it: When an interrupt happens, the function that is handling it is allowed to register a function pointer in a queue, whereafter it terminates. Then the Hugs kernel sources are sprayed (just as in the case of cooperative multi-tasking) with places where the function pointers in this queue (if non-empty) can be executed. It should be relatively simple to implement: One only needs to identify some places in the code where it is admissible to execute those function pointers. (One exception is when the Hugs kernel is idle, in which those function pointers should be executed immediately and not enqueued.) That is, if one want to allow a high-level event to be treated by the Hugs kernel while the Hugs kernel is actively running. Hans Aberg

At 15:47 -0700 2001/02/28, Alastair Reid wrote:

Some advice to people submitting changes:

Back in the days when I was maintaining Hugs, changes were substantially more likely to be merged into the main base if they were decomposed into a number of small, independent changes whose impact and consequences could be understood in isolation from the other changes.

For example, Hans' stack overflow changes sound like a feature that all Hugs users could benefit from (i.e., not just MacOS users) but it really needs to be submitted as a separate set of patches if Johan is to correctly integrate them and if various individuals around the world are to submit modifications which make the stack overflow code work on other platforms (Sparcs, x86s, etc.)

I think so too, that some such stuff should be of general applicability. The things that do not fall into this category, and is platform specific, should be moved, and be put into a separate set of sources. (As I have done with some of the Mac stuff that formerly was in the Hugs kernel sources.) The reason this does not happen entirely so, is that the Hugs kernel code is very monolithic, with nearly all names not exported, .c files exotically included in .c files, instead of putting the relevant names in a header. So it is hard to do something as intrusive as making an MacOS implementation of it without putting in the right hooks. As for the code itself, the only reasonable is to put it in as it is, and move then move the portions when one knows where they should be. -- It is too big, to do anything else. (One will end up on the equation that Johan is experimenting with, trying to reimplement rather a lot of work.) -- As for myself, I do not really have time even to patch up new version every time the is a new release of the Hugs kernel. So if you want to make your own, entirely new reimplementation, I can only wish you good luck! :-) Hans Aberg * Email: Hans Aberg <mailto:haberg@member.ams.org> * Home Page: <http://www.matematik.su.se/~haberg/> * AMS member listing: <http://www.ams.org/cml/>