Gabriel Dos Reis wrote:
>
> Waldek Hebisch <hebi...@math.uni.wroc.pl> writes:
>
> | I am not sure you can keep constructors calls completely uniform:
> | we have 'construct', 'new' and a bunch of more specific constructors.
> | Below is patch that I propose (only to Product, algebra will also
> | need some adjustment). With the patch I can do:
>
> I like the general flavour of it. However I have one quibble.
>
> |
> | (3) -> Pr := Product(Integer, Polynomial(Integer))
> |
> | (3) Product(Integer,Polynomial(Integer))
> | Type:
> Type
> | (4) -> [1, x]
> |
> | (4) [1,x]
> | Type:
> List(Polynomial(Integer))
> | (5) -> [1, x]$Pr
> |
> | (5) (1,x)
> | Type:
> Product(Integer,Polynomial(Integer))
>
> I think *one* kind of syntax should be sufficient. Either square
> brackets or round brackets, but not both. The reason being that in
> typical Spad code and scripts, we do not have much of type annotations
> around to help quickly figure out what is meant. So, have only one way
> of saying something is a tremendous help for code/script understanding.
> I would vote for round brackets, but only marginally.
On _input_ side there is only one syntax: square brackets. Given
that round brackets are used to denote subexpressions and function
calls I am affraid that giving them extra meaning would lead
to confusion.
Concerning output, I believe that that best is use the same form
as for input. Round brackets in output come from original code,
but it is easy to change them to square brackets.
>
> | (6) -> p1 := [1, x]$Pr
> |
> | (6) (1,x)
> | Type:
> Product(Integer,Polynomial(Integer))
> | (7) -> p2 := [7, y]$Pr
> |
> | (7) (7,y)
> | Type:
> Product(Integer,Polynomial(Integer))
> | (8) -> p1 + p2
> |
> | (8) (8,y + x)
> | Type:
> Product(Integer,Polynomial(Integer))
> | (9) -> p1*p2
> |
> | (9) (7,x y)
> | Type:
> Product(Integer,Polynomial(Integer))
> |
> | Note that plain '[1, x]' produces a list -- one needs '$Pr' to choose
> | 'construct' from the product.
>
> Unless you specifiy the target, not? E.g.
>
> a: Pr := [1,x]
>
> or
>
> [1,x]@Pr
>
> -- Gaby
Sure, both works. My point is that interpreter will not introduce
product by itself, one must explicitly request it.
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
