[Aldor-l] [Aldor-combinat-devel] Should this "parser" work?

Christian Aistleitner tmgisi at gmx.at
Sun Oct 29 04:20:44 EST 2006


Hello,

> Yes, ok, I think you are right there. However, res is only modified (in  
> your
> sense) within grammar. Outside I don't access it anymore.

But you change the entries of res, after res has been used to call domain  
building functions (although these domains haved been built, when changing  
res's entries–(maybe) because of lazy evaluation).

> So this bit boils down to the question: what does constancy mean. In  
> fact, AUG
> is quite explicit here:
>
> The names appearing in an expression in type context may be
>
> * defined via "=="
> * imported via "import", or
> * function parameters which are nowhere updated.
>
> So, I guess, res.i := something is not allowed.

Yes.

> However, I'd say that the more important question is, whether it  
> *should* be
> allowed or not. It doesn't really make sense to have such a beautiful  
> language
> imposing conditions that actually restrict it's applicability.

I'd argue, that what you want requires awfully careful planning within the  
compiler.
It has really tremendous effect on type checking, and what can be done  
statically and has to be done at runtime.
Aldor is too sloppy here. Otherwise, you probably would not get your code  
to compile.

Are there languages, where you can create _arbitrary_, _recursive_,  
parametric types (I know that Aldor does not have parametric types ;) )  
smoothly at runtime?
I do not know any.
The only concept that I know of, where this is possible without any  
problems are topic maps.
But that's a concept to store data and not a programming language.

Maybe typed, functional languages allow to model these things. However, I  
am in strong doubt that this can be done in a smooth and proper way, as  
you still have an evaluation order. And that's one of the troubling things.

Can anyone present examples?

> I really hope that the current situation changes, i.e., that Aldor  
> becomes free
> and that people who are interested can work on an Aldor 2, which is a  
> little
> less restrictive...
>
> Do you agree? Or do you think that the current restrictions are
> necessery/sensible?

Sadly enough, I guess it's a very natural restriction. I guess, there are  
several workarounds (even for Aldor) if you just need certain kind of  
recursions, but for your grammar parsing code, you want the whole thing.
And it means lots of troubles to get this working in a compiler.

> If the latter is really the case, then I'd think there
> should be a different way to function grammar with the same (proposed)
> semantics as the current implementation, that does conform to the Aldor
> language.

Of course you can add tailored, new concepts for this problem to any  
compiler. But for Aldor, the top-most priorities to me are, to get a  
working compiler.

--
Kind regards,
Christian



More information about the Aldor-l mailing list