On Mon, Mar 25, 2024 at 12:11:42PM +0100, Grégory Vanuxem wrote:
> hello Waldek, hello folks,
>
> Le mer. 20 mars 2024 à 22:28, Waldek Hebisch <[email protected]> a écrit :
> >
> > On Wed, Mar 20, 2024 at 07:41:11PM +0100, Grégory Vanuxem wrote:
> > > Hello,
> > >
> > > Do you happen to know why the declaration of string(Integer) is in
> > > StringCategory and its definition in the String domain?
> > > (STRINGIMAGE$Lisp)
> >
> > 'string' constructs a String and as all functions of similar sort
> > is defined in corresponding domain. As usual, 'string' is declared
> > in corresponding category, that is StringCategory
>
> Yes, of course. I was just wondering why String(__Integer_) was
> declared there instead of a generic declaration like:
> string : % -> String
Where would you like to put this declaration? Declaration without
implementation is problematic, as this would lead to errors at
runtime. So any more general declaration would need associated
implementation. By its very nature operation like 'string' is
specific to a domain.
>
> That way, like Symbol, it can be defined in the Integer domain and
> thus avoid unexpected effects during interpreter coercion mechanisms.
> I encountered this with other integer related domains like another
> prime field domain, another integer mod domain... etc.
>
> In fact, instead of declaring string : % -> String in those domains I
> declare it at a 'Category' level and that solved this. To be more
> precise, I do not ask for its implementation,
We try to have implementation for any declared function. Otherwise
we have code which compiles cleanly but fails at runtime. Most
users consider such behaviour to be a bug.
> having a way to obtain
> an ASCII string representation of every Spad object would be handy I
> find.
That if done as independent implementation would be a significant effort.
Now we could try to use Format1D and existing coercion to OutputForm
for this, but 'string' for Integer is special, because it used by
formating machinery. And there are domains without coercion to
OutputForm.
> Even string(Type) like string(Integer) => "Integer". I guess
> this exists somewhere in Spad but I have not found where.
Not in Spad. ATM this is done at Boot level.
> A good
> candidate to use it could be the 'error' function. There seems to be
> no implicit rules to use this function and from memory I have seen an
> error like "Not invertible". Franckly, imagine you have a lot of code
> with integers, matrices etc. and you see this error. Euh... Not a
> field? rectangular matrix? Singular maybe? And so on. Personally I
> like to know the function who throws the error
That is easy, we have things like
error "makeSketch: constant polynomial"
That is, include function name as part of error message.
> and more information
> could be handy. For example string(%) could be of use. I only know the
> 'latex' function declared in SetCategory that resembles but it is a
> typesetting function, not a simple string function.
Well, output goes via OutputForm. IMO main problem is that ATM
putting OutputForm in messages is clumsy. Compared to that things
like 'string' add IMO little value.
> ,>
> > > That way if someone adds a domain, say, Foo, that has an Integer to
> > > Foo coercion and exports a 'string' operation the interpreter will
> > > choose the Foo one. It's a bit of a shame, isn't it?
> >
> > Well, that is how Spad overloading works: if you have two ways
> > they should give the same result or you need to be more specific
> > (hide Foo, add explicit '$Integer' etc.). If Foo can be coerced
> > to Integer, then maybe 'string' in Foo is not needed at all.
>
> Yes, but from my point of view string(Integer) should not be
> overloaded, it is up to the Integer domain author/programmer to handle
> this coercion Integer -> String. There is 'convert@String' though, but
> it uses 'string':
> convert(x : %) : String == string(x pretend Integer)$String
Well, IMO big problem with 'convert' is that interpreter is too
eager to use it. And we really do not want interpreter to convert
things to strings and then report errors or worse do operation
on strings.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZgTNAJarllnLzaxo%40fricas.org.
