RE: A Plea for Functionality: Dynamic Alter Global Variable Values

I'm guessing that this comment is targeted at XSLT 2.0 rather than XQuery,
since you've raised related concerns on the xsl-list.

I can tell you now that there is no way the XSL WG will contemplate making
such a fundamendal change to the nature of XSLT as a functional programming
language.

Object programming languages were originally invented to tackle simulation
problems, because it is convenient to represent the state of each agent
being simulated by the state of an object in the program. Different
programming languages are optimized to different kinds of problem, and it
might simply be that you are using the wrong language for the job in hand.
Complaining to a manufacturer that their hammers are not very good at
driving screws is unlikely to get you very far.

Someone might be able to help you to devise a solution to this problem using
XSLT 2.0 if you describe it clearly enough. The language is computationally
complete, so everything is possible. The place for such a discussion is the
xsl-list at mulberrytech. It's possible that the new facility of tunnel
parameters will enable you to improve the modularity of the code.

The formal public comment period has closed, which means that the working
group now has discretion whether to accept comments or not. Comments that
point out bugs in the spec are still welcome, but comments that suggest new
features or radical changes to the language design can only delay the end
date. Since we're now trying to deal with all the issues that were raised
during the comment period, and since I believe that this one has little
chance of affecting the language specification, I'm not going to add it to
the issues list unless the chair decides otherwise.

Michael Kay 

# -----Original Message-----
# From: public-qt-comments-request@w3.org 
# [mailto:public-qt-comments-request@w3.org] On Behalf Of Roger 
# L. Costello
# Sent: 21 March 2004 12:40
# To: public-qt-comments@w3.org; Costello,Roger L.
# Subject: A Plea for Functionality: Dynamic Alter Global 
# Variable Values
# 
# 
# FUNCTIONALITY REQUESTED
# 
# The ability to dynamically alter the value of a globally 
# scoped variable.
# 
# DOMAINS REQUIRING THIS FUNCTIONALITY
# 
# Multi-agent simulation, parallel processing, complex adaptive systems.
# 
# REASON FOR REQUIRING THIS FUNCTIONALITY
# 
# Consider a multi-agent simulation: I would like to have code 
# to express the movement rules for a *single* agent, and then 
# *separately* have code which *applies* the movement rules to 
# each agent (a classic case of separation of concerns, and a 
# classic paradigm of parallel processing).
# 
# I will show a simple example in pseudocode:
# 
# Agent Movement Rule
#    Move forward one cell
#    Turn right 90 degrees
#    Move forward 2 cells
# 
# Agent Processing
#    For each agent do:
#       Apply Agent Movement Rule
# 
# In this example we see that we have cleanly separated the 
# statement of the how each agent should move (Agent Movement 
# Rule), from the application of the movement rule to each 
# agent (Agent Processing).
# 
# In order for the Agent Processing code to to apply the 
# Movement Rule code to each agent it will need to modify the 
# value of a global variable.  Thus, you now see why I am 
# requesting this functionality. 
# 
# CAN MULTI-AGENT SIMULATION BE DONE WITH EXISTING 2.0 FUNCTIONALITY?
# 
# Yes.  In the above example the Agent Movement Rule could be 
# nested within the Agent Processing code (in fact, I have 
# implemented this). 
# However, it results in (very) brittle, complex code and it 
# does not support separation of concerns (e.g., one person 
# writing the Agent Movement Rule, another person writing the 
# Agent Processing code).
# 
# NOT TOO LATE, I HOPE!
# 
# I realize that this request is late in the game.  However, I 
# feel that without this functionality the 2.0 version will 
# have a large gaping hole in its capability, and severely 
# cripple multiple communities.
# 
# Thanks for your time.  /Roger
# 
#

Received on Sunday, 21 March 2004 11:50:03 UTC