[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