The Falcon Programming Language in a Nutshell
A Falcon script can define classes and instantiate objects from them, create singleton objects (with or without base classes) and apply transversal attributes to the instances. The provides keyword checks for properties being exposed by the instances:
// A class class Something( initval1, initval2 ) // Simple initialization can be done directly prop1 = initval1 prop2 = nil // init takes the parameters of the class // and performs more complex initialization init self.prop2 = initval > "Initializer of class Something" end function showMe() > "Something says: ", self.prop1, "; ", self.prop2 end end // A singleton instance. object Alone function whoAmI() > "I am alone" end end // an instance instance = Something( "one", "two" ) instance.showMe() //"Alone" is already an instance if Alone provides whoAmI Alone.whoAmI() end
Falcon has a Basic Object Model (BOM), which is available in all the items. Objects and classes can override some methods. For example, passing an item to the > print operator causes its toString BOM method to be called, and that can be overridden as follows:
object different function toString() return "is different..." end end > "the object... ", different
Falcon supports multiple inheritance, but it disambiguates it by forcing inheritance initialization and priority, depending on the order of the inheritance declarations.
Classes also support static members that can be shared between objects of the same class and methods with static blocks that can work as class-wide initializers. Methods can be retrieved and also called directly from classes when they don't need to access the self object, providing the semantic of C++/Java/C# static methods.
It is possible to merge normal procedures with methods by assigning procedures to properties:
function call_me() if self and self provides my_name > self.my_name else > "Sorry, you didn't call me right." end end object test prop1 = nil my_name = "I am a test!" function hello() > "Hello world from ", self.my_name end end // normal calls call_me() // using the procedure as a method test.prop1 = call_me test.prop1() // or a method as a procedure proc = test.hello test.my_name = "a renamed thing" // see: proc will dynamically use the right "self" proc()
Attributes are binary properties that can be either present or not present for a specific instance or object, regardless of its class.
Attributes have a great expressive power, and in Falcon, they indicate what an object is, what it has and what it belongs to, depending on the context. For example, we can define a ready attribute that indicates the objects ready for elaboration:
// declaring an attribute "ready" attributes: ready class Data( name ) name = name function process() > "Processing ", self.name, "..." end end // create 10 processors processors =  for i in [0:10] processors += Data(i) if i > 5: give ready to processors[i] end // work with the ready ones for d in ready d.process() end
RTL provides several functions to manipulate attributes.
The has and hasnt operators check for the presence of an attribute. For example:
attributes: ready class SomeClass //... other class data ... // born ready! has ready end item = SomeClass() if item has ready > "Item was born ready!" end
The base construct of Falcon functional programming is the callable sequence, also known as Sigma. At the moment, the only sequence supported is the array, but other types of sequences (such as lists) should be supported soon.
Basically, a Sigma is a delayed call that can work like this:
function test( a, b, c ) > "Parameters:" > a > b > c end // direct test( "one", "two", "three" ) // indirect cached = [ test, "four", "five", "six" ] cached()
The call respects the procedural paradigm (variable parameters), and the array is still a normal vector that can be accessed and modified through the standard language operators and RTL functions.
This delayed call is still not a full “functional context evaluation”. The proper functional evaluation process is called Sigma reduction. It recursively resolves Sigmas from inner to outer and left to right when they are at the same level, substituting them with their return value.
Special functions known by the VM as Etas start and control functional evaluation; the simplest Eta function is eval(), which initializes and performs a basic Sigma reduction.
For example, the expression “(a+b) * (c+d)” can be written in a Lisp-like sequence:
function add( a, b ): return a+b function mul( a, b ): return a*b > "(2+3)*(4+5)= ", eval(.[mul .[add 2 3] .[add 4 5]])
The . notation is shorthand for array declarations whose elements are separated by white space instead of an explicit “,”.
Falcon RTL comes with a rich set of Etas, such as iff (functional if), cascade (which joins more standard calls in a single sequence), floop and times (different styles of functional loops), map, filter, reduce and many others.
Functional sequences can be parameterized through closure and references. For example, the above example can be made parametric in this way:
// add and mul as before... function evaluator( a, b, c, d ) return .[eval .[mul .[add a b] .[add c d]]] end tor = evaluator( 2,3,4,5 ) > "(2+3)*(4+5)= ", tor()
Traditional functional operators, such as map, filter and reduce, are supported, but the out-of-band item system expands their functionality.
Out-of-band items are items marked with a special flag through the oob() function. Although they are normal items in every other aspect, this special mark indicates that they hold unexpected, special or somehow extraordinary value traveling through functional sequences. Although this is not a direct support for monadic calculus, monads can be implemented at the script (or binary module) level through this mechanism.
Falcon also supports Lambda expressions and nested functions.
We currently are working on some extensions to make Sigmas even more configurable—for example, parameter naming (similar to Lisp field naming) and access from the outside to the unbound variables used in the sequence.
Falcon functional programming merges with OOP, as Sigmas can be set as object properties, and object methods can be used as Kappas (Sigma-callable header symbols):
object SomeObj a_property = 10 function myProp( value ) return self.a_property * value end end > "5*10=", eval( .[SomeObj.myProp 5] )
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide