> For an educational purpose we often must code one or two loops or
> tests. And I can only use interpreter with students. My purpose is
> about this << concrete >> mathematics, not teach a new language
> and the domains.
I understand your problem. But the only suggestion I can give here is:
Wai
Hi Ralf, Martin, Gaby and all,
I agree with all the Ralf mail, but I pain to explain that I don't see
how to use easily pairs/tuples in axiom when the coordonates aren't
of the same type (so I don't speak about Complex which can be a Vector)
By example (Integer, Float).
Of corse I may use List A
Hi Francois,
if you work in the interpreter, it is probably reasonable to use some
Record construction. However, if you do serious programming, then you
should consider Record as being a very low level data structure. That
is, you are certainly better off in defining a new type instead of just
> a: Record(Integer == 7, DoubleFloat == 0)
>
> is not allowed... But maybe that's a bug.
Let me quote aldorug.pdf section 14.6:
Record: Tuple Type -> Type
--
Records provide the basic updatable structure for aggregate data. Each
type argument to Record may be given in a
"Bill Page" <[EMAIL PROTECTED]> writes:
> > By the way Record(Integer, Integer) is not allowed in Aldor.
> > I do not understand why, isn't that a bug:
> >
> > %13 >> import from Record(String, String)
> > ...^
> > [L13 C29] #1 (Error) Duplicate selector/type pair
On 26 Feb 2008 19:28:16 +0100, Martin Rubey wrote:
> ...
> Possibly, this is the reason why Aldor allows Records
> also *without* labels:
>
Allowing Records without labels (oddly not allowed in Axiom) is
entirely analogous to allowing Union without labels (which is
allowed).
> ...
> By the way
Francois Maltey <[EMAIL PROTECTED]> writes:
> Dear Ralf and all,
>
> > In particular [List and] Record provide such bracket function of type [...]
> > which allows the usual list construction.
> >
> > (in Record(a: Integer, b: String, c: Float))
> >bracket: (Integer, String, Float) -> %
> >
Dear Ralf and all,
> In particular [List and] Record provide such bracket function of type [...]
> which allows the usual list construction.
>
> (in Record(a: Integer, b: String, c: Float))
>bracket: (Integer, String, Float) -> %
> which allows
>
>Arec: Record(a:Integer, b:String, c:Flo
On 26 Feb 2008 06:26:50 -0600, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
>
> | > In OpenAxiom-1.2.0, you can use { } to construct sets directly.
> |
> | Gaby,
> |
> | I don't know whether you want to make SPAD syntax more similar
> | to Aldor,
>
>
> I'd, like as much as possible, to ret
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> | Sure there is no semicolon, but I don't understand. (Unfortunately, I
> | can only speak of Aldor...). Cannot
> |
> |{1}
>
> The point is that if the contained single expression is all you have,
> there is no point in putting in a brace. If y
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| > | but in case Integer and Set(Integer) are the only things in scope,
| > what | should
| > | | a := {1}
| > | | stand for?
| > Well, I was talking about the interpreter where that is not an issue:
| > domains are loaded automatically on demand (assumin
> | but in case Integer and Set(Integer) are the only things in scope, what
> | should
> |
> | a := {1}
> |
> | stand for?
>
> Well, I was talking about the interpreter where that is not an issue:
> domains are loaded automatically on demand (assuming they are
> exposed, which is the case for L
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
| > In OpenAxiom-1.2.0, you can use { } to construct sets directly.
|
| Gaby,
|
| I don't know whether you want to make SPAD syntax more similar to Aldor,
I'd, like as much as possible, to retain good aspects of Axiom as
originally by defined Jenks&Sut
Francois Maltey <[EMAIL PROTECTED]> writes:
[...]
| The display of a finite set is {...} but it's impossible to construct
| a set without the list. This may be useful to forecast a construct
| for set without built the list. imagine a list of 10^5 equal elements.
| It seems it's impossible to u
Hello Waldek,
> I have just removed support for a few constructs that I consider
> obsolete:
> - usage of '(|', '|)', '(<' and '>)' insted of '[', ']', '{' and '}'
> - APL like syntax for maps
> - "scripted symbols" in the Spad parser.
>
> Rationalle: I would like to merge old and new parser -- t
15 matches
Mail list logo
