Re: Operator overloading [was: Re: Does my ideal language exist?]

• To: info-dylan@ai.mit.edu
• Subject: Re: Operator overloading [was: Re: Does my ideal language exist?]
• From: hs@inferno.nirvananet (Hartmann Schaffer)
• Date: Tue, 20 Jun 2000 20:45:02 -0400 (EDT)
• References: <m34s82daqz.fsf@enterprise.newedgeconcept> <8hh0ho$hut$1@nnrp1.deja.com> <8hj3lm$58b@web.nmti.com> <8hjmt4$jvq@odds.stat.purdue.edu> <8hlkpt$gfi@web.nmti.com> <Pine.GSO.3.96.1000607190423.8992J-100000@tardis.tardis.ed.ac.uk> <ov8mi8.cr8.ln@localhost>
• Xref: traf.lcs.mit.edu comp.lang.forth:56998 comp.lang.misc:33171 comp.lang.dylan:12210

In article <ov8mi8.cr8.ln@localhost>,
	sian@localhost. (Sian Leitch) writes:
> ...
> Operator overloading in Algol 68 is possible (and typical) because
> the context of an operand is `firm' which means that integers cannot
> be `widened' to real or complex numbers, nor converted into arrays
> (`multiples' in Algol 68).

i don't have access to algol68 material any more, but i am pretty sure
that in most contexts automatic widening did happen, while narrowing
had to be explicitely requested by in the source code.  the rational i 
remember was that widening is always safe (in terms of value
preservation), while narrowing (i think that was the term they used)
usually implied a potential inaccuracy or value loss, so for most
narrowing operations there were several operators providing different
types of narrowing (like round / truncate / floor / ceiling)

> ...

-- 

Hartmann Schaffer

• Operator overloading [was: Re: Does my ideal language exist?]
• From: Hugh Greene <q@tardis.ed.ac.uk>
• Re: Operator overloading [was: Re: Does my ideal language exist?]
• From: sian@ai.mit.edu (Sian Leitch)

• Prev: Need help with Class-Allocated Slots
• Next: Re: Lisp - First Impressions
• Index(es):
  • Main
  • Thread