Partial and conditional export
Ralf Hemmecke
1) Since Union actually requires domains as arguments, there must be
some special compiler code dealing with that. In the long run, I would
like to either have a special domain Failed, which only has one element
called failed and which can be used as Union(D, Failed) or to have a
domain like Partial (see below).
2) I've tried to write a Partial domain, but with some problems.
---rhxBEGIN partial.spad
)abbrev domain PARTIAL Partial
Partial(V: Type): with
if V has CoercibleTo OutputForm then CoercibleTo OutputForm
inject: V -> %
retract: % -> V
failed: () -> %
failed?: % -> Boolean
== add
Rep := Record(val: V)
if V has CoercibleTo OutputForm then
coerce(x: %): OutputForm ==
failed? x => "failed"::Symbol::OutputForm
x.val :: OutputForm
inject(v: V): % == construct v
retract(x: %): V == x.val
failed: % == NIL$Lisp
failed?(x: %): Boolean == EQ(x, failed)$Lisp
---rhxEND partial.spad
(1) -> Integer has CoercibleTo OutputForm
(1) true
Type: Boolean
(2) -> Partial Integer has CoercibleTo OutputForm
(2) false
Type: Boolean
Any idea why I don't get true for (2)?
3) I actually would like something like in Aldor, i.e. that I can specify
failed: %
in the categorial part. But that doesn't work. Any chance that it can
work in some near future?
Ralf
Gabriel Dos Reis
| I don't like Union(SomeDomain, "failed") very much.
|
| 1) Since Union actually requires domains as arguments, there must be
| some special compiler code dealing with that. In the long run, I would
| like to either have a special domain Failed, which only has one
| element called failed and which can be used as Union(D, Failed) or to
| have a domain like Partial (see below).
OpenAxiom has had the domain Maybe for exactly that purpose for years now.
It is even more optional than Union in almost all cases.
-- Gaby
Waldek Hebisch
>
> I don't like Union(SomeDomain, "failed") very much.
>
> 1) Since Union actually requires domains as arguments, there must be
> some special compiler code dealing with that.
Yes, there is special case code, but it is probably more general
than you think: each string is regarded as being a type having
itself as unique value. If context requires String as a type,
then this unique type is silently coerced to String. Consider:
(2) -> "ralf"::"ralf"
(2) ralf
Type: ralf
(5) -> List("ralf")
(5) List(ralf)
Type: Type
(8) -> "ralf" has Type
(8) true
Type: Boolean
(9) -> "ralf" has SetCategory
>> System error:
The index 4 is too large.
The last result shows that this "string as a type" mechanism is not
fully implemented.
ATM I am not sure what to do about this. On one hand it allows nicer
syntax (without a lot of boilerplate to declare trivial types).
On the other hand it introduces irregularity into types system
and it is not clear how much effort is needed for complete implementation.
As I wrote in proivate mail you currently need Type as part of
category expression.
> 3) I actually would like something like in Aldor, i.e. that I can specify
>
> failed: %
>
> in the categorial part. But that doesn't work. Any chance that it can
> work in some near future?
>
But what the above do. Consider the following implementation:
Rep := Integer
n := 0
failed == (n := n + 1; n)
Is it allowed by Aldor? Related to this is question if runtime
interface is functional (this is each time you use 'failed' getter
function is called to fetch its value).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
>
> Rep := Integer
>
> n := 0
>
> failed == (n := n + 1; n)
>
> Is it allowed by Aldor?
Yes. (see below)
And the meaning would be that the value of failed is computed once (at
the time the *domain* is instantiated and never changed. While for a
definition failed() it would be evaluated every time failed() is called.
Aldor is *not* a functional language. Therefore constants and nullary
functions don't behave identically.
---rhxBEGIN const.as
#include "aldor"
#include "aldorio"
Foo: with {
foo: () -> Integer;
bar: Integer;
baz: Integer;
} == add {
n: Integer := 0;
foo(): Integer == {free n; n:=n+1}
bar: Integer == n:=n+1;
baz: Integer == n:=n+1;
}
main(): () == {
import from Foo;
a1: Integer := foo(); stdout << "a1 = " << a1 << newline;
a2: Integer := bar; stdout << "a2 = " << a2 << newline;
a3: Integer := baz; stdout << "a3 = " << a3 << newline;
a4: Integer := foo(); stdout << "a4 = " << a4 << newline;
a5: Integer := bar; stdout << "a5 = " << a5 << newline;
a6: Integer := baz; stdout << "a6 = " << a6 << newline;
}
main();
---rhxEND const.as
>aldor -grun -laldor const.as
a1 = 3
a2 = 1
a3 = 2
a4 = 4
a5 = 1
a6 = 2
BTW, note that in Aldor the function body (actually the lambda
expression) creates a new scope while the body for constants does not.
That's the reason for the "free" above.
In fact, it's equivalent to the following definition for the constant foo.
foo: ()->Integer == ():Integer +-> {free n; n:=n+1}
BTW, Rep is not needed for the domain/package Foo, since I have no
reference to %.
Ralf
Ralf Hemmecke
>>
>> 1) Since Union actually requires domains as arguments, there must be
>> some special compiler code dealing with that.
> Yes, there is special case code, but it is probably more general
> than you think: each string is regarded as being a type having
> itself as unique value. If context requires String as a type,
> then this unique type is silently coerced to String. Consider:
> (2) -> "ralf"::"ralf"
>
> (2) ralf
> Type: ralf
Interesting...
I first thought that this is bad (actually it is bad), but after a while
it reminded me of the enumeration type in Aldor.
%1 >> #include "aldor"
%2 >> #include "aldorinterp"
%3 >> E == 'ralf'
Defined E @ ? == Enumeration(ralf: Type)
%5 >> import from E
%6 >> ralf
ralf @ Enumeration(ralf: Type)
%7 >> 'ralf'
@ Join(
with
== add ()
,
Join(PrimitiveType, OutputType) with
== add ()
)
And the listing of the type comes from the implementation
extend Enumeration(T: Tuple Type): Join(PrimitiveType, OutputType) == add {
-- this is due to the compiler's internal handling of Enumeration
local TT(): Tuple Pointer == T pretend Tuple Pointer;
Rep == MachineInteger;
import from Rep;
(a: %) = (b: %): Boolean == rep a = rep b;
(outp: TextWriter) << (a: %): TextWriter == {
import from String, Tuple Pointer;
outp << string element(TT(), next rep a);
}
}
which can be found here...
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/aldor/src/datastruc/sal_string.as
i.e., the output is library defined.
In some sense I like the Aldor way more, since the meaning of the double
quotes is not overloaded too much to mean type as well as element.
On the other hand, I don't really care much about Enumeration. I didn't
yet have a big need for it.
So I would be rather in favour the remove the option that "blah" can
mean a type, but I know that Union(X,"failed") is too often used in the
Algebra code.
Ralf
Jalaluddin Morris
The INSTALL documentation says
- Lisp, one of: ... * sbcl, 1.0.7 or later, versions before 1.0.35
prefferred ...
but I cannot get fricas to compile with at least one later sbcl.
Perhaps to you could change "preferred" to something stronger.
Jalaluddin
Ralf Hemmecke
On my Ubuntu 10.04 system Fricas 1.1.0 compiled fine with
>sbcl --version
SBCL 1.0.29.11.debian
Can you provide the exact error message and more information about your
system. A build log would also be helpful.
Ralf
hemmecke
I don't think I have got a clear answer of why (2) doesn't give true.
Should I put this into the bugtracker?
Ralf
---rhxBegin ppp.spad
)abbrev domain PPP Ppp
Ppp(V: Type): with
if V has CoercibleTo OutputForm then CoercibleTo OutputForm
fail: % -> Boolean
== add
Rep := Record(val: V)
if V has CoercibleTo OutputForm then
coerce(x: %): OutputForm == x.val :: OutputForm
fail(x: %): Boolean == true
---rhxEnd ppp.spad
(1) -> Integer has CoercibleTo OutputForm
(1) true
Type: Boolean
(2) ->Ppp Integer has CoercibleTo OutputForm
(2) false
Type: Boolean
Waldek Hebisch
>
> Dear Waldek,
>
> I don't think I have got a clear answer of why (2) doesn't give true.
> Should I put this into the bugtracker?
>
> Ralf
>
> 3b6df8/4d8a36d15b4a7dd7#4d8a36d15b4a7dd7
>
AFAICS that example works fine now. IIRC some related example
does not work, so I consider this still an open bug. And yes,
if you have example that does not work in trunk, please put
it into bugtracker.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
Perfect.
Ralf