🚀 go-pugleaf

I'm not entirely sure I understand what you are getting at, but that's
never stopped me from talking before...

In article  <PCG.91Mar12135254@aberda.test.aber.ac.uk> Piercarlo Antonio Grandi writes:
...
]No, no, we have *two* misunderstanding here. I have never said that in
]this example one need declare *explicitly* the types of the arguments of
]an operator; simply, that a type is defined by the operators that can be
]meaningfully applied to the values of that type.

What does "meaningfully applied" mean?  In a dynamically typed
language, any function can be legally applied to any value.  So are
you suggesting that every value has the same <type>?  Or do you want
"meaningfully applied" to mean that the function doesn't produce an
error message when called with that value?  Then what do you do with
something like

  procedure foo(x1,x2)
  if number(x1) then return x1 + x2
  else return x2
  end

where x2 must be a number if x1 is, but otherwise can have any type?
I think the whole concept is on shakey ground.

]... is regrettable and is only really an efficiency
]hack, just like the one between 'eq' and 'equal', and it generates much
]the same class of problems...

An aside, 'eq' and 'equal' are semantically distinct.  I would
consider the language to be lacking an important operation if it were
missing either one.  The same applies to 'eql'.  They all serve
different purposes.

]This is wrong, as far as I can see, because then there is no way to know
]the <type> or <typing> of a value...
]I think you are wrongly assuming, in other words, in your definition
]above, that there is some magic way to know which set a value belongs
]to, without encoding it into the value itself...

I wasn't making any assumptions about the representation of values.
Frankly, I'm surprised to see representation come up at all, since I
don't see what it has to do with the subject at hand (unless you are
thinking of <type> as a particluar way of interpreting a group of
bytes as a value.  That doesn't fit your definition though.)

]... On the other hand if you encode the set into the value
]itself, then you are defining types as equivalence classes, and your
]definition and mine are exactly equivalent.

Not at all.  Your definition has the <type> of a value changing when
new functions are added.  Mine doesn't.

]gudeman> Then no seperate notion of <typing> is needed.
]
]... The end result of your proposal is to drop the
]notion of <type> and keep only that of <typing>, not viceversa.

I'm throwing away your concept of <type>, as I said.

]... when a new
]release of Unix switches the implementation of /etc/passwd from a text
]file to an hash file, you need a program to convert formats, whose role
]is essentially that of converting one <type> to another to maintain ther
]illusion that <typing> has not changed.

The job of the program is to convert from one representation to
another.  The set of operations on the file has not changed, so the
the <type> hasn't changed, by your definition.  Again though, it looks
like you mean <representation> when you say <type>.

]... I know no language that IMNHO
]does a satisfactory job of reconciling the gross rigidities of doing
]<typing> with the reality that <types> are equivalence classes.

Are you familiar with Common Lisp?  What sort of type do you need that
you can't define in that language?  How is an equivalence class
different from a set?  And what equivalence relation are you refering
to?  It looks at times as though you mean $equiv(x,y) iff typeof(x) =
typeof(y)$ -- which makes <type> and <typing> identical.

]gudeman> ...  It also gives you a fairly
]gudeman> simple way to define the result of the 'typeof' function(s)...
]
]This is just <typing>, according to my terminology. You have thrown away
]the notion of <type> entirely.

Yeah, that's what I said.  (I get the feeling we aren't
communicating...)
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman