grammar rules for colon

[Martin]

Peter,

Do you know of any 'special handling' of colon in Aldor?

Its just that, in my implementing of the parser ':' does not seem to be binding as tightly as I would expect.

So for example:
a+b:c
The '+' is binding more tightly than ':' which seems to be saying 'a+b' has type 'c' rather than (as I was expecting) 'b' has type 'c'.

This is because the rules that use ':'
InfixedExprsDecl
Infixed
are defined outside of other prefix and infix rules rather than inside.

So do you know anywhere where this might be handled outside the grammar rules or have I missed anything in the grammar?

Thanks,

Martin

[Ralf Hemmecke]

> a+b:c

Are you saying that such an expression actually occurs in an Aldor
program? Can someone write a real example with that pattern?

Martin, do you actually mean

a + b::c

?

Ralf

[Martin Baker]

Thanks Ralf, I am concentrating so much on the syntax I an forgetting
about the meaning.

I guess that, although this is accepted by the parser, it needs to
generate an error.

Just so that I am clear about the semantics are we saying that 'b:c'
will only occur in a definition and not in an expression?

So please ignore my previous message, sorry about that.

Martin

[Ralf Hemmecke]

> Just so that I am clear about the semantics are we saying that 'b:c'
> will only occur in a definition and not in an expression?

I'm not the inventor of the language, but out of my head I only see the
following situations for ":"

a: T := ...
foo(): T == ...
foo(a: S): T == ...
for x:T in ... repeat ...
... Record(a: A, b: B) ...
... Union(a: A, b: B) ...

Of course foo can be a function/domain/category/package.

It's basically always... when one introduces a new identifier, one has
to say of what type it is.

Disclaimer: Maybe that list is not complete.

Ralf

[Martin Baker]

On 28/10/14 10:26, Ralf Hemmecke wrote:
> a: T := ...
> foo(): T == ...
> foo(a: S): T == ...
> for x:T in ... repeat ...
> ... Record(a: A, b: B) ...
> ... Union(a: A, b: B) ...

Ralf,

Thanks, this is very helpful, I have added these to the tests here:

https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.aldor.tests/src/com/euclideanspace/aldor/tests/ParserTests.xtend

I would welcome any additional tests.

Thanks,

Martin

[Waldek Hebisch]

Martin wrote:
>
> Its just that, in my implementing of the parser ':' does not seem to be
> binding as tightly as I would expect.
>
> So for example:
> a+b:c
> The '+' is binding more tightly than ':' which seems to be saying 'a+b' has
> type 'c' rather than (as I was expecting) 'b' has type 'c'.

In most uses of ':' precendence does not matter. In some case
':' is illegal. In example below

a+b:c == sumfun(a, b)

both cases make sense (trough binding to b seem more frequent
in real code). In

(a, b) : c +-> 0

we clearly want '(a, b) : c' to be argument to '+->'.

In old Spad ':' acted somewhat like 'pretend' only performing
even less checking. For such use more tight binding of other
operators make sense. But AFAIK such construct is not
present in Aldor. Still, I it is quite possible that
precendence was choosen in the past and kept to avoid
changing grammar.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

> In example below
>
> a+b:c == sumfun(a, b)
>
> both cases make sense (trough binding to b seem more frequent
> in real code). In
>
> (a, b) : c +-> 0

> we clearly want '(a, b) : c' to be argument to '+->'.

Waldek, can you give real Aldor constructs? In both expresssion a and b
have not been given a type.

The only thing that I can imagine is something like this:

%7 >> macro xx == x:Integer
Comp: 0 msec, Interp: 0 msec
%8 >> macro yy == y:Integer
Comp: 0 msec, Interp: 0 msec
%9 >> f:=(xx,yy):Integer +-> 0
() @ (x: AldorInteger, y: AldorInteger) -> AldorInteger

Well, for Martin's parser that means that he has to take macros into
account.

I haven't managed to make something like a+b:Integer == f(a,b) work.
Note also that in Aldor one defines

(x:Integer) + (y: Integer): Integer == ...

whereas in SPAD that would be

(x: Integer + y: Integer): Integer == ...

i.e. precedence in Aldor and SPAD is not identical.

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> > In example below
> >
> > a+b:c == sumfun(a, b)
> >
> > both cases make sense (trough binding to b seem more frequent
> > in real code). In
> >
> > (a, b) : c +-> 0
>
> > we clearly want '(a, b) : c' to be argument to '+->'.
>
> Waldek, can you give real Aldor constructs? In both expresssion a and b
> have not been given a type.

Does Aldor always demand all details in declaration?
Or maybe has "all or nothing" rule for argument and return
types? My understanding from reading AUG was that if other
declaration provides needed info then Aldor will merge them.
In the first case if '+' is on list of exported function
(or, more generally has forward declaration), then
I hope that Alsor will choose overload based on return type
(or when there is only one exported version choose this
one). In the second case context (for example if '+->' appears
as argument of 'map') may force argument types, my impression
was that Aldor can propagate type from context to place
where '+->' appear.

I did not try to run the examples trough Aldor. But if any
of them can not be completed to real program, then Aldor
works quite different than what is suggested by its
literature.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Martin Baker]

On 28/10/14 19:37, Peter Broadbery wrote:
> The following is accepted:
>
> default a, b: String;
>
> a+b: MachineInteger == # a;

Thank you - I have added this to the tests (and my code passes this test!):
https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.aldor.tests/src/com/euclideanspace/aldor/tests/ParserTests.xtend

So ':' has intentionally has a lower precedence than '+'
(I'm still not 100% sure that you are saying this is an intended feature
of Aldor rather than an artifact of how it was built?)
Either way, if existing code depends on it its good to have it in the tests.

I would also like to write some tests for the SPAD version of this code:
https://github.com/martinbaker/euclideanspace/blob/master/com.euclideanspace.spad/src/com/euclideanspace/spad/Editor.xtext

But I have not got round to writing tests for SPAD yet. In the meantime
I think I will put notes about the differences into the Aldor tests.

> ... interestingly lambda expressions require that types are fully
> specified for the parameters - I suspect that this is an
> implementation restriction (ie. no one has gone back and confirmed the
> need for it).

I don't have any tests for lambda expressions yet. I will try to derive
some from the syntax although that does not seem like best practice.
Ideally the tests would come from someone with a better knowledge of the
language than me.

> There are a couple of post-parsing compiler passes before the type
> inference phase of the compiler is started - normalization and
> checking - the first of these (abnorm.c) cleans up the parse tree, for
> example adding lambda expressions to definitions and a couple of other
> things. The following abcheck parse does some additional syntactic
> checks that the parser does not pick up.

This is good to know, I have not really got beyond the parser stage yet
(I have not even looked at the code embedded in the grammar). The Xtext
code generates an Eclipse EMF model (think AST - does Aldor use AST-like
structure?) Once I am happy with the EMF model structure then I guess
the first stage will be to do type inference on it so I guess I will
need to investigate this code.

Thanks,

Martin

[Ralf Hemmecke]

> On 28/10/14 19:37, Peter Broadbery wrote:
>> The following is accepted:
>>
>> default a, b: String;
>>
>> a+b: MachineInteger == # a;

Ah, yes. Right. That is why I failed. Aldor obviously needs "default" to
declare the type of variables.

http://www.aldor.org/docs/aldorug.pdf (Chp. 8.13, page 109)

Unfortunately, SPAD is not so explicit about such modifiers.

Ralf

[Pippijn van Steenhoven]

On Wed, Oct 29, 2014 at 10:07:11AM +0000, Martin Baker wrote:
> This is good to know, I have not really got beyond the parser stage
> yet (I have not even looked at the code embedded in the grammar).

That code is very straightforward.

> The Xtext code generates an Eclipse EMF model (think AST - does
> Aldor use AST-like structure?)

Yes, it uses an AST, which is one of the reasons why the parser action
code is straightforward.

> Once I am happy with the EMF model
> structure then I guess the first stage will be to do type inference
> on it so I guess I will need to investigate this code.

Why do you re-implement the entire frontend when you could add hooks in
the existing compiler to provide you with the necessary information?

--
Pippijn van Steenhoven

[Ralf Hemmecke]

On 10/29/2014 11:07 AM, Martin Baker wrote:
>> ... interestingly lambda expressions require that types are fully
>> specified for the parameters - I suspect that this is an
>> implementation restriction (ie. no one has gone back and confirmed the
>> need for it).

Peter,

are you saying that

Z==>Integer
import from Z
l: List Z := [3, 7, 5, 11, 2]
sort!(l, (x,y)+->x>y)

will not work (well it doesn't), i.e. the compiler cannot infer from the
type List(Z) of l and a function sort!: (%, (Z, Z)->Boolean) -> % from
List(Z) that the lambda expression must have type (Z, Z)->Boolean?

Personally, I am perfectly fine if the Aldor compiler cannot and needs
full declaration of types, because it's easier for a human to extract
type information. However, some people might find this too bloated.

Ralf

[Pippijn van Steenhoven]

On Wed, Oct 29, 2014 at 12:16:48PM +0100, Ralf Hemmecke wrote:
> Personally, I am perfectly fine if the Aldor compiler cannot and needs
> full declaration of types, because it's easier for a human to extract
> type information. However, some people might find this too bloated.

People like me :). Editor support for the language (e.g. by querying the
compiler frontend) can tell you the types by hovering/pressing keys/...
over the name in question. In OCaml, I press Shift+T in vim to get the
type of the thing under the cursor. In Aldor, we could have the same
thing.

[Ralf Hemmecke]

OK... fine! But currently I don't see such an Aldor-mode for Emacs or
vim or Eclipse. If such a support were available, I would probably be
more relaxed.

Obviously, does Martin re-program the parser, because it's not clear how
to easily extract the information from the aldor compiler itself.
Pippijn, it would be wonderful if you find time to help Martin with such
a hook.

Ralf

[Martin Baker]

On 29/10/14 11:13, Pippijn van Steenhoven wrote:
> Why do you re-implement the entire frontend when you could add hooks in
> the existing compiler to provide you with the necessary information?

I like the concept of the Eclipse Model Framework and Xtext. Ideally I
would like a pure Xtext (pure java) implementation but I accept that
this is a very long term aim. I realise there are other ways of doing it
but thats what interests me.

I wonder if a interim solution could be to use Peters code (If that
would be acceptable to Peter?). That is use Xtext for editing and all
the associated syntax highlighting, realtime error messages/warnings,
code completion, and so on. Then when the file is saved it would use
Peters code to compile and run the Aldor program.

In addition to Eclipse, Xtext are planning to support IntelliJ IDEA as
explained here:
http://blog.efftinge.de/

Martin

[Peter Broadbery]

I'd have absolutely no objection to you using my current work.  It's proceeding very slowly at the moment, mostly due to real life getting in the way.  The next version should have a better feature set for an IDE, excluding syntax highlighting and type information, but including incremental builds and error highlighting based on compiler output.

The compiler can produce an abstract syntax tree representation (-Fap) on compilation - this could be annotated with type information, although I'm not sure what would be the best form of this for xtext. There is also a symbol representation, which gives full signatures for top level types in a file (-Fasy).  These might provide enough information for syntax highlighting and refactoring.

I'd be happy to make changes to the aldor compiler so that the output form is in a form useful to an ide.

Peter

--
You received this message because you are subscribed to the Google Groups "aldor-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aldor-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Baker]

On 29/10/14 20:36, Peter Broadbery wrote:
> I'd have absolutely no objection to you using my current work. It's
> proceeding very slowly at the moment, mostly due to real life getting in
> the way. The next version should have a better feature set for an IDE,
> excluding syntax highlighting and type information, but including
> incremental builds and error highlighting based on compiler output.

Thanks, looks promising (my progress is also slow).

> The compiler can produce an abstract syntax tree representation (-Fap)
> on compilation - this could be annotated with type information, although
> I'm not sure what would be the best form of this for xtext. There is
> also a symbol representation, which gives full signatures for top level
> types in a file (-Fasy). These might provide enough information for
> syntax highlighting and refactoring.
>
> I'd be happy to make changes to the aldor compiler so that the output
> form is in a form useful to an ide.

Xtext parser generates two interlinked tree structures:

* EMF model (semantic model) - used for validation and eventually code
generation - I think this is the equivalent to the AST.

* Node Model - This is read by the Eclipse JFace text editor component
to display and enter the text. Leaves in this tree are tokens which
point to a chunk of text stream which must be contiguous and
non-overlapping with other tokens.

It is the interlinking between these two tree structures which allows
the IDE capabilities.

By default the structure is based on the grammar, that is, the nodes
correspond to grammar rules. However this produces a tree structure
which is too steep with unnecessary nodes, Xtext provides ways to modify
this structure. However this customisation is limited and there is a
requirement for a 1:1 mapping (many:one mapping not allowed) between
these two tree structures. This makes it very hard to support macros as
they would require a many:one mapping.

The reason I go through all this is to explain that there are a lot of
constraints to what I can do. However it would be good if I can try to
set this tree structure to be the same as your abstract syntax tree
representation (as far as possible).

Thanks,

Martin