Paul Onions wrote:
>
> I have a problem with FriCAS 1.3.5 using records inside a function.
> As an example consider the following code, where I define a record
> type and simple constructor and accessor functions:-
>
> (1) -> R ==> Record(a:Integer, b:Integer)
> Type: Void
> (2) -> makeR(x:Integer, y:Integer):R == [x,y]
> Function declaration makeR : (Integer, Integer) -> Record(a: Integer
> ,b: Integer) has been added to workspace.
> Type: Void
> (3) -> getA(r:R):Integer == r.a
> Function declaration getA : Record(a: Integer,b: Integer) -> Integer
> has been added to workspace.
> Type: Void
>
> I then create a record and call my accessor function on it to retrieve
> one of its components. This works as expected.
>
> (4) -> r := makeR(2,3)
> Compiling function makeR with type (Integer, Integer) -> Record(a:
> Integer,b: Integer)
>
> (4) [a = 2, b = 3]
> Type: Record(a: Integer,b: Integer)
> (5) -> getA(r)
> Compiling function getA with type Record(a: Integer,b: Integer) ->
> Integer
>
> (5) 2
> Type: PositiveInteger
>
> Now I'll create a variable in the global workspace of the same name as
> one of the selectors. This breaks things, but this is expected
> because the selector name used in my accessor function is evaluated
> (as described in the documentation).
>
> (6) -> a := 0
> Compiled code for getA has been cleared.
>
> (6) 0
> Type: NonNegativeInteger
> (7) -> getA(r)
> There are 29 exposed and 5 unexposed library operations named elt
> having 2 argument(s) but none was determined to be applicable.
> Use HyperDoc Browse, or issue
> )display op elt
> to learn more about the available operations. Perhaps
> package-calling the operation or using coercions on the arguments
> will allow you to apply the operation.
> Cannot find a definition or applicable library operation named elt
> with argument type(s)
> Record(a: Integer,b: Integer)
> NonNegativeInteger
> <... snipped ...>
>
> So now I try to create a more robust accessor function to stop this
> happening (following guidance in the documentation):-
<snipped description of errors>
> So, is this a bug? And if so, is there a workaround?
I do not think this is a bug. Rather a deliberate limitation.
If you look deeper you will see consistent pattern: interpreter
language misses features needed for "large scale" programming,
instead tries to be somewhat forgiving for interactive use.
On small scale it is not hard to avoid name clashes, and while
interpreter makes some effort to limit clashes with library
functions it misses features available in Spad.
It would be nice to remove interpreter limitations, but given
that iterpreter design is based on then, this is large task
and prgress is slow.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/E1iUXes-00062b-42%40hera.math.uni.wroc.pl.
