Feb2001 hugs98 on MacOS

[Hans Aberg]

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