I’m on Late Night Cocoa, discussing F-Script 2.0 with Scotty of the Mac Developer Network. You can listen to us here.
Archive for October, 2008
I just created a F-Script group on Google Groups. You are invited to join and to use it for technical questions or discussions about F-Script and related subjects. This is also the place where you can get notified of the latest releases.
You can access the group at http://groups.google.com/group/f-script
F-Script is mostly latently typed and, as such, could benefit from a type inference system. Among other things, type inference can be used to detect a number of programming errors at compile time (which is nice) without cluttering programs with explicit typing.
Creating such a system for F-Script can draw from techniques already in use with some latently typed languages. Beside, in the case of F-Script, there is a way to improve the efficiency of these techniques to produce a powerful and effective type inference system. The key point is that while F-Script code is largely exempt of explicit typing, most methods invoked from F-Script are actually Objective-C methods for which explicit typing information is often available. This means that we have a massive amount of type information we can feed the type inference system with, making it easier for it to infer new type information in F-Script code and, ultimately, to detect potential programming errors (or to help with automatic optimization, etc.)
This interesting approach is presented by Andrew Weinrich and Ben Liblit, from the University of Wisconsin-Madison, in « Type Inference in Mixed Compiled / Scripting Environments ». In particular, they describe how it is implemented in
flint a type checking and static analysis tool for F-Script under development.
Programs written in statically-typed languages are commonly extended with scripting engines that manipulate objects in the compiled layer. These scripting environments enhance the capabilities of the program, at the cost of additional errors that would be caught by compile-time type checking. This paper describes a system for using type information from the compiled, statically-typed layer to perform type inference and checking on scripting code. To improve the quality of analysis, idiomatic rules based on common programming patterns are used to supplement the type-inference process. A proof-of-concept of this system is shown in
flint, a type-checking tool for the language F-Script.
Dominique Dutoit has released an F-Script action for Automator. It lets you add custom F-Script code within your Automator processes. You can get it here.
The input of the action (i.e., the output of the previous action) is automatically bound to a variable named “input” in the F-Script workspace. Usually, it is an NSArray object. The output of the action is the value of the last F-Script expression executed in the custom F-Script code (automatically boxed in an NSArray if needed).
You’ll need to have the F-Script framework (download here) installed in
You can now download F-Script 2.0 alpha 6. It contains the latest developments, including:
- Better error detection and reporting when defining new classes
- Support in the runtime for subclassing F-Script classes in Objective-C
- A literal syntax for hexadecimal numbers (finally!). Standard Smalltalk syntax; e.g.,
- Support for using the
nilas a receiver
- Various internal improvements
In addition, there will be a couple of language adjustments in F-Script 2.0, and this alpha contains one of them, as described below.
In F-Script 1.x, equality and inequality operators (i.e.,
~=) are provided for all objects. They are implemented in a category of NSObject, and rely on the standard Cocoa
isEqual: method to determine equality.
This is convenient but leads to a small amount of added conceptual complexity in a few situations related to array programming. Since life is better when even the slightest unneeded complexity is taken away, F-Script 2.0 changes this (remember that F-Script integrates array programming and Cocoa together and we want to do it with zero impedance mismatch). In F-Script 2.0,
~= are no longer provided at the NSObject level. The standard generic method for testing objects equality in Cocoa is
isEqual:, and you can use it with F-Script too.
Of course, just removing
~= and be done with it would horribly break compatibility between F-Script 2.x and code written for F-Script 1.x. In addition, we would really miss these nice operators…
Well, don’t panic. While these operators are no longer provided by default for all objects, they are implemented for a number of objects, such as NSString, NSNumber, NSDate, NSValue, FSBoolean… This covers the vast majority of current and desirable usage and you can also implement them for your own classes if that make sense.
In addition, F-Script 2.x comes with the magic needed to maintain backward compatibility with existing code in the few remaining cases where your F-Script 1.x code might send
~= messages to objects that relied on the default implementation provided by the NSObject category in F-Script 1.x. In such cases, all will work as usual and F-Script will log a warning suggesting you change your code to use
If you want to, you can turn off this magic backward compatibility system by using the
MaintainFScript1EqualityOperatorsSemantics user default, on an per application basis. For instance, to turn it off for the F-Script application, type the following in the Mac OS X terminal:
defaults write org.fscript.fscriptapp MaintainFScript1EqualityOperatorsSemantics NO
To reactivate it, type:
defaults write org.fscript.fscriptapp MaintainFScript1EqualityOperatorsSemantics YES