Ralf Hemmecke wrote:
>
> >> SPointCategory(): SPointCategory() == add ...
> >>
> >> In other words, SPAD should let you define a category and also a domain
> >> with the same name, because they are distinguishable by their types.
>
> > No. There is no overloading for constructors. Spad compiler
> > assumes that there is only one contructor with given name and
> > giving new definition removes the old one. Stephen Watt argued
> > that overloading for constructors should be allowed because
> > in the first compilation stages compiler does not know what
> > is a constructor and what is ordinary function. But I am
> > not convinced: disallowing overloading for constructors
> > simplifies compiler and I see no gain from allowing it.
>
> I would like to actually that
>
> A: Category
>
> and
>
> A: with {...}
>
> are two different things since they have different types. Or at least
>
> B: () -> Category
>
> and
>
> B: () -> with {...}
>
> and
>
> B: () -> Integer
>
> be different, because that would follow the principle of types being
> first class and functions are distinguishable by their return type.
> I wouldn't even want to make a big distinction between (ordinary)
> functions and functions that return a domain.
>
> I guess there are technical reasons why such things are problematic.
> And actually, until I had seen a category and a domain being called by
> the same name, I wouldn't have thought of using such an option.
>
> Since I didn't have need for such overloading until now, I'll not fight
> for it.
>
> However, the distinction between functors or ((domain) constructors)
> (i.e. "functions" that return domains) and ordinary functions worries me
> slightly. What would you call a function of this type?
>
> foo: Integer -> (Boolean -> Ring)
>
> foo(1) is a domain constructor. Clear. But foo itself? It's returning a
> function. Would you call it an "ordinary" function? How it is currently
> encoded inside fricas?
>
> Would it be very much different to
>
> Foo: (Integer, Boolean) -> Ring
>
Well, technical reasons as are follows: to resolve overloading we
need to know types. If we allow overloading in type-producing
expressions that we get circularity, with no clear way to sove.
Currently, the only type expressions with nontrivial handling
in the compiler are constructors (as opposed to type-valued
functions) and variables. Also, compiler assumes that types
are equal <=> type names are equal.
In the future we will have better handling of more general
type expressions, then we will need appropriate restrictions.
Of course, types can have parameters which are ordinary
values, and for those values overloading is allowed. Currently
compiler just compares parse trees for expressions corresponding
to such parameters. If parse trees are different compiler
assumes that types are different. I would like to do better
then this.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
