On Fri, Jan 6, 2012 at 5:04 PM, Ralf Hemmecke wrote:
> ...
> [in Aldor]
>
> ll: List List I := [[1,2,3],[4,5,6],[7,8,9]];
> a := first ll.2;
> b := first (ll).2;
> c := first(ll).3;
> ...
> a = 4
> b = 2
> c = 3
>
> Looks like parens force precedence of prefix function application over the
> dot application.
>
The FriCAS interpreter seems to behave the same way as Aldor. This is
OK, but having first been told that . binds more tightly than function
application, I think the way Shoe compiles boot code is more
consistent. Apparently in Shoe space has no meaning except to delimit
names when necessary, parenthesis only affect grouping and function
application is always denoted by juxtaposition. This means that a, b,
and c all have the same meaning.
(1) -> )boot ll:=[[1,2,3],[4,5,6],[7,8,9]]
(EVAL-WHEN (EVAL LOAD)
(SETQ |ll| (LIST (LIST 1 2 3) (LIST 4 5 6) (LIST 7 8 9))))
Value = ((1 2 3) (4 5 6) (7 8 9))
(1) -> )boot a:=first ll.1
(EVAL-WHEN (EVAL LOAD) (SETQ |a| (CAR (ELT |ll| 1))))
Value = 4
(1) -> )boot b:=first (ll).1
(EVAL-WHEN (EVAL LOAD) (SETQ |b| (CAR (ELT |ll| 1))))
Value = 4
(1) -> )boot c:=first(ll).2
(EVAL-WHEN (EVAL LOAD) (SETQ |c| (CAR (ELT |ll| 2))))
Value = 7
Changing the meaning always requires the use of parenthesis for grouping:
(1) -> )boot d:=(first ll).2
(EVAL-WHEN (EVAL LOAD) (SETQ |d| (ELT (CAR |ll|) 2)))
Value = 3
Given that the use of parenthesis with unary operators is optional, I
rather like it this way.
Now it seems annoying that Spad has yet another way of parsing this, see (2):
(1) -> )sys cat paren.spad
--- paren.spad
)abbrev domain MAIN main
I ==> Integer
main(): with
a:()->I
b:()->I
c:()->I
== add
ll: List List I := [[1,2,3],[4,5,6],[7,8,9]]
a() == first ll.2
b() == first (ll).2
c() == first(ll).3
---
(1) -> )co paren.spad
Compiling FriCAS source code from file /home/wspage/paren.spad using
old system compiler.
...
main is now explicitly exposed in frame frame1
main will be automatically loaded when needed from
/home/wspage/MAIN.NRLIB/MAIN
(1) -> a()
(1) 4
Type: PositiveInteger
(2) -> b()
(2) 4
Type: PositiveInteger
(3) -> c()
(3) 3
Type: PositiveInteger
(4) ->
> On 01/06/2012 10:12 PM, Waldek Hebisch wrote:
>> ...
>> I must say that for me this example show how bad is practice
>> of omiting parenthesis in function call with single argument
>> (note that with mandatory parenthesis there would be no question
>> of precedence -- call would always have higher precedence than '.').
>>
--
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.
