Tuesday, July 31, 2007

Windows and the Tea Shell

The Tea shell for the JVM has been available as version 3.2.2 for some months now.

There is no problem running the shell under Windows if you had Tea 3.1.0 up and running.

The first problem is that 3.2.2 includes no TEA.BAT in the tgz file. Just get the old 3.1.0, extract the bat file and update it to suit your install.

Tea must find a GNU jar for regexp and a Xerces jar for XML parsing. I reference them explicitly in a temp CLASSPATH in that BAT, e.g.,
set CLASSPATH=%TEA_BASE_DIR%;%TEA_BASE_DIR%\xerces-1.4.4.jar;%TEA_BASE_DIR%\gnu-regexp-1.0.8.jar;%CLASSPATH%

Tea is intended to bring multi-paradigm programming to the JVM. It is a java-based functional langauge with extensions for procedures and classes. This is another language intended to be component 'glue'. The selling point is that it is in java.

Other multi-paradigm languages either have their own compiler written in C or are using libraries implemented in C. Tea is java so one positive is that you get javadocs. The tea reference javadoc lists about 20 functions as the language core.

As a functional language Tea is intended to make the use of closures easy: functions are first-class objects as in JavaScript. In many respects the object system is like Smalltalk: members are private; methods are public. Code blocks in {} come with their contexts as closures. Every statement is at least a word which invokes a function. Lists are like Smalltalk collections: they can contain objects of mixed types. Unlike JavaScript, there is no literal notation for functions, but they can be loaded at will from jars or from raw source files using the source word.

Variables are not pre-typed, but they must first be declared with a define. The define word is over-loaded 3-fold: define a variable; declare a variable to have a value; define a variable to be a function as declared. The define word returns what it defines (it, too, is a function.) The set! function is used to re-assign a variable and anonymous functions can be had using the lambda function. Much like Smalltalk's collect: there is a map function to iteratively apply a function to a list. For lists of lists there is the function map-apply. Unassigned vars are returned with the value null. But note this sigil use:
define nativeParser $null

The syntax is very simple. Statements end at end-of-line. Comments start with octothorpe. You get variable values with a prefixed $ sigil. Other scripters will feel comfortable. The type tests use function? string? symbol? int? pair? which is extended to boolean tests as same? not-same? null? and not-null?. Lists use parentheses and, thankfully, no commas.

Lists are very much Scheme, as in
define testPair [cons "first" "last"]
where [car $testPair] gives "first and [cdr $testPair] give "last".
List are built from such pairs; the last pair in the list references a pair where both slots are null. With syntactic sugar our test list can be declared as
define testPair ( "first" "last" )

The Smalltalk procedural style is made possible by using the $ sigil.
For example, if you have a database connection in variable conn then
define sqlStmt [$conn statement]
returns a statement. The difference from Smalltalk can be seen when the query is created: there is no need for a colon, as in
define dataSet [$sqlStmt query "SELECT client_id FROM new_customers"]
but what is different is the use of [...] and not as a code-block { expression }. What is happening, of course, is a command substitution as in Tcl. The {} are used to defer evaluation as in a while loop.

The load function is rather like Jython: it gives access to java classes including Tea functions in those java jars.

But why would you use Tea? One possiblity is that you already know Scheme and Tcl or need a rapid way to work with closures in the JVM. But why not simply use JavaScript? One curiousity is that Tea is promoted as a language for rapid-prototyping, but in Lisbon it has been used for major banking and telco systems. But was it used only as glue code? Not at over a million lines according to Tea's own 'whitepaper'.

One observation: Tea is almost the opposite of Curl and Rebol. It is only now adding GUI and networking. But why add them if this is a scripting language for the JVM? It must be irresistable. Some people spoil their kids; some people spoil something else. And most of us seem to bloat if we are not kept on track ... and reminded that what we leave out can be as important as what we put in.

In Tea you get a hint of what the future holds if we shift away from 'C' and the OS to life with a VM.

Likely Tea will never have the momentum to break into North American markets unless it is embraced by a major player. It does have an advantage over Jython: there is no shifting Python beneath it. Then again, functional may becoming fashionable... even at Microsoft.

If you are a secret Schemer masquerading in Java or someone who can't thrive without a little Tcl, you may want to have some Tea... and lemon? Ah, right. They already added the syntactic sugar ...

PS There is another TEA which is the Tiny Encryption Algorithm and yet another Tea that is a strongly-typed templating language for managing servlets from the Disney TeaServlet project at what was once GO.COM Green tea. Black tea. Chá, anyone?

Monday, July 30, 2007

The Zend of PHP

July 2007 saw the release of the 1.00 'production' release of the Zend Framework. To quote:
The Zend Framework project has developed solutions to solve frequent needs of web application developers, including the following areas:

* Powerful MVC framework
* Database access solution that balances ORM with efficiency and simplicity
* Lucene-compatible search engine
* Advanced I18N support
* Robust authentication/authorization classes and input filtering
* Rich web services client interfaces, including Google Data APIs and StrikeIron
* Many other useful classes to make you as productive as possible
* Thorough and high-quality test suites and documentation
* Open-source development process with an active community provides continuous review and testing


One of the many criticisms of PHP as a scripting language for web development is the lack of enforcement of separation of content from logic. Now Zend proposes an MVC framework for PHP.

MVC (Model-View-Controller) is usually associated with Smalltalk and the thick client even before client-server, let alone the web and RIA. MVC used in conjunction with frameworks such as Struts for J2EE is MVC in name only. The concern is this: keeping domain models and business models from being entangled in presentation issues. The web MVC variant is usually called Model 2 MVC. In Smalltalk, the evolution of MVC to Morphic (from Self) or to M/V without controllers (Cincom Smalltalk Widgetry) is a topic in itself. Dolphin Smalltalk has MVP (Model-View-Presenter) and provides a nice introduction at their Object-Arts site.

PHP starts with a bad rap for not having adequate modularity: it still lacks namespaces. Smalltalk itself is evolving to embrace namespaces and away from classic MVC so we have something curious occurring.

Here is what the Zend Framework appears to offer. I quote:
<qt>
Put simply; models contains your domain specific code such as a user class, views contains your templates, or view scripts as they are called, and controllers contains the files that process data to and from the models and views. Following this simple practice not only introduces a design pattern into your programming arsenal, but also organizes your code in a way that makes it more maintainable than a great many existing PHP applications.
</qt>
What we really have here is the front controller pattern that arose in J2EE in frameworks such as Struts where it is combined with a Command pattern.

In terms of security, PHP with the Zend Framework remains a filtering approach. What is not yet clear to me is how this chaining of filters and validators constitutes a framework. A Framework is not just a library of classes and certainly not a cookbook of recipes. A Framework can usually be understood as providing for the interoperation of services identified with components by enforcing constraints. The constraint might be: this service must be presented as an interface (now you are constrained to implement against a minimal abstraction.)

To have a framework it is not enough to have a class library providing a mechanism which removes ? and & from PHP URL's or adding more filtering.

You may want to check out the Zend Framework site with its webinar and demo wiki application. The site also links to manuals for the API and a developer reference. The latter opens on Access Control Lists; scroll down to find Controllers. What is missing is an overview of the framework such as is readily communicated by the Rails folks promoting Ruby. Having the familiar directory structure in itself does not establish 'convention-over-config'.

Perhaps whether you have 'c-over-c' comes down to 'GUI-shootouts', but that sort of thing does not impress architects concerned about security+maintainability. Saying you are using a 'framework' only goes so far. If what you meant is a library of classes that will be familiar to Struts developers, then why not Java with JavaServer Faces with jars, ears and Maven with the Spring 2.0 framework for security? What ties anyone to PHP in a business setting?

PHP has likley gotten to where it is because it posed no steep learning curve. And then it got a bad case of bloat. What results could be called 'wading through muck' rather than 'slogging uphill'. But when I arrive to perform on a maintenance contract, knowing what the framework was and that it was respected means a whole lot. Knowing what libraries were used gives very little indication of what you are in for.

Saturday, July 28, 2007

Example is the Curl developer's example macro


This little Curl script could be the web developer's best friend.
As a web content language, Curl 5.0 provides a powerful RIA platform. This applet using the macro 'example' might convince you.
The macro 'example' creates a live code example in your browser which will open a child applet window.
First we run the following code snippet as an applet in the Curl IDE, embed it as a web applet or launch it with the Curl RTE with a dbl-click in a file explorer.
{curl 5.0 applet}
{applet license="development"}
{curl-file-attributes character-encoding = "windows-latin-1"}
{import * from CURL.DOC.CONTENT.ACCESSORIES}
{example 
{bold Hello {italic there}! }
}

Example is a Curl macro. The result is a web page in which to execute Curl, revert and save Curl applets. It you know something slicker than this, I would want to see it.
You may notice that in my example I have thrown in a {VBox }
I could hit REVERT and I would be back at the original. Here is the result:



If I like my changes, I can save the code from the web page with 'Save Applet'.
In practical terms this also means the ability to create web-based developer documentation with 'live' code snippets. And the eample maco nests: you can have a nippet which is used to demonstrate another snippet.
Curl comes with a visual test framework, but this little 'example' macro should give you a hint of what is possible in Curl 5.0
Note that 'example' is made available by importing the Curl package
CURL.DOC.CONTENT.ACCESSORIES

Tuesday, July 24, 2007

PDC Visual Prolog 7.1 released

If you recall the days of Borland Turbo Prolog (there were books on Turbo Prolog in bookstores and libraries back then) you may not be aware that it lived on as PDC Prolog (Prolog Development Center)

Much like the first home of Prolog at prologia.fr, this is a web site that does no appear to be the site of a language implementation, let alone Prolog.

Prologia IV is a language for Constraint Logic Programming in which Prolog is a limiting case. The company now focuses on industrial applications. The same is true at PDC. The other notable company with a Prolog more widely used is ILog with JRules.

PDC has focused on domain specific languages (DSL). Visual Prolog itself has fostered another company, EZY Prolog which looks to simplify using VIP.

Visual Prolog for Windows GUI has always required as much knowledge of Windows GUI programming as would be required of a C++ developer although much better suited to RAD.

What makes Visual Prolog worth exploring is the way in which OOP has been brought to a declarative language with hooks to user interaction. It is an implementation which continues to evolve as an industrial strength framework. It is worth comparing to the Logtalk framework which brings a remarkably flexible OOP option to almost any Prolog implementation (PDC and Strawberry are notable exceptions.)

Logtalk can be employed to specify a prototype-based framework: it lives in symbiosis with a prolog implementation. PDC Prolog is fundamentally class-based, but its specification of interfaces is so flexible that nothing much is lost: a interface can be used in an implementation of a class even if not declared by the class - which provides almost as much as working with objects as prototypes. There are other type-based OOP projects with a similar strength: TiScript and the XOTcl extension to Tcl which allows an object of a class to also declare its own attributes.

Some years ago I built a dynamic aerobatic squadron generator for a flight simulator in PDC Prolog without objects ( takeoff from any airport, perform manoeuvres, land at an airport. It used to run at the home airfield museum display of an aerobat team. That was done in Prolog without an object-framework or constraints (but at least did not require XML, being in Prolog.) If I ever find time or a sponsor to re-write it, it would be hard-sell to move to Oz if that meant losing the object-flexibility of PDC7.1 or Logtalk with any Prolog with constraint resolution.

The PDC install ran flawlessly (an installer for a smart language should be as smart) which certainly is not always the case with interesting languages, e.g., Python or its CMS, Plone.

PDC also comes with its own external database framework which has always been a favorite feature with me and worked very well for my dynamic squadron generator.

Even if you don't remember Turbo Prolog, check out PDC. If you use Eclipse, checkout AMZI! Both sites have great instructional resources. If you need open-source, there is, of course, Logtalk+SWI+java

halt.

Sunday, July 22, 2007

XOTclIDE: the IDE that is almost Smalltalk

I copied XOTclIDE82.kit into my \kits directory for ActiveState Tcl/Tk for Windows.
A double click on the kit ( I already had Tclkit in the PATH for Tcl\bin ) and I was politely asked whether to launch Simple or with Version Control. Simple was fine for now.

The result was a Transcript, a ClassBrowser and I was one click from a WorkSpace.

If you have ever used Smalltalk, this will sound very familiar.

And if you have never used Tcl with the GUI Tk you deserve to take an hour or two and see what simple GUI-driven control of admin tasks can be like.

XOTcl is extended MIT OTcl. There had been a few GUI extensions to Tcl rather as there have been for Python. But these extensions are principled: they do not simply provide a wrapper to a GUI library. The Mozart-Oz system is very much built on principle and exploits Tcl/Tk in its QTk, but lacks an IDE (SICStus Prolog also has a Tcl interface.). Tcl upvar and uplevel are not a replacement for the Mozart implementation of Oz, so my question becomes: does this rich environment impede or foster useful Tcl scripting?

An IDE as rich as that found with most Smalltalk implementations tends to be only as useful as its GUI layout tools and/or GUI specification framework. If it is awkward to tie event handlers and callbacks to widgets and worse to edit or maintain them, then little is gained by having object inspectors and dynamic workspaces. Tcl/Tk itself is marvelously simple (Jython comes to mind by way of comparison - or Rebol or Curl RTE's.)

The XOTcl documentation presents a very flexible, dynamic object framework, but the XOTcl components are file-based Tcl packages which must be registered with Tcl. Tcl is about component integration, but it's own integration of packages is a weak point, which is not to say that packaging and load dependencies cannot also be a headache in Smalltalk.

If I find the learning curve not too steep ( if Curl, the MIT web content language, has a gentle curve then Rebol is like learning to surf: anyone can paddle out ... ) then I will add a header page at eclectic-pencil and see if I can't put up a few useful markers across the terrain.

If you have a favorite language with no non-commercial IDE and are not in love with Eclipse, XOTclIDE does show what a mature IDE can offer a developer in a dynamic language. The only development environment to interest me as much as this was the outline-browser of Strongtalk.

PS Eclipse, of course, evolved from IBM VisualAge Smalltalk ...

Saturday, July 21, 2007

Array-like objects in prototype-based JavaScript

In the course of a recent exchange on what constitutes prototype-based as opposed to class-based in OOP, I took a moment to look at a few neo-JavaScript interpreters.

An array-like object is an object which satisfies some part of the interface which an Array prototype would specify. First create an object obj = {} and then add to the object with obj[0] = 1 and finally test the object for type, length, constructor and prototype.

All of the interpreters respond that obj is of type Object. One reports that obj now has a length of 1 with no constructor and Object as prototype. The others responded that length was undefined with no prototype but a constructor of type Object.

The downside of this little exploration has been a re-reading of Chapter 7 on OOP in Peter Van Roy's CTM. My estimation of that otherwise fine book has suffered.

It seems that the first thing that goes wrong in Chapter 7 is the good intentions.
One good intention is to warn you that object-purity is not the answer and another that class inheritance is not the answer if the subclasses violate the type of the superclass. If type offends you, then substitute "fails to respect an invariant of a superclass". And in passing, if you have multiple inheritance, only inherit from unrelated classes.

Anytime inheritance trumps composition or runs deep where it need not do so, a design suffers and maintenance and evolution become problematic. Classes for a GUI framework where inheritance may naturally run deep can be the worst place to learn OOP. Ditto for collections and containers. The ease of subclassing is the undoing of many projects. And the ease of extending base classes. And failing to respect a separation of concerns.

However, Class itself typically has only one subclass: Metaclass and Class itself likely lies only 3 or 4 classes deep in the Object hierarchy.

Peter Van Roy fails by misconstruing object-oriented as class-based and ignoring prototype-based. Had the author given any attention to Self, JavaScript or Logtalk, this could not have happened. Instead we have Smalltalk-80 and Java with a very short note on object-based. There is nothing about "add-on" OOP although it is common as rain in Prolog itself (perhaps because it was such a vice in C++.) When it comes to his reports of failures, just remember all of those industrial-strength Prolog apps which have been re-written by imperative programmers. A grain of salt is in order.

The use of Smaltalk-80 is problematic because Smalltalk has no ISO standard as does Prolog. What Smalltalk has are implementations. Had the author looked at VisualAge Smalltalk he could have cited a plethora of types: IBM Smalltalk came with 5 types of subclasses. Not to mention that a subclass of nil ( Object and any light-weight objects which serve as proxies) form at least two types as does any object implementing >>doesNotUnderstand. You could argue the same for classes with class instance variables as opposed to those with only instance variables or class variables. Smalltalk has runtime dynamic type-resolution and so is not strongly-typed in the sense of the compile-time type resolution of many other languages. An untyped language would not be more powerful than the alternatives: it is in theory more restricted, being the language with one implicit type, the 'any' type or the 'just-cannot-say-yet' type. It certainly could not easily implement the power of multiple value-side datatypes for single-type variables.

So one suspects that the consideration of Smalltalk-80 is consideration of a strawman. Indeed the dangers of subclassing for inheritance are presented as the dangers of side-effects and an opportunity is missed.

The object-orientation that is presented is a minimalist class-based approach with no method overloading within a class. This should have struck me as absurd in a language inspired by Prolog.

One suspects that the target is the unnamed sin of C++. But Objective-C is ignored, as is Lua and embedded scripting in general. Java is given the most attention and C# is ignored, itself a regrettable choice.

That the entire book ignores JavaScript may be a symptom of ignoring scripting. But this is a book on techniques and not just algorithms: Concepts, Techniques and Models.

The warning against 'structure' versus 'type' inheritance is just hollow. Substitute 'module' for 'class' and 'dependency' for 'inheritance' and try to convince yourself of this in a book that stresses the importance of modules and in light of the importance of modules in Prolog and imperative languages. The reader would be better served to look at class-type declarations that permit 'mixed' and 'convenience' modules to be constructed ( something more awkward in languages where module equates to physical file directory ). Of course what is a directory, but just the kind of unprincipaled 'structure' which the author deplores. One might as well deplore the use of 'path' in navigating these structures as 'path' has an equally unprincipaled order (but putting '.' at the head of classpath is deplorable.)

What is curious is that Van Roy ignores significant similarities between Oz and Smalltalk in the area of overloading methods within a class. Smalltalk with optional Types, Strongtalk, does provide overloading. The need for overloading in Smalltalk is revealed by counting calls to >>class or indexing into the Smalltalk SystemDictionary with symbols or calls to >>isKindOf: It is an aspect of polymorphism that should not be ignored. It is present in typed Prolog.

If MIT Press goes for a second edition of CTM, here is hoping that this entire chapter gets a re-write ( including the tell-tale editing error which seems to reveal that some material in the chapter was destined for another location in the book.) By that time it may be the JVM and .NET who deserve attention if Scala develops a following. A book with chapters on declarative and OOP cannot plausibly ignore Logtalk.

Objects alone are not the answer for distributed or concurrent or collaborative computing. Nor is class-based object orientation. But objects, whether referred to as records or associative arrays or hashtables are part of the answer wherever functions are first-class objects.

Oz is just too important to the case for multi-paradigm programming to have its only book and such a significant book marred by such a treatment of object-orientation. Had the author gotten past Smalltalk-80 to Self and JavaScript, the objectives of CTM would have been better served. As it stands, the book ignored distinctions between Java4 and Java5 which cannot be ignored as we move to Java6. If ECMAScript leaves prototype-based and Rebol3 leaves prototype-based it will be all the more important to assess the extent to which class-based is the answer for effective object-orientation.

A chapter on Logtalk could be the framework on which to hang the trio: Concepts, Techniques and Models. There is no need to hang the strawman.
PS
Oz itself has been called 'concurrency-oriented'; nothing prevented Oz from being prototype-based as was Rebol (prior to Rebol3) and with the flexibility of Logtalk+Prolog.
For discussions see Crockford and OZ Classes on principal

Thursday, July 19, 2007

Dialogs in Curl and in the Curl Documentation Viewer

The Curl Documentation Viewer can be a bit of a challenge if you lack a Curl book.
Here is a translation of the code docs for showing a Dialog as found in the Dialog (class) item.

show  : Show a dialog in its own window.
public  
{Dialog.show
title:String = {host-localize "Pop-up Window"},
modal?:bool = true,
center?:bool = true,
owner:#View = {View.get-default-owner},
style:DialogStyle = DialogStyle.standard,
large-icon:#Pixmap = null,
small-icon:#Pixmap = null
}:void

The first thing we need is an instance of a Dialog which we can show.
We get that with {Dialog new} or the short-cut, {Dialog}

So we can attempt to execute the documented method in the Curl IDE as
{{Dialog}.show
title = {host-localize "Pop-up Window"},
modal? = true,
center? = true,
style = DialogStyle.standard,
large-icon = null,
small-icon = null
}

You may notice that I have torn out the option for the default view owner when I tore out the type declarations.

But the Dialog is not very promising when you execute it: it is barely visible.
Try this.
{let vbox:VBox = {spaced-vbox width=2in, margin=5pt}}
{{Dialog vbox}.show
title = "Pop-up Window"
}

Now we almost have something like a Dialog to show. Add {text as follows:
{let vbox:VBox = {spaced-vbox width=2in, margin=5pt,
{text "Give us a Dialog to show"}}
}
{{Dialog vbox}.show
title = "Pop-up Window"
}

As my Grandpa would say, "Now you're cooking with gas!"
And hopefully the class-side documentation makes a little more sense to you than it did before.

The expression {Dialog vbox} is not the most common idiom.

More common might be
{let dialogTest:Dialog = {Dialog vbox, border-width = 2pt}}
{dialogTest.show
title = "Pop-up Window",
center? = true
}

And perhaps we should be using
{let dialogTest:Dialog = {Dialog vbox, border-width = 2pt}}
{value
{dialogTest.show
title = "Pop-up Window",
center? = true
}
}


{Dialog vbox} is a curious expression. It can be used because the default constructor for the class Dialog is defined with '...' for rest arguments.
In our case, the 'rest' of the arguments is a VBox. Dialog itself inherits from classes designed to provide functioning for graphics containers and for traversals.

It is curious to note that MessageDialog is not a subclass of Dialog, but a subclass of one branch of the multiple-inheritance tree of Dialog: the class StandardActiveTraversalContainer, which inherits from Frame and thereby BaseFrame which is itself the super class of MessageDisplay, the parent of MessageDialog.

FileDialog may also surprise you: it is not really a class so much as a module ( there is a variant of JavaScript, TiScript, where a Type can also be used in just this way.) It is both abstract and final.

This may be worth noting if you are interested in running Curl outside the Browser in the way that Mozilla XUL applications run outside the browser. In this case sub-applets and multi-applet behavior become important, not Dialogs. In Microsoft Windows, modal Dialogs have a troubling past. They have their counterpart in the MDI 'solution'. It is reassuring that in Curl we will be working with smart Frames and Boxes instead.

See the notes on detached-applets and the use of View. For a minimal detached-applet, you can simply use a CommandButton as follows:
{curl 5.0 applet}
{import * from CURL.GUI.BASE}
{import * from CURL.GUI.CONTROLS}
{View
{CommandButton
label = "&Click Here",
style = "standard",
{on Action at btn:CommandButton do
set btn.label = "Test with a &Click."
}
},
visibility = "normal",
{on WindowClose do
{exit}
}
}

If you are using the IDE, save the file as a detached applet with the .dcurl file extension.

To run a script using
curl.exe -l myscript.xcurl
use
{curl 5.0 script}
{import * from CURL.GUI.BASE}
{import * from CURL.GUI.CONTROLS}
let win:View = {View
{CommandButton
label = "&Click Here",
style = "standard",
{on Action at btn:CommandButton do
set btn.label = "Test with a &Click."
}
},
visibility = "normal",
{on WindowClose do
{exit}
}
}
{win.show}
{event-loop}

If you are using the Curl shell console, you will have to click back into the console after sending >>show in order for Curl to evaluate {event-loop}

Tuesday, July 17, 2007

Curl and Perl regexp

One of the nice thinga about Curl, the web content langauge, is that when you use {regexp-match ... you will be using the regexp flags that you know from Perl.

I will put a page on Curl regexp over at eclectic-pencil under the Curl/Surge RTE pages and {import * from CURL.LANGUAGE.REGEXP }

My document links for Curl are also kept there.

Sunday, July 15, 2007

a note on Polymorphism in Rebol and Oz

I have put a page on Polymorphism in Rebol and Oz with some mention of Strongtalk at eclectic-pencil

It really does not do justice to the richness of Rebol and may presuppose some familiarity with Smalltalk. All are available as freeware on the web.

If you work in JavaScript or C# there will be a lot to interest you in the trio of Oz, Strongtalk and Rebol. TiScript, for example, is a JavaScript variant which rejects prototype-based in favor of simple modules.
If you are looking at the new languages coming available for .NET and VisualStudio and want to see multi-paradigm programming then Oz is the place to start.
If you find you don't quite get Oz and the whole Emacs thing, start with Rebol.
If you don't want another way to think about web programming, just an alternative to JavaScript+CSS+HTML+whatever, download the Curl RTE and IDE.
I had been almost sold on XUL + JavaScript or XAML + C# and then I took a look at both Rebol and Curl.
In the next few days I will post something on the beauty of "Quick" Tk in Oz. If you were ever taken with Logtalk+Prolog or Datalog+RDF you will appreciate td(...) and lr( ...) as td( lr( ... )) i.e. layout of widgets is top-down and left-right...

Saturday, July 7, 2007

Sciter, TiScript, DyBase and JSON

If you have ever looked at XUL for Mozilla, you owe it to yourself to look at an alternative way of declaring a UI with JavaScript.
TiScript is an extended-JavaScript with a few twists and it works with DyBase to provide scripting and persistence for Sciter.
Sciter is from Terra Informatica, whom you may know for BlockNote or their SqlLite wrapper.

What Sciter offers is an alternative to JavaScript+DOM. Instead of loading the DOM for an HTML page, the strategy is to use TiScript with a few extensions to CSS.

Sciter offers web developers 8 DOM and Window classes:
  • Element - DOM element. All HTML elements including the document root, frame, inputs, etc. are elements in Sciter.
  • Attributes - a collection of named attributes of any html element.
  • Style - a collection of style attributes applied to any element.
  • Image - bitmap image objects on which you can draw using Graphics methods
  • Graphics - an object wrapper for drawing primitives for drawing on any Element or Image
  • View - represents Sciter window (the main Sciter window and Dialog are views)
  • Event - represents the current UI event.
  • Sciter - a global object holding Sciter application specific methods.


Top level windows are represented by View objects in Sciter. Both the main window of the Sciter.exe application and the client area of the X-Sciter.dll sandbox window are views. Dialog windows also have their associated views.

Each view has a root property which is the root element of the loaded document. The root element in Sciter is the <HTML> element of the loaded document and there is no dedicated Document class because in Sciter the Document is an element tree composed of an element and its children.

Frames and framesets are also ordinary DOM elements. Each has a single child element: the root element of the loaded document. If the document is loaded into a frame, the parent property of the root element of the document will refer to that containing frame element.

These simplifications are intended to make up for inherent weaknesses in how CSS+Javascript is used in web layout to complement simple HTML.

This interests me while I am looking at the separation of concerns which is attempted by Mozilla with XUL for Firefox and for other XPCOM applications outside the browser which use the XPFE (Cross-platform front-end) framework. Sciter+TiScript+JSON is also interesting when contrasted to Rebol/View and the upcoming Liquid-GLayout marriage for Rebol (Rebol does not yet have a cross-platform IDE - which is something else Rebol shares with Oz and Mercury.)

The major change that you will find in TiScript is the use of type to define both classes and modules (namespaces) without the prototype-based emphasis of JavaScript. A class with a this() function has an instance constructor*. In TiScript the prototype field is a reference to a type or is undefined. TiScript also has a nice variant on C# properties to provide set and get accessors for field privacy. Sciter itself uses 'self' to refer to the root object as in self.myFunc()

Corporations in the far east which have used Curl will not want to migrate to XUL+rdf+dtd+css+js and it is hard to imagine ActionScript and Flash as being much more attractive. It would be interesting to know whether TiScript itself would obviate the need for the Google Web Toolkit as a JavaScript nostrum while also streamlining the scripting ( GWT is touted as a remedy for unintended JS closures causing memory leaks under IE - but I should add that GWT does have a fine inexpensive plugin to Eclipse by Instantiations.)

Another point of interest is that TiScript offers JSON persistence through a version of a DyBase library which has been modified to support 'native' TiScript. DyBase is said to have interfaces to PHP, Perl,Python, Rebol and Ruby but I could only find a Smalltalk alpha outside of the home archives of the DyBase author (and none at rebol.org, CPAN or the Python Cheese Shop and no RubyForge or sourceforge entries; the dybase site at garret.ru was off-line this weekend.)

Dybase could be as neglected as the database options offered by associative and hierarchical/network databases (MUMPS, DNS and LDAP are hierarchical) in the world of MySql and XBase. And there is Lazysoft, to which there are links at StumbleUpon and AboutUs.

Perhaps if an AltME group opens on DyBase there will be an opportunity to judge its merits across a few languages. Until then I will watch ltu.

* the author of TiScript is the author of Harmonia, an FLTK for the D language.

Thursday, July 5, 2007

exposing slim Liquid Rebol

The dataflow framework for Rebol is called Liquid and is available from rebol.org as a SLiM library.

If you are new to this as I am, it is not obvious how to proceed.

First you need both slim.r and liquid.r

Slim can be found at rebol.org in the scripts.
You can download liquid or retrieve it from the Rebol console by visiting Liquid
to either get the file or run the one-line script at the Rebol console.

Start by loading SLiM with
do %slim.r
and then try
do %liquid.r

The important liquid function is liquify. An attempt at
source liquify
or
help liquify
will show that nothing is yet available.

Start by checking the SLiM paths with
slim/paths
which should be an empty block.

I am using local code (liquid.r and slim.r are in my Rebol directory) so I just do this:
slim/paths: [%.]

Now I check my SLiM path to liquid this way:
slim/find-path %liquid.r
which gives me my Rebol path.
Now I can do the two key bits:
lq: slim/open 'liquid none ; gets any version
and then expose that lq library with
slim/expose lq none ; replace none later with a blk of funcs
Now you can test with a simple test for the liquify true? function with
source true?
You are now ready to use the liquid documentation at Steel quickstart or the Steel Liquid page.

Monday, July 2, 2007

A Name for Rebol 3.0

Now that Rebol 3.0 is in alpha, I feel some concern that a re-naming could be in the offing.
Rebol emerged from Lava. The great thing is that any google on "Rebol" is a fruitful google.
Just suppose that your interest is music and the Oz compiler named Mozart...

That a language called "Stockhausen" could reemerge as "Alice" might amuse.

But it is vexing to search for "io" as a language (it is a language, as was Icon.)

There were silly, ill-timed names: calling the new APL by "J" comes to mind.

A DOS language named "C#" could only have been worse named were it called "C:"
Then there is Obol. All three. And whatever all is named "Rio". At least three.

The worst case for me is Curl which is doomed to be confounded with cURL. When a hairspray named "Surge" appears, the Curl RTE will have to be re-named.

Nemerle has sagely chosen an off-spelling.

"D" is not "E"

Self has suffered through LiveScript, JavaScript, ECMAScript and may be swallowed by ActionScript.

Even Prolog suffers with the 'prolog' in XML.

But Rebol. Rebol is as well-named as Perl.

That is not the case for Cecil with Vortex or any talk of Cecil and Diesel.

Smalltalk was ill-named. Self was worse. Slate, well, we'll see. Then there is StrongTalk and MetaTalk and BackTalk.

So we take datatype+value+word+block+context. Hmmm. A Rebol function could easily give us

dat-vardock-XT
dat-woluock-XT
dat-blordue-XT

Perhaps Rebol/command is in need of a new moniker. REBOL is not, imho.