Hello Alex,
Thanks for the quick response.
expression = '(' expression ')'
Mea culpa. Now fixed at http://www.measurement-factory.com/tmp/opes/
That's nice.
I agree that using case to distinguish operators is a bad idea. I have
a better(?), not yet documented, idea. String should have case
sensitivity attached to them by module methods that produce them.
String constants would default to case-sensitive. This will make it
possible to compare, say, HTTP request method with "GET" or "connect"
constants and always get "correct" result depending on protocol
sensitivity rules.
I like this idea!
case_sensitive() and case_insensitive() Core methods are provided to
force particular sensitivity mode when needed. Comparing a case
sensitive string with a case insensitive string will result in case
insensitive comparison.
Here I still prefer having different operators for sensitive and
insensitive. However, based on your idea above, we could probably have a
default behaviour defined for comparison (which is based on the
attributes of the string).
This needs further thought/polishing. Have you seen sensitive strings
anywhere? Do you think this approach will work?
I cannot recall seeing it anywhere else at the language level ... only
sensitivity at operators/API. But yes, python allows defining regular
expressions that can be optionally case insensitive (compile method),
similarly Java specifies some classes whose objects can have case
sensitivity as an attribute for comparison.
I have rejected scope for the sake of simplicity. I could not find
convincing examples where it would be really needed. With
single-assignment approach, global scope is needed to name expressions
based on external conditions:
Yes, the need for global assignment is clear.
If a name is not used outside the module, the optimizer will remove
it. Thus, the above is only helpful to avoid name collision. If this
becomes a true problem, "local" variables should be introduced into
the language. Personally, I doubt many general-purpose modules would
be written as P programs.
Yes, the scope manipulation statements will only aid in avoiding name
collision. Alternatively, you could always mandate a need to qualify any
member with the module name (ie., name representing the import
statement) as opposed to providing features that may result in name
collision.
I beleive, the optimizer cannot apriori know whether or not the name is
used outside the module. What happens if the current P source file is
imported in another (nested modules!) ?
I would prefer to see more explicit Http.message.method in the above
case.
But, consider the case wherein a module implements an operation such as
regular expression match. In that case, I would prefer to say
matchRE(expr1,string) rather than re.matchRE(..)
Nevertheless, it may be better to make that a language restriction
itself and mandate the need to qualify members (as I mentioned in an
earlier point)!
Are you talking about the difference between use and require in Perl?
I agree that adding require would be a good solution if many modules
are written in P, but I think to support modules written in P well,
more things like explicit exported or explicit local variables will
need to be added.
That would be an alternative way of extending the scope - that would be
more like other languages and would probably be prefered.
* Section 4.1: Interpreter-module interface.
** I think we should at the minimum specify a minumum interface that
must be supported by a module, such as - isDefined("membername") and so
on - which could typically be provided a default behaviour by the
interpreter (based on the semantics of the import statement).
Not sure what general interface functions we can document. Can you
give more examples?
Is isDefined really needed? If something is not defined, P interpreter
will raise a failure. Is that not sufficient to detect undefined
things?
Yes, some things may be caught with exceptions.. How about
isCaseSensitive(string) ? Assuming the new attributed string that you
mentioned. I will try and list those one of these days.. As of now, I am
thinking of some methods that provide reflective property.
** There is also a need to specify the characterisitics of the service
being returned by the imported module. (or give a reference to where
this info is available)
I agree that service interface needs to be documented.
This needs to be documented. I think the semantics should be apply
once and then continue interpretation. However, we need to document
whether named expressions may change after service invocation:
a = message.headers.have("Via"); // suppose there is no Via
if (not a) {
Services.apply(service); // adds Via
}
if (a) {
// should this be executed?
}
My feeling is that the computed (used) value should not change.
Assignment is not a macro.
As per the description in 3.6, the computed value should change! The
alternative semantics can be obtained by
if (not a) {
Services.apply(service);
}
else {
/* if not a */
}
*** Will the interpreter employ the call-out protocol at this point? If
so, does it send the response or the request? For example, in the ICAP
case, is it RESPMOD or REQMOD?
It may employ OCP. I think that services need service-specific
configuration parameters that determine mode and what needs to be
supplied (e.g., request, response, or both).
Don't we then need to specify how to get the request and response from
the Core? Do you assume that the interfaces for the request/response
objects will be provided by the protocol module?
** How does one specify the vectoring point (equivalent of 1,2,3,4 in
IRML)?
Application-dependent. HTTP Adaptation draft or other documents may
document this as a part of HttpProxy module description.
Thanks a lot for your feedback. I hope that my "we want to keep it
simpler for now" responses did not discourage you. This is just a
starting point. With sufficient demand and real-world use, we should
be able to polish and enhance the language.
Personally, I have seen the need for a conditional expression (at the
minimum with OR and AND) and also need for regular expression match
while using IRML...
Thanks for making this discussion interesting..
regards
Geetha