On 01/19/2012 06:20 PM, Waldek Hebisch wrote:
Ralf Hemmecke wrote:
On 01/18/2012 06:41 PM, Martin Baker wrote:
On Wednesday 18 Jan 2012 16:48:42 Waldek Hebisch wrote:
Assuming everything is in graph.spad:
)boot $bootStrapMode := true
)compile graph.spad
)boot $bootStrapMode := false
)compile graph.spad
OK thanks, I have updated the tutorial, this simplifies the process a
lot.
https://github.com/hemmecke/fricas/commit/6fa5c6e9025c6b6be80d120c04928eeae2367d16
I've updated your tutorial a bit by introducing the "document" command
to tangle the files. At least on my computer there also was no Loop
domain. So I also had to extract it from graph.spad.pamphlet
I get the same errors that you get.
compiling exported * : ($,$) -> DirectedGraph Product(S,S)
Internal Error
Error while instantiating type DirectedGraph(Product S S)
and I think that Waldek's hint is not the right one.
You mean that you still get error after using described
procedure?
No, sorry. I did not even try your suggested procedure, since Martin's
code does not look "proper" to me.
It looks like the
error comes from
DirectedGraph(S): Exports == Implementation where
S: SetCategory
...
SPROD ==> Product(S,S)
GRPHPROD ==> DirectedGraph SPROD
Exports ==> Graph(S) with
...
"*":(%,%) -> GRPHPROD
Implementation ==> add
...
You basically want DirectGraph(S) to export a function with signature
(%, %) -> DirectGraph Product(S, S)
This is supposed to work, $bootStrapMode is exactly designed
to resolve such cases.
Yes, but I simply say, one shouldn't write such code. The reason for
this is that I would like not to mention the name of the constructure
that is about to be defined in its body. (Here we even see DirectGraph
in "Exports", i.e. more than twice before the == sign.
$bootSTrapMode might resolve such issues, but I simply argue that such
code should not be written. (Maybe just my personal view,)
I think, such a function should better live inside a package:
DirectGraphFunctions(S): with
_*: (DirectGraph S, DirectGraph S) -> DirectGraph Product(S, S)
== add
...
That would probably avoid the bootstrapping problem and looks much
cleaner IMHO.
I do not think this is good idea: '*' is clearly operation on
DirectGraph and naturally belong to the domain. We have cases
where for technical reasons we have to introduce extra packages,
but this is not the case.
Well, then you have another opinion than me. I would rather want a
signature *: (%, %) -> %. Martin's multiplication is not going from the
domain to itself, but rather from the domain to a new domain that
happens to be constructed by a constructor (a function) with the same
name as the one that % is constructed from.
Remember the Monad thread. Neither SPAD nor Aldor has a way to refer to
the function name of a domain constructor. It's certainly not %.
Ralf
--
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.
