On 10/30/23 13:48, Waldek Hebisch wrote:
Well, at first I expected AssociationList and hash tables to
use the same output as IDPO, but original authors did this differently.
BTW, the following looks strange:
(12) table(1 = 2.0)
Type: AssociationList(Integer,Float)
Yes. I cannot say that I am very happy with that notation. In fact, a
"better" notation would be
table[[key=1,entry=2.0], ...],
but that is too much notation, so original developers invented something
shorter using just "=" for Table and AssociationList and "->" for IDPO.
Since IDPO represents a finite combination, I still think it should be
called "...Sum..." instead of "...Product...", but that is another matter.
For IDPO it would also make sense to have
2*y + 1*x
as output, similar to how divisors are denoted.
IDPO may have extra structure but in general it is just product
with no additional structure. So '*' and '+' are inappropriate
in general case.
Yes, of course. I was just stating an option.
Well, '\rightarrow' is clearly different thing than '\to'.
I cannot really interpret this sentence, since \to feels to me more like
a latex command with a semantic name "to" that is to be represented by
an arrow. And \rightarrow is the name representing a symbol, an arrow.
LaTeX is not really the language for expressing semantics.
If you wanted to express that \rightarrow or rarrow to stand for what I
denoted as ":>", then OK. Yes, a third operator is fine for me.
Hmm, I would be more happy with "~>" or maybe "=->".
Yes "~>" would be fine for me. Three letters defeats the idea of having
as little "non-information" as possible.
If we insist on 2 character symbol, than "~>" is IMO pretty
good one.
Fine. Looks good. Probably better than ":>".
Nevertheless, adding new output arrows that prevent
cut&paste would be somehow bad.
Well, current OutputForm is quite different than what is accepted
by interpreter. I do not plan significant changes to current
interpreter parser, but adding new operator symbols to old parser
is quite easy. So extra symbols actually can make cut&paste
easier.
I want cut&paste, but on the other hand introducing ~> as a new operator
to the SPAD language is somehow not really in my interest. Then users
would be able to declare a function
"~>": Integer -> Integer
or
"~>": (Boolean, Boolean) -> Boolean
Although the latter would probably make Martin Baker happy, I thing it
is too indistinguishable from -> that it might lead to bugs that are
hard to find.
To support cut&paste better, it would make sense to introduce another
layer that translates output from Format1D into something that can be
pasted back to the FriCAS command line.
Even better, however would be, if there were a mechanism to cut and get
exactly the value that %%(stepnumber) represents. Unfortunately, one
usually only wants to copy part of the output back as input.
Too unsolvable for now. So to make the story short, I am in favour of
introducing "~>" which in LaTeX seems to be \leadsto (with symbol
\rightsquigarrow, as defined in amsfonts.sty and amssymb.sty.
BTW, I wonder whether we could get rid of "TAG" and replace it with "~>"
or "LEADSTO" and either "->" or "TO", and "+->" or "MAPSTO" as the tags
that appear in an OutputForm.
Ralf
--
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/94b57cc6-a8f1-4f23-ac18-55c839ad0245%40hemmecke.de.
