Posts filed under 'Rant'
Long, long ago, I complained about various warts and infelicities in E4X, the ECMAScript extensions for generating and pattern-matching XML documents. It turns out that two of my complaints were not well-founded: sequence-splicing is supported, and programmatic construction of tags is possible.
Firstly (and I’m amazed I didn’t realise this at the time, as I was using it elsewhere), it’s not a problem at all to splice in a sequence of items, in the manner of Scheme’s unquote-splicing; here’s a working solution to the problem I set myself:
function buildItems() {
return <>
<item>Hello</item>
<item>World!</item>
</>;
}
var doc = <mydocument>{buildItems()}</mydocument>;
You can even use real Arrays (which is what I tried and failed to do earlier), by guerilla-patching Array.prototype:
Array.prototype.toXMLList = function () {
var x = <container/>;
for (var i = 0; i < this.length; i++) {
x.appendChild(this[i]);
}
return x.children();
}
function buildItems() {
return [<item>Hello</item>,
<item>World!</item>].toXMLList();
}
var doc = <mydocument>{buildItems()}</mydocument>;
Programmatic construction of tags is done by use of the syntax for plain old unquote, in an unusual position: inside the tag’s angle-brackets:
var tagName = "p";
var doc = <{tagName}>test</{tagName}>;
So in summary, my original expectation that E4X should turn out to be very quasiquote-like wasn’t so far off the mark. It’s enough to get the basics done (ignoring for the minute the problems with namespace prefixes), but it’s still a bit of a bolt-on afterthought; it would have been nice to see it better integrated with the rest of the language.
May 7th, 2008
tonyg
In C, size_t is unsigned. In Java, there are no unsigned fixed-width pseudointegral types, so it can perhaps be forgiven for having an array’s length field be signed. In .NET, however, which has unsigned ints, an array’s length field is also signed. What could it possibly mean to have a length less than zero?
September 19th, 2007
tonyg
I find it fascinating that after so many decades of support for closures, we’re still stuck in a C-style mentality of passing function-pointers that take an explicit context argument rather than a proper closure object. Witness the design of .NET’s Type.FindInterfaces method:
public virtual Type[] FindInterfaces (TypeFilter filter,
Object filterCriteria);
The TypeFilter argument is a delegate. The Object argument is context that the delegate may require! This is pretty much exactly the old-school C-style way of implementing closures:
/* Yes, pretty crude translation, I know */
TypeArray find_interfaces(int (*type_filter)(Type*, void*),
void *argument);
Smalltalk (and Lisps) would do it in the natural way, with a block (a closure):
someType selectInterfaces: [:interface | ... ]
Lisp 1.5, complete with support for lexical closures, appeared in 1959. It’s 2007. That’s forty-eight years.
September 11th, 2007
tonyg
Although we’ve been very pleased to welcome Felix and Simon in the last few months, and we’re very happy about the return of Sam Jones, we’re still on the lookout for fresh blood.
We really haven’t had much luck with recruiting strangers recently. Simon and Felix both came to us via personal introductions.
We’ve been sifting sadly though the CVs sent by recruiters. There have been a few exceptions, but these nearly always fail to raise a flutter of interest. Typically there’s no sense of the person behind the application, just a very narrow range of experience and interest. We really rely on the slow but steady trickle of CVs we get from people who actually know of LShift, and have perhaps even looked at this website and have actively chosen to apply. This kind of application has a much better chance of success here. We’ve had a few close runs in the past few months. Unfortunately, one of the interesting applicants just disappeared into the ether mid-way through the recruitment process (we’re not that bad surely?). We met someone else we’d hire tomorrow - sadly for us it turned out not to be such good timing for the applicant (yet, i hope). We’ve just heard from another interesting prospect too, but we’d still love to see more applicants like these, and a little bit more luck.
If you know open source and commercial projects, if you’re not afraid of computer science and you know how to complete a project then please cheer us up and get in touch. If you fit the bill but the job described here doesn’t appeal then we’d love to know why.
Also, we’d be very interested to know where all the CVs from women in this industry go - we haven’t seen one for ages.
July 26th, 2007
sophie
Some sites or services, quite reasonably, need to know who I am (and that I really am that person, to some acceptable level of verifiability). It’s usually because they hold data on my behalf, and neither me nor they want anyone else getting at that data.
But why does InfoQ require me to register to download a free PDF?
They say,
… we’re happy to offer a free version for download, to get this knowledge in as many peoples hands as possible
;
however, I had to complete a long form (to which I mostly invented answers), then verify my email address, then navigate back to the page. I hardly see how that is compatible with the stated aim.
After running into that, I almost despaired when I went to download the official MySQL JDBC driver.
Almost: there’s actually a link below the register (or log in) options saying “No thanks, just take me to the downloads!”.
Yay for MySQL.com!
June 12th, 2007
mikeb
Reading through tonyg’s recent post I came across something i haven’t yet seen in use - inline XML within Javascript code. E4X, it seems, has landed. It is now available by default in Firefox and Rhino - other implementation will surely follow.
E4X, shorthand for ECMAScript for XML is a nice language extension to Javascript adding native XML support. It adds XML types, a notation for literal XML and some basic operations. Previously, if you wanted to use XML in your Javascript code, you had two choices. Since XML has a textual representation, you could work with strings. This approach, however, is extremely error-prone, and is of limited use if you intend to do anything more sophisticted than just generating XML. The other approach is to use the XML DOM, which exposes the full power of XML using a consistent model, but is too verbose and so rather unpleasant to use.
Example: XML using strings / innerHTML
// Short, but notice how I forgot to close the paragraph
// Also, this is non-standard, and only works in HTML
myElement.innerHTML = '<p><b>Hello</b> <i>World</i>';
Example: XML using the DOM
// That must be one of the longest hello world
// examples I've ever written
var paragraph = document.createElement('p');
var bold = document.createElement('b');
var hello = document.createTextNode('Hello');
bold.appendChild(hello);
var italic = document.createElement('i');
var world = document.createTextNode('World');
italic.appendChild(world);
var space = document.createTextNode(' ');
paragraph.appendChild(bold);
paragraph.appendChild(space);
paragraph.appendChild(world);
myElement.appendhChild(paragraph);
As it happens, I am working on something that requires quite a lot of DOM manipulation within the browser, and tired of constructing XML using the DOM API I set to give the new E4X capabilities of Firefox 1.5 a try. The dissapointing reality, I soon found out, is that while E4X is very much present, it can’t be used for accessing or creating DOM elements. So if you plan on parsing some XML data, or generating XML from your program you can use E4X, but DOM manipulation, arguably the most important activity involving XML in a browser is not served by this new extension at all.
Example: How E4X could be used with the DOM
// This is structured XML, notice how there are no quotes
var p_xml = <p><b>Hello</b> <i>World</i><p>;
// But unfortunately you can't do that
var p_element = document.createElement(p_xml);
myElement.appendChild(p_element)
Javascript is a complete, general-purpose language, but in practice, it is being used exclusively as an extension for host environments. In Firefox, for example, it is used for adding program logic to the browser’s display formats - HTML, XUL and SVG. These formats can be expressed in text, but in order to manipulate them you need to access them using the DOM. For HTML, firefox adopted the nasty innerHTML non-standard extension, which allows the user to access the contents of a node as text. Fortunately, this extension doesn’t work with non-HTML elements. E4X could have been the perfect replacement - a compromise between using the dumb textual representation and the structured, but counter-intuitive DOM.
Why doesn’t Firefox provide a way to construct and manipulate DOM elements using E4X? It’s hard to blame the mozilla developers, given that the ECMA standard does not include any mention of the DOM or how to interact with it. Any extension they would have come up with would end being the next generation innerHTML non-standard.
This failure of the E4X standard, together with tonyg’s previous critique of E4X, as well as other rumours from the Javascript development arena have me wondering whether the standartisation efforts by ECMA have greatly benefited the language and its active community.
July 24th, 2006
Tom Berger
What’s the right way to create a subclass in JavaScript?
Wrong question, say the JavaScript advocates. JavaScript isn’t one of those fuddy-duddy old class-based languages. It’s something much more exciting: a prototype-based language! So remember, when you work with JavaScript, remember never to refer to “classes”, because JavaScript doesn’t have them, and it only shows you’re stuck in the old way of thinking.
I’m sure that these sentiments have done enormous harm to the reputations of real prototype-based languages, so let me banish it right here. JavaScript is not a prototype based language; it most closely resembles a class-based language, but all its mechanisms for doing the work of a class-based language are horribly broken, which is why its advocates try to pretend it’s something else.
Continue Reading July 24th, 2006
Paul Crowley
E4X is a new ECMA standard (ECMA-357)
specifying an extension to ECMAScript
for streamlining work with XML
documents.
It adds objects representing XML to ECMAScript, and extends the syntax
to allow literal XML fragments to appear in code. It also supports a
very XPath-like notation for
use in extracting data from XML objects. So far, so good - all these
things are somewhat useful. However, there are serious problems with
the design of the extension.
If E4X objects were real objects, if there were a means of splicing a
sequence of child nodes into XML literal syntax, and if E4X supported
XML namespace prefixes properly, most of my objections would be dealt
with. As it stands, the overall verdict is “clunky at best”.
These are my main complaints:
It doesn’t do anything like Scheme’s unquote-splicing,
and so using E4X to produce XML objects is verbose, error-prone and
dangerous in concurrent settings.
There seems to be no way of splicing in a sequence of items -
I’d like to do something like the following:
function buildItems() {
return [<item>Hello</item>,
<item>World!</item>];
}
var doc = <mydocument>{buildItems()}</mydocument>;
and have doc contain
<mydocument>
<item>Hello</item>
<item>World!</item>
</mydocument>
What actually results is the more-or-less useless
<mydocument>Hello,World!</mydocument>
The closest I can get to the result I’m after is
function buildItems(n) {
n.mydocument += <item>Hello</item>;
n.mydocument += <item>World!</item>;
}
var doc = <mydocument></mydocument>;
buildItems(doc);
It’s full of redundant redundancy - it’s as verbose as XML, when you
can do so
much better.
There’s no toXML() method (or similar) for use in
papering over the yawning chasm between the XML objects and the rest
of the language: you can’t even make a Javascript object able to
seamlessly render itself to XML.
The new types E4X introduces aren’t even proper objects -
they’re a whole new class of primitive datum!
Because they’re not proper objects, you can’t extend the system. You
ought to be able to implement to an interface and benefit from the
language’s XPath searching and filtering operations. E4X is so close
to offering a comprehension
facility for Javascript, but it’s been short-sightedly restricted to
a single class of non-extensible primitives.
You can’t even construct XML tags programmatically! If the name of
the tag doesn’t appear literally in your Javascript code, you’re out
of luck (unless you resort to eval…) [[Update: I was wrong about this - you can write <{expr}> and have the result of evaluating expr substituted into the tag.]]
E4X XML objects have no notion of namespace prefixes (which are
required for quality implementations of XPath and anything to do
with XML signatures). Prefixes only turn up in the API as a means of
producing (namespaceURI,localname) pairs. This is actually how it
should be, but because there’s already broken software out there
that depends on prefix support, by not supporting prefixes properly
you preclude ECMAScript+E4X from being used for XML signatures or
ECMAScript-native XPath implementations.
In my opinion, E4X violates several programming
language design principles: most importantly, those of
regularity, simplicity and orthogonality, but
also preservation of information, automation and
structure. SXML, perhaps in
combination with eager
comprehensions, provides a far superior model for producing and
consuming XML. Sadly, there’s no real alternative for ECMAScript yet -
we’re limited either to library extensions, or to using the DOM
without any syntactic or library support at all.
June 24th, 2006
tonyg
Can a correct, or even sensible Date, Time and Calendar library be designed, for any programming language at all, ever, by anybody, genius, time expert, or not? Certainly Java’s Date API isn’t very inspiring, but some systems do manage to do better: here’s a quick survey of the state of Date/Time/Calendar libraries in a few different languages.
Scheme’s SRFI 19 is, overall, an excellent library at its core (i.e. the specification of Time objects), but suffers from a number of bugs in its reference implementation, some quite serious, and lacks support for the timezone database.
Things may be looking up for Time processing in Java: the Joda Time library looks like it’s designed around the key separation of Instants, Intervals, and Durations from Calendar-related notions such as Dates, Times, and human-readable representations of time. The evidence suggests it may even deal with timezones properly.
Even C’s venerable time implementation (it’s an int! Everything’s an int!) is better than that provided by many languages. At least it’s correct and reasonably simple. The main flaw in it is the way that the current timezone is not even a global variable - it’s an environment variable. Trying to treat it as a parameter is an exercise in frustration, making timezone calculations far, far more difficult than they need to be.
Squeak currently has two major libraries: Chronology, the incumbent, and the comprehensive-looking newcomer Chronos. I’ve only ever used Chronology, but I can definitely say it was a very pleasant experience compared to every other language and date/time library I’ve ever used. Chronology doesn’t really do timezones (or leap seconds), and from that point of view Chronos is a significant improvement. Chronos looks very promising, but loading it broke my image (timestamping doits broke during save and quit) so I’ve not explored it in any detail.
May 5th, 2006
tonyg
For about a week, I thought my EpsonScan driver was broken: whenever I selected a folder to dump my batch scans, it would just hang there on the “Browse for Folder” dialog box.
Then I noticed the same problem in NikonScan…, Picasa… and Thunderbird.
Suspicious, huh? I rummaged around and noticed that Windows Update had installed four patches about a week ago. I bit of googling suggested KB908531 might have been the culprit. So I uninstalled KB908531 through the Add/Remove Programs feature in Control Panel and ta da! my computer is usable again.
BTW, you should read Microsoft’s knowledgebase article before you uninstall the patch. Since those are the primary applications for my computer at home, I’ll be living (dangerously) without the patch until they fix it properly.
April 25th, 2006
francis
Previous Posts