axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Aldor-l] [Axiom-developer] Re: exports and constants


From: Bill Page
Subject: RE: [Aldor-l] [Axiom-developer] Re: exports and constants
Date: Sat, 29 Jul 2006 00:54:58 -0400

Christian,

On July 28, 2006 3:21 AM you wrote:

>...
> However, besides the parsing part, the extensions and all
> the other issues, if it's the way you choose, let me help 
> you getting it to compile and run. The following piece of
> code works:
> ... 
> 
> Just as expected. What did I do to get the code working?
> 
> I got rid of pile.
> Piles are simply a pain to my eyes.
> 

 :} I like coffee
 :{ You like tea
 ;} It really doesn't matter to me

See http://wiki.axiom-developer.org/SandBoxReflectionInAldor

> I turned exports into a function, as you'd probably want to 
> call it more than once.
>

I don't understand the relevance of whether exports is a function
or not. As a generator we can use it as often as we like. No?
 
> You yielded anonymous categories, created just within the 
> yield clause. This looked dangerous to me, so I turned them
> into proper definitions within MyDom's add part. This however
> gave problems when checking by has (as the Categories where
> no longer anonymous), so I had to use them already in the with
> clause, and moved them to the top-level scope (EXPORT0, ...).

Unfortunately Aldor treats named categories differently than
anonymous ones:

"7.5 ... Note that Aldor is constructed so that a domain is only
a member of a named category if it explicitly inherits from the
category - not if it merely exports the same collection of
(explicit) declarations."

I think being able to use anonymous categories is quite
important because we really do want to be able check for just
the presence of explicit declarations. The names artificially
assigned to these declarations is not important to us and of
course it would be rather awkward to have to name every
declaration in the system.

Also if I did use named categories shouldn't I use the 'define'
keyword since ultimately I will probably be interested in using
the value of these categories in forming other domains?

Still, it is reassuring that at least Aldor can compile this
stuff in the case of named categories!

> 
> I use the macro yieldT instead of simply yield, to tell the 
> compiler the yielded thing really is a Category. For some of
> my experiments this wasn't necessary -- for some it was.

This looks like another case of rather weak type inference in
the compiler.

> 
> I moved your "has" check in a separate function. It doesn't 
> seem to work out well, if the Cat part of "Dom has Sig" is
> not constant in scope.

No, I don't think that is a problem. I have an example that
works where Sig is not constant in scope. Maybe it was a
different issue?

> 
> That's it.
>

Wonderful! Thanks.
 
> > Except that I can not seem to get the "has" expression to
> > work the way I expected it to. Maybe this is another bug?
> 
> Your code demonstrates more than just one compiler bug ... ;)
>

Yes I guess so. While playing with this code we seem to have
found several different ways to make the compiler or the
generated code fail. :(
 
> > [ warning about "-fwritable-strings" ]
> > This is one more example of something that could probably be
> > easily and quickly resolved if Aldor was open source.
> 
> I doubt that. In May, I got a mail from one of the compiler 
> people telling me
> 
> I have spent the last couple of days looking into this 
> [Remark by CA: the  
> "-fwritable-strings" issue] , but the whole compiler uses 
> char * a = "abc"  
> (and the compiler is about 250K LOC).  In most of the places 
> they seem to be treated as const char *, but I still have a
> long way to go.
> 
> So somebody is already working on it, and I believe him, that 
> it's not one of those problems you fix in the 5 minutes till
> lunch break ;) Nevertheless, maybe he'd get help and feedback
> once the compiler is freed.

Absolutely! It is ridiculous and extremely disappointing that
we all have been waiting years now for things like this and other
compiler bugs to be resolved simply because of licensing issues
that could have been resolved a long time ago. :( From comments
posted to the Axiom Wiki web site it is clear there is a lot of
interest in Aldor - most even consider it essential for the future
of Axiom itself - so I have no doubt that there would be a lot of
resources available to work on such problems if only Aldor were
open source.

> 
> 
> > I do not see any advantage of the syntax
> >
> >> for s in exports(Mydomain) repeat ...
> >
> > over my
> >
> >   for s in exports$Mydomain repeat ...
> >
> > which does not involve any explicit external function call.
> 
> First of all (as I described in the upper part of my mail), 
> you wouldn't be able to get two different generators. Hence,
> if the generator ran out of elements, you cannot restart it
> -- very nasty thing ;)

No, I don't understand this. It seems to work fine for me at

http://wiki.axiom-developer.org/SandBoxReflectionInAldor

Perhaps I am missing something here?

> 
> The second issue is abstraction. Even if you get the thing 
> done your way, I'd never call exports$SomeDom directly.
> 
> Create some domain
> 
> Reflection( T: Type ): with {
>       exports: () -> Generator Category
> }
> 
> and use exports$(Reflection(SomeDom)).
>
> Thereby you can extend the whole reflection thing quite naturally,
> and if reflection gets built into compiler/runtime, you wouldn't
> have to change the programs relying on reflection, but only need
> to change the domain Reflection.
> 

Yes, that makes sense. Thanks.

Regards,
Bill Page.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]