- From: Jeremy Carroll <jeremy@topquadrant.com>
- Date: Tue, 03 Nov 2009 22:58:05 -0800
- To: public-rdf-dawg-comments@w3.org
- CC: Holger Knublauch <holger@topquadrant.com>, Jeremy Carroll <jcarroll@topquadrant.com>
As a personal comment, (sorry you are probably sick of me now). I don't particularly seek a response to this comment. I am surprised that there is concern that the LET single assignment construct may mislead users into having an incorrect processing model in their heads that might be overly procedural. This surprise is because the whole point about having a declarative semantics is that the processing model is irrelevant. Thus, with a declarative language, we expect, perhaps even desire, that users have incorrect processing models. Each implementation is free to use their own processing model, and the user works with their own. For example, when running an XSLT script, if it has some side effect of writing a message to the console, it is often surprising when these messages get written. This is because the easiest way to think of the XSLT processing model is top-down left-to-right, but good implementations tend to be lazy. This mismatch between the users model and the implementor's reality is desirable because: a) it makes it easier for the user to understand the language b) it allows the implementor to efficiently implement the language c) the declarative language design ensures that it doesn't matter that these two views of the processing model differ, perhaps radically. So, I think an advantage of the term LET as opposed to BIND (say) is that LET reminds some users of procedural programming in BASIC, and allows them to reuse that programming model. Now, while the details of the execution flow are very different in SPARQL than in BASIC, it seems that this apparent familiarity has pedagogical advantages. == For the record, TopQuadrant's position is we don't care what word is used, whether it is LET or BIND or something else. A further aside is that the latest release of TopBraid Composer includes a SPARQL debugger function that exposes some aspects of the insides of the SPARQL processing (I haven't used it). But I guess that using such a tool would quickly disabuse you of any incorrect notions of the processing model. (LET, I believe, is one of the SPARQL extensions supported by the tool). Jeremy
Received on Wednesday, 4 November 2009 06:58:43 UTC