The possible solution ¶

In the expression:

(length "ciao")

the literal expression "ciao" is considered of type <string> and the symbol length, that comes before it, is searched in the list of multimethods whose first argument is of type <string>. The class <string> contains a table of multimethods whose first argument is of type <string>. There is no need to import a binding named length to access the table of multimethods: if it is determined at expand–time that an expression returns a value of type <string>, the expander has access to the table.

But … ¶

What is the difference between having a table of multimethods in a class and just having a global namespace of multimethod names that is queried before the bindings in the local lexical context? In the program:

(import (vicare))

(length "ciao")

the expander just visits the global namespace first, in search of a method named length having one argument with type <string>:

• If the method exists: it is used.
• If the method does not exist: normal binding resolution takes place.

A global namespace of multimethods is equivalent to multimethods in the class definition.

If it is a global namespace … ¶

Is it fine to access it transparently? Or would this transparent access make the code too difficult to interpret for humans? Should a (possibly optional) namespace qualifier be introduced? Possible alternatives:

• Multimethods have names starting with a dot:

  (.length "ciao")
  (.append "ciao" " mamma")
  

  the dot is a small and one–keyboard–tap character.

• Prefix qualifier:

  (:: length "ciao")
  (:: append "ciao" " mamma")
  

  Foreign example: Guile uses the @ character to access bindings from modules without importing such modules in the lexical context.

• Infix qualifier:

  (length :: "ciao")
  (append :: "ciao" " mamma")
  

• Improper list syntax:

  (length . "ciao")
  (append . "ciao" " mamma")
  

• Quoting syntax:

  :(length "ciao")
  :(append "ciao" " mamma")
  

  the reader converts the input:

  :(?form0 ?form ...)
  

  into:

  (colon ?form0 ?form ...)
  

  where colon must be an identifier bound in the lexical context of the expression.

About the improper list syntax ¶

It is currently unused by Vicare. The Scheme reader could be instructed (in #!vicare mode) to convert the input:

(append . "ciao" " mamma")

to some special form, like it already does for the apostrophe and similar operators: the input '(1 2 3) is read as (quote (1 2 3)). So, in general:

(?form0 ?form1 ... . ?form2 ?form3 ...)

could be read as:

(improper (?form0 ?form1 ...) (?form2 ?form3 ...))

where improper must be an identifier bound in the lexical context of the expression.

But what about:

'(1 2 . 3)

which is a perfectly valid literal expression? The reader should distinguish between quoted and unquoted input: this should not be a reader’s responsibility.

Conclusions ¶

Having a global namespace for multimethod names seems the most sensible solution.

The cleanest way to query this namespace seems to be a proper syntax use like:

(method-call ?name ?operand ...)

where method-call is defined in the boot image and exported by (vicare). Some reader syntax should be used to obtain a method-call syntax use from some easy–to–type sequence of characters.