cvs commit: hugs98/dotnet License.net hugs98/dotnet/doc dotnet-lib.html dotnet.html examples.html hugs98/dotnet/examples/basic Env.hs Http.hs Mail.hs hugs98/dotnet/lib DotNet.hs hugs98/dotnet/lib/Syste m Array.hs ...

sof 2003/03/02 22:31:11 PST Modified files: libraries/Hugs Prelude.hs src Makefile.in builtin.c connect.h ffi.c hugs.c input.c iomonad.c machdep.c machine.c parser.y prelude.h runhugs.c server.c server.h static.c storage.c storage.h type.c src/msc Makefile src/winhugs Makefile Added files: dotnet License.net dotnet/doc dotnet-lib.html dotnet.html examples.html dotnet/examples/basic Env.hs Http.hs Mail.hs dotnet/lib DotNet.hs dotnet/lib/System Array.hs Console.hs DateTime.hs Enum.hs MarshalByRefObject.hs Object.hs ObjectTy.hs String.hs StringTy.hs Type.hs TypeCode.hs TypeTy.hs ValueType.hs Xml.hs dotnet/lib/System/Collections IEnumerator.hs dotnet/lib/System/IO Directory.hs DirectoryInfo.hs dotnet/lib/System/Xml XmlAttributeCollection.hs XmlNameTable.hs XmlNamedNodeMap.hs XmlNode.hs XmlNodeTy.hs XmlReader.hs dotnet/tools App.cs AssemblyInfo.cs HsOutput.cs README.txt TypeInfo.cs src builtin.h src/dotnet .cvsignore HugsServ.cpp HugsServ.h HugsWrapper.cs Invoker.cpp Invoker.h Makefile hugs.rc options.h prim.cpp prim.h runhugs.rc Log: .NET interop + FFI support This commit adds interop support for the .NET platform. It merges the modifications made to the Hugs sources by Hugs98.net, but provides deeper integration by letting you bind to .NET functionality directly via the FFI: foreign import dotnet "static method System.Environment.GetEnvironmentVariable" getEnv :: String -> IO String removing the need for writing out those small marshalling wrappers you have to with Hugs98.net. The supported import decl syntax is as follows: foreign import dotnet "{static}? {[ctor|field|method]}? {'['assembly']'}?classOrFieldOrMethName" funName :: {FFIType ->}* {IO}? FFIType where FFIType = usual stuff + (Hugs.Prelude.Object a) + Prelude.String Support for letting you export Haskell code as .NET classes/methods via FFI declarations is in prep. Hope no one minds me integrating these changes; the source mods are conditional on DOTNET being #defined. [The dotnet/doc/ + dotnet/examples directories have yet to be fully sync'ed up.] Revision Changes Path 1.25 +7 -1 hugs98/libraries/Hugs/Prelude.hs 1.38 +1 -1 hugs98/src/Makefile.in 1.50 +6 -499 hugs98/src/builtin.c 1.69 +17 -3 hugs98/src/connect.h 1.25 +121 -3 hugs98/src/ffi.c 1.118 +11 -10 hugs98/src/hugs.c 1.60 +16 -2 hugs98/src/input.c 1.47 +45 -21 hugs98/src/iomonad.c 1.80 +14 -15 hugs98/src/machdep.c 1.16 +22 -2 hugs98/src/machine.c 1.37 +6 -2 hugs98/src/parser.y 1.43 +5 -9 hugs98/src/prelude.h 1.14 +3 -4 hugs98/src/runhugs.c 1.29 +18 -11 hugs98/src/server.c 1.8 +12 -2 hugs98/src/server.h 1.144 +223 -149 hugs98/src/static.c 1.64 +25 -8 hugs98/src/storage.c 1.53 +86 -33 hugs98/src/storage.h 1.67 +17 -2 hugs98/src/type.c 1.24 +2 -2 hugs98/src/msc/Makefile 1.13 +1 -1 hugs98/src/winhugs/Makefile

Sigbjorn Finne
This commit adds interop support for the .NET platform.
Looks interesting! However, just one minor point:
dotnet/lib DotNet.hs dotnet/lib/System Array.hs Console.hs DateTime.hs Enum.hs MarshalByRefObject.hs Object.hs ObjectTy.hs String.hs StringTy.hs Type.hs TypeCode.hs TypeTy.hs ValueType.hs Xml.hs dotnet/lib/System/Collections IEnumerator.hs dotnet/lib/System/IO Directory.hs DirectoryInfo.hs dotnet/lib/System/Xml XmlAttributeCollection.hs XmlNameTable.hs XmlNamedNodeMap.hs XmlNode.hs XmlNodeTy.hs XmlReader.hs
These hierarchical names look rather strange. Why "System" as a base dir? Wouldn't System.DotNet be perhaps more reasonable, ala System.Posix for instance? Also, for example, how do these submodules compare with the more "obvious" locations: System.Array Data.Array System.String Data.String System.Xml Text.XML although, since they are .NET-specific, perhaps they belong down another level, e.g. System.DotNet.Text.XML Regards, Malcolm

Just to clarify -- this is a separate toplevel namespace
(mirroring the .NET Framework). Should conflicts become
an issue a prefix will be added.
--sigbjorn
----- Original Message -----
From: "Malcolm Wallace"
Sigbjorn Finne
writes: This commit adds interop support for the .NET platform.
Looks interesting!
However, just one minor point:
dotnet/lib DotNet.hs dotnet/lib/System Array.hs Console.hs DateTime.hs Enum.hs MarshalByRefObject.hs Object.hs ObjectTy.hs String.hs StringTy.hs Type.hs TypeCode.hs TypeTy.hs ValueType.hs Xml.hs dotnet/lib/System/Collections IEnumerator.hs dotnet/lib/System/IO Directory.hs DirectoryInfo.hs dotnet/lib/System/Xml XmlAttributeCollection.hs XmlNameTable.hs XmlNamedNodeMap.hs XmlNode.hs XmlNodeTy.hs XmlReader.hs
These hierarchical names look rather strange. Why "System" as a base dir? Wouldn't System.DotNet be perhaps more reasonable, ala System.Posix for instance?
Also, for example, how do these submodules compare with the more "obvious" locations:
System.Array Data.Array System.String Data.String System.Xml Text.XML
although, since they are .NET-specific, perhaps they belong down another level, e.g.
System.DotNet.Text.XML
Regards, Malcolm _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs

"Sigbjorn Finne"
Just to clarify -- this is a separate toplevel namespace (mirroring the .NET Framework). Should conflicts become an issue a prefix will be added.
Ah, I see - this is the standard .NET namespace, as opposed to the standard Haskell namespace. That's fine, no problem. Personally, I would still prefer a DotNet prefix, mainly to indicate that these are platform-specific libraries rather than ones that might be assumed to be platform-neutral. We already see many newbies assume that because e.g. fromInt is in the Hugs Prelude, then it must be standard Haskell, so I predict already the day when someone asks "Why doesn't GHC accept an import of System.Array?" or similar. Actually, I do notice a minor conflict already - System.Console is a directory in the base package, and it is also a module in the dotnet package. Although this is OK by the hierarchical rules, it may be a little confusing that the module does not simply re-export (some of) the contents of the directory, because in fact they live in different packages. Regards, Malcolm
participants (4)
-
Alastair Reid
-
Malcolm Wallace
-
Sigbjorn Finne
-
Sigbjorn Finne