Tag: Programming Language

Is it "poor taste" to include type information in function definitions?

I had wondered:

Is it “poor taste” to include type information in function definitions?
It seems like very nice documentation, but then again, maybe it is nicer rely on the inferencing engine to reduce the amount of code?
In theory you write short, easy to understand functions; in practice it isn’t always this simple though.

People kindly replied:

When you can avoid it, it is better to NOT include type information. Using a tool like “ocamldoc” will render the function and its inferred types in a real documentation format (e.g. HTML).
There are cases where you need to include type information, but they are corner cases.

— Sylvain

Interface files (.mli) are usually the main place for documentation. Within the .ml files, you can explain your algorithms but it’s usually just plain comments, not so much type annotations.

— Martin

As to the matter of “taste”, note that this practice is not idiomatic in Ocaml, in contrast to Haskell where it seems current. I’m not sure if that’s your case, but people coming to Ocaml from Haskell may at first tend to exaggerate on this aspect…

— Dario

Chicken: the transition to hygienic macros and a real module system is complete

With the most recent commits (4.4.4), chicken is now consistent in the way core forms are handled. There are no hard-coded special forms and everything can be redefined, reexported and modified on import. Syntax may now also expand into module forms (if at toplevel, local or nested modules are still not available and not strictly necessary).
So, the transition to hygienic macros and a real module system is hereby complete…

— Felix

Keywords added to MIT-Scheme

I’ve [Joe Marshall] added `keyword’ objects to MIT Scheme in a way that I hope keeps everyone happy. A keyword is a self-evaluating symbolic token, much like a symbol, but it never needs quoting because it can never mean anything but itself.
The reading and printing of keywords is controlled by the variable *keyword-style*, which can be #f or one of these symbols: cl, dsssl, srfi-88, both
If *keyword-style* is #F (the default), then there is no way to read keywords, and they are printed as #[keyword foo].
If *keyword-style* is ‘cl, then tokens with a leading colon are considered keywords and keywords are printed with a leading colon. Symbols with a leading colon are printed with vertical-bar quotes
and you can create symbols with leading colons by using vertical-bar quotes.
If *keyword-style* is ‘srfi-88, then tokens with a trailing colon are considered keywords and keywords are printed with a trailing colon. Symbols with a trailing colon are printed with vertical-bar quotes and you can create symbols with trailing colons by using vertical-bar quotes.
‘dsssl is a synonym for ‘srfi-88
If *keyword-style* is ‘both, then either syntax is acceptable for reading, but the cl syntax will be used in printing. (Putting a colon on both ends would be weird, so don’t.)

(via MIT-Scheme-devel)

How are DLLs used on Cygwin 1.7?

Over the weekend I needed to set up a R6RS Scheme interpreter on Cygwin. It came down to either PLT or Ikarus. Both seem to be straightforward builds but I couldn’t make PLT happy so I went with Ikarus instead. It was a very simple and straightforward configuration and took maybe a minute to build. Once things were clearly working fine I figured I would try to get some of Ed’s OpenGL (box2d-lite and agave) demos running just for the fun of it.
Both of the programs depend on the GL and GLUT libraries. At runtime the correct DLL is loaded depending on the OS type. There wasn’t a setting for Cygwin so I added one. The thing was that I specified the wrong file name: /usr/lib/libGL.dll.a and /usr/lib/libglut.dll.a.
It was an uneducated guess in the first place. I figured there would be a one to one mapping. After Marco kindly kicked my butt on the Ikarus list though, by asking some basic questions like has it ever worked and have I checked out the difference in error messages, I got me thinking that I should have read up on this.
The Cygwin documentation here and the Redhat documentation here seem to explain it… Windows DLLs need additional information to be linked against. On Cygwin, when GCC sees .dll.a files it “knows” how to get the additional data out of them in case you want to link to Win32. Reading on in the Redhat documentation, it lists the DLL search path when you specify -L argument for GCC. In that list I saw that /bin is included. That surprised me.
It turns out that on Cygwin, DLLs that are not compiled to work with Win32 are located there. At least, this is my understanding. When you link to these DLLs though, the OpenGL demos work just fine on Cygwin with Ikarus.
Is this also your understanding? I need to dig in more to this topic.
I had been trying to get so many things working this weekend that I didn’t invest the amount of the time that this deserved, or most of those things for that matter.