We can define intent in various ways – in my doctoral thesis an intent was defined as a goal – i.e. where choice and commitments are open.
In the length example, I define an intent as a mathematical definition – whereas an implementation is an algorithm that when executed computes based on the definition.
In Prolog the description of the definition and of the algorithm are closer aligned because of the declarative and procedural reading of the same code.
I don’t see why you’re trying to define Prolog narrowly.
Would you say I’m not programming in Prolog if I use freeze/2 or dif/2 or when/2 (which date back to about 1985)? What about attributed variables, which are earlier than 1985, and which are used by various constraint solvers?
There have been various “flavors” of Prolog from the very beginning, and I think there’s little point in trying to precisely or narrowly define what “Prolog” means.
Certainly it is – length/2 is defined only if the length is a non-negative integer. So, there should also be a test for N being an integer.
I think i am missing something important you have in mind, since the rewrite seem trivial … just use the is operator and change the order … it would still have the declarative flavor offered by Prolog.
I like the #= operator mainly because it can handle deferred compute (via, I guess, attributed variables), and can be used before the recursive call, and because it work bi-directional.
re: executable specification
Terms such as requirements, design, implementation, and the term specification – which is often associated with requirements, have always had fuzzy boundaries – and often they are in the eye of the beholder – i.e. you have to ask who made an embodied decisions - the customer or the implementer – to know if its required or by-design.
An executable specification has the additional benefit that you can more easily validate the specification with the problem owner, by executing it and asking if the observed behavior is the intended one.
O’Kefee describes in his Crafts book how he thinks differently when implementing in C or in Prolog – with the latter evoking a metaphor of many strands that must interrelate just so …
When I am close to the book I can look up the exact quote …
I can understand why you are introducing the area of default knowledge here, but my comment was with a much more narrow scope in mind and much closer to software engineering.
A software system that gets implemented, gets specified first. The specification would then capture functional intents whereas the implementation capture realization of those intents in imperative code.
Absolutely …
Non-Functional Requirements, or so called ,NFRs, are key to the overall success of a solution system.
Clearly, solution systems that implement the same functionality can be designed to address different NFRs – such as a database that is embedded vs. a database that is multi-tenant and on the cloud.
You are right, I was not precise in my phrasing – i meant functional requirements that describe intent …
In my doctoral work I made use of a modeling framework that treated NFRs as goals/intents to be achieved and assisted in clarifying them and exploring the design space for satisficing them (satisfying well enough) in relation to tradeoffs with other NFRs
This was essentially an argumentation framework.
Typically, dealing with NFRs involves architectural decisions, but also more detailed decisions such as related to data structures used …
Dan
Didn’t occur to me to post it here – also, although, i am posting quite extensively here - i do like to keep my identifiable internet footprint low … would be glad to send you a link “off-list” …