Differences between XL2 and XLR
Christophe de Dinechin
> I have been studying XLR and I see some similarities to XL2, it appears to be another way of building the parse trees in which case it could be built within the XL2 wrapping of modules etc.
The parse trees and parsing algorithms are practically identical. There are some subtle differences, mostly improvements in the XLR version that I didn't backport to XL2 yet:
- There is no postfix in XL2, I thought at the time that prefix would be enough, i.e. 0! in XL2 is a prefix with 0 on the left. It just doesn't work :-)
- XLR uses spacing to disambiguate "write -X" and "x - y". XL2 doesn't have the corresponding code yet.
- In XL2, indentation is ignored after a trailing infix, but not in XLR. This means that in XL2, you can write:
A + B +
C + D +
E + F
whereas in XLR you would need parentheses for this, but then you can write the following
slide "Slide title",
* "First bullet"
* "Second bullet"
In general, XLR is slightly better in my opinion than XL2, but I must admit I didn't have time to modify the XL2 side to match.
Henry Weller
> some subtle differences, mostly improvements in the XLR version that I didn't
> backport to XL2 yet:
> - There is no postfix in XL2, I thought at the time that prefix would be
> - enough, i.e. 0! in XL2 is a prefix with 0 on the left. It just doesn't work
> - :-)
That does sound a bit contrived :-)
> - XLR uses spacing to disambiguate "write -X" and "x - y". XL2 doesn't have
> - the corresponding code yet.
Using spacing to delimit operators does make life a lot easier and if it were a
requirement then - could be used in identifiers as in Lisp; this is a move I
would support.
> In general, XLR is slightly better in my opinion than XL2, but I must admit I
> didn't have time to modify the XL2 side to match.
I am a bit concerned that you will not find the time or perhaps not have the
inclination to continue with XL2 now that you have much more direct and pressing
needs for XLR.
Best regards
Henry
Christophe de Dinechin
On 11 mars 2011, at 23:48, Henry Weller wrote:
>> The parse trees and parsing algorithms are practically identical. There are
>> some subtle differences, mostly improvements in the XLR version that I didn't
>> backport to XL2 yet:
>
>> - There is no postfix in XL2, I thought at the time that prefix would be
>> - enough, i.e. 0! in XL2 is a prefix with 0 on the left. It just doesn't work
>> - :-)
>
> That does sound a bit contrived :-)
Actually, with the "more specialized wins" rule in XL2, it works better than in XLR. Consider N! : N is a "wildcard" (because it's found in the parameter list), but ! is a fixed symbol. So you can match the expression to the pattern with the "more specialized wins" rule. That's one reason I never really needed the postfix node in XL2.
>> - XLR uses spacing to disambiguate "write -X" and "x - y". XL2 doesn't have
>> - the corresponding code yet.
>
> Using spacing to delimit operators does make life a lot easier and if it were a
> requirement then - could be used in identifiers as in Lisp; this is a move I
> would support.
Actually, spacing is not really delimiting operators. x-y and x - y are the same. Only x -y is treated differently. Now, using - in separators is something that more and more people are familiar with (e.g. CSS). Why not? Need to think about it.
>> In general, XLR is slightly better in my opinion than XL2, but I must admit I
>> didn't have time to modify the XL2 side to match.
>
> I am a bit concerned that you will not find the time or perhaps not have the
> inclination to continue with XL2 now that you have much more direct and pressing
> needs for XLR.
This is a very valid concern. Limited resources have always been a primary issue when developing XL2. This is why this project has taken so long. Consider this: XL had working variadic templates in 2001, 10 years ago, 5 or 6 years before it was even on the drawing board for C++.
That being said, I have not given up in 15+ years, and I have no intention to give up. But honestly, if you depend on XL2, it is likely to move too slowly for your needs. We'd need 10 to 15 dedicated core developers, like Go or other languages. I have never been able to really build such a community around XL2, probably my biggest failure with this project. If you want to be able to use XL2 one day, that's really the first problem to solve. And history shows I don't know how to solve it...