[q-lang-users] Special values or failing functions

[Alexander N. <AN...@sp...>]

Hello q-lang-users,

  I'm constantly running into some problem in Q that I'll try to
  describe. Probably it's because of my Prolog background.

  Suppose I have a function that may return a value, but also may
  fail. For example, length of a path in a graph. If nodes are
  interconnected, there is length, if no - there is no length.
  Returning some 'special' value like 0 or 99999 is generally a
  bad practice. Due to polymorphic nature of Q I can return
  a value of another type, like false or []. Note that 'fail'-ing
  sometimes requires additional level of function nesting, because
  it applies to one equation only but not to function itself.
  
  Then there comes another problem. Suppose I have a list of values
  that I want to process using function like this, leaving only
  results that make sense, that are 'proper' values.
  It seems to me that I cannot make this procedure polymorphic,
  because if for example 'false' means unwanted value for integer
  function, 0 could mean unwanted value for boolean function, etc.
  Another example is further processing of results. Say, I want
  to find the longest path. It leads to the expression :

  if ((isnum P) and (isnum Q)) then (max P Q) else if (isnum P) then P
     else if (isnum Q) then Q where P = (dist (A,B) N ), Q = (dist (C,D) N );

  I do not think it's very readable. Wouldn't it be nice to have a
  common 'special' value like nil or NULL or whatever, to indicate
  failure ?

  Also it is sometimes not handy that 'where' clause belongs to one
  equation only. If it was not so, I could write

  getmax (A,B) (C,D) = (max P Q) if (isnum P) and (isnum Q);
                     = P if (isnum P);
                     = Q if (isnum Q); where P = (dist (A,B) N ), Q =
                                   (dist (C,D) N );
             
  which is much more readable.
  Just thoughts. Maybe I am looking from the wrong side. In Prolog I
  can just fail a predicate.
  
  
-- 
Best regards,
 Alexander                          mailto:AN...@sp...