On Thursday, July 16, 2015 at 4:28:40 AM UTC-7, Staś Małolepszy wrote:
> I don't think we should mimic JS code too much. There value in using a
> different syntax; we have different semantics.
We do, so it's very obvious to me that when we need to store things we can't in
JS data model, we need to change. For example default hash value is an example
where we extend. Thanks to that, everyone who ever saw JS, PHP, Python or
literally any of the popular languges that do store hashes will recognize this:
{
x: "foo",
y: "foo2"
}
And on top of that we can store additional bit of information that we need.
Minimal learning curve.
> PHP is a full-on language which was used to build Facebook. Please tell me
> you don't want to build the next Facebook in L20n ;)
No, and as you know, that was not my point. I'd appreciate if you didn't fall
back to demagogy.
> OK, how about the slash character which I used in my previous email when I
> mentioned imports? Note this is just part of the name, not a new kind of
> expression.
> (cldr/plural n)
> (intl/format-date datetime)
Hahaha. I'm ok with slash but exactly as part of expression syntax ;)
I imagine that we could introduce imports this way. "cldr" is automatically
imported.
> I think that Lisp is easy to learn because it's so simple. So it's not
> only on the merits of the simplicity of implementation that I suggest we
> use it.
I believe that that's your personal subjective experience not shared by
majority of people working with IT.
> However, I think much of our discussion here boils down to who likes
> S-expressions and who doesn't. We might want other people to weigh in. It
> would also make sense (as you suggest later) to see what we could take from
> this proposal that we both agree on and see what depends on the fact that I
> used Lisp for expressions (like dashes in names). I tried to compile such a
> list at the end of this email.
Awesome. I agree. Let's separate pieces that all three of us agree on, and lets
keep the ones where we disagree isolated.
> Why is it OK? L20n.js already is 70kb of JavaSciprt code, 30kb minified.
> It's huge. If we want people to use it at all we should be careful about
> adding more code to it.
I agree. And yet, I don't think that the solution is to impair users
experience, learning curve, and make them learn new expression syntax in order
to shave 10kb of that.
> I'd like to share that gut feeling but given how we haven't come up with UI
> concepts for L20n in tools like Pootle tells me that it's not going to be
> soon that we'll have all localizers writing expressions.
Agree.
> I don't want to optimize our syntax for a rare use-case of writing
> expressions. I think
> the gist of my thinking is to base expressions on something which is proven
> to work and easy to learn and implement. Remember v1's compiler and all
> the different types of functions it created to be secure? I don't want to
> repeat that.
And I pretty much believe that we should repeat much of that.
The thing with the syntax is that you can't optimize it for current properties
scope plus one/two things and then figure out how it works 2 years from now
when we'll add full expression syntax. We won't be able to change it. At all.
And I am actually quite confident that if we went with your expression syntax
that it would be a major reason for people not to adopt L20n.
> I think it's better suited for our minimal system because it's just one
> kind of syntax that we need to support.
I don't think we should design L20n syntax around its minimal form, but its
final form. That's why 1.x was so useful.
There was a project, not far ago, to design l10n library around minimal use and
then add features as they became necessary.
I thought we had our lesson.
> In the current http://l20n.github.io/spec/grammar.html you can make a
> mistake on every level of the expression syntax. In conditional expr you
> can forget the colon. In logic expr you can omit one operand. In call
> expr you can mix parens. In computed property and attribute exprs you can
> mix brackets. There's just so many permutations of errors and we need to
> support all of them.
And we do, because they are parse errors. Which is awesome.
> See https://gist.github.com/stasm/c99010a8ab6d467562ba#file-plural-old-php
> for how the complex branching needs to be implemented in one single
> expression using three ternary ifs. I think that's a limitation of the
> current C-like syntax.
I don't think it's a problem.
> We can move part of the error reporting to runtime which is usually more
> informative.
Disagree. Parse errors are way safer and more useful than runtime ones. The
earlier we catch a problem the better.
> We can also run static analysis on parse time (which is easy
> with S-expressions because code is data) and possibly detect problems
> before runtime.
Sorry, I don't even know if you're still serious. So, you're presenting static
analysis on S-expressions for its ability to detect errors as an advantage over
parser syntax errors...
> I think this comes down to teaching users that the opening paren is always
> special and calls system functions (unless you call a macro with
> (:my-plural ..)). Note that you can't call variables so it's not
> ambiguous. If we had a symbol for calling other symbols, the following
> would have the same meaning:
>
> (cldr-plural n)
> (call &cldr-plural n)
So, once again, you're basically saying that whatever other Web technology thay
know is not useful and we'll teach them the new way. That's the learning curve
I don't believe we should introduce.
> Looks like you didn't skip it all ;)
Oh I did. I can dig into that much more.
> I don't think I want people to be adding often in L20n.
They probably don't. But they may want to do execute logical operations or
arthmetic operations. And, as I pointed out in the part you skipped, the way
our civilisation teaches people about them (both in spoken/written languages
and logic/math) is with "A x B x C", not "x A B C"
> I expect expressions to be
> mostly used in macros and I expect macros to be written by tech-savvy
> localizers who can easily grasp RPN.
And I believe that those same localizers would much prefer to work with
JS-like, C-like syntax.
> I think the definition of "webby" isn't very clear and may mean different
> things to different people. I agree that RPN is non-standard on the client
> side.
I believe that when learning L20n, familiarity with Web technologies should
lower the entry barrier and make it easier to read/modify/write.
Even languages we think of as "next" like L20n for Rust, Python, C++ will have
the same characteristic. Unless we see lisp-like environment based L20n
implementation in the future, I believe my point is valid.
> CSS very much uses dashes. A lot of dashes everywhere! In ids, class
> names, property names, variables, you name it. Which in fact is my
> inspiration!
Does it mean you also want to play funny games with our syntax later on like
how CSS tries to deal with substraction operator in calc vs. ID's with dashes?
Sweet little decisions like "The + and - operators must always be surrounded by
whitespace. The * and / operators do not require whitespace" ?
Do you want to play games with:
--foo-faa = 100px;
--foo-faa2 = 50px;
color: calc(var(--foo-faa) - var(--foo-faa2));
And repeat the introduced inconsistency and secondary nature of variables.
> I want to be be able to do this:
>
> <p id="hello-word" l10n-id="hello-world"></p>
>
> and not this:
>
> <p id="hello-word" l10n-id="helloWorld"></p>
And I'm ok with doing the latter to avoid toCamelCase/fromCamelCase stories
between the language that doesn't have mathematical operators and one that does.
> In RPN it's not an operator if it's "in the middle". That's the benefit
> which I want to reap: make syntax unambiguous.
I mean substraction operator being "-" may be found in the middle of the ID as
"my-name". It's not an operator anymore from the parser perspective, but it
looks like one to a human eye.
> I know I'm repeating myself, but the whole point of RPN and S-expressions
> is to not have operators. Everything is a function call.
I feel like I'm telling you what is my perspective on what we should do with
L20n syntax and you respond by saying whats the point of some other approach.
> Ugh. That's even more hierarchy... :(
True.
> The consequences of using S-expressions for our use-case are as follows:
>
> - we can use dashes in entity names, like CSS
> this-is-a-valid-identifier
Not a goal. Would be nice to have, but quite minor value imho. Languages that
can substract should not have "-" in IDs.
> - we can use the single colon in references
> :brandName
I don't believe it's specific to S-expressions.
> - we can use the question mark in entity and macro names
> (:between? 2 1 3)
Not a goal.
> - every system function is called in the same manner, with (callee arg).
> With C-like syntax, there's the confusion between referencing and calling:
> @callee vs. @callee(arg).
Antigoal. I much prefer the syntax to easily catch when the user did something
else than he wanted. That's why we separated entity ID references from
variables. To catch early that the user wanted to reference an entity that
doesn't exist rather than saying "well, maybe it's a variable?".
Same with other pieces. I prefer to say "well, you wanted to call and it's not
callable" than "oh, you want something X with arg Y and we'll try some things
and maybe one of them will work".
> - the only thing that we need to reserve is the & prefix which denotes
> system functions. We can add anything there without the risk of clashing
> with the existing syntax. C-like syntax prevents us from ever using &, |,
> : etc.
And I don't see this as a value. "hello-$w|rl:d" IDs are not a huge value.
btw. I really believe that you're rationalizing your preference by trying to
present the ability to push arbitrary characters into entity ID's as a huge win.
> OTOH, we still need bool literals with the prefix like in
> S-expressions: @true and @false.
I don't think we decided on boolean literals. Last time we discussed, we
dropped them.
> - expressions use fewer special characters and are consistent. Compare the
> following indexes (I'm already using parts of my proposed changes)
> [@cldr/plural(n) user["gender"]]
> [(cldr/plural n) (attr user "gender")]
If you want to not distinguish globals separately (as you do in your sexpr
example) then don't put '@' in front of the global.
Except of that, yeah. The former looks much better to me.
> - we're not limited to single-expression bodies. we can pass any number
> of args to a function and define custom runtime behaviors. For instance we
> could add a `condp` function (condition using a fixed predicate, similar to
> a switch)
> (condp &= username
> "Mary" "she"
> "John" "he"
> "other")
So, we could add switch if we needed it. I don't see a huge value in it.
> Sure we could add a @condp global in the current syntax and call it with
> any numbers of args, but why would @condp be a function and not @if?
Because there's no major use case and we're dealing with basics for now.
>
> Do we want to say 'no' to all of these advantages?
Absolutely. I find the cost of introducing exotic syntax, increasing entry
barrier, diverging from expression language of other web technologies (CSS, JS,
DOM, JSON etc.) and moving lots of syntax errors to runtime. Absolutely.
> We want to build a small yet powerful domain language with expressions. Lisp
> syntax sounds like a perfect fit to me, tbh.
I don't agree with you.
> Wouldn't the following be confusing? @param looks like a global.
>
> /* @param $n Number of hellos */
> <hello[@cldr.plural($n)] { ... }>
Hmm, idk. I don't see it as very confusing.
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
