On Thu, Jul 16, 2015 at 8:21 PM, Zibi Braniecki <
[email protected]> wrote:
>
>
> {
> x: "foo",
> y: "foo2"
> }
>
> And on top of that we can store additional bit of information that we
> need. Minimal learning curve.
>
I see how this might be minimal learning curve for someone who understands
a bit of programming. For those who haven't had such experience at all,
this is black magic. It's familiar to us and it's easy to confuse this
with thinking that this is *the* minimal learning curve. In fact, I could
argue that S-expressions are the minimal learning curve too!
>
> > 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.
>
It's not. It's a crucial point. PHP was badly designed without
namespaces. It's bad design because PHP is a general programming
language. It currently has over 5,000 built-in functions. That's
terrible. L20n is a domain-specific language and I hope we'll mange to
keep the number of built-ins below 100 and more like 10, really.
>
> > 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.
>
OK, that's an interesting approach which I like. This is also related to
the sentiment Richard has about globals vs. developer $vars. Maybe we
could get rid of global completely with such imports?
>
> > 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.
>
And what's that belief based on?
> 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.
>
S-expressions give us that flexibility by moving syntax constructs like +
operator to runtime, where + is a function call. The syntax stays the same.
> 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.
>
Why are you confident again, here?
> 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"
>
You say "they probably don't" and then you say "may want to execute
arithmetic operations". What kind of operations are those? Can you think
of specific examples? Realistically, do we need more than some kind of
plural support which can be extended to take into account metadata bools
like "is animate" or "is a person" and some kind of string lookup function
(startsWith, endsWith)?
I think we're overengineering L20n big time. It shows in the discussion
about the dash in identifiers. Is L20n supposed to be a programming
language? Or is it supposed to be a data store format with some expression
syntax? I firmly believe it's the latter. We'd be using YAML if it wasn't
for multiline strings on our side and significant whitespace on YAML's
side. I want the expression syntax to be well thought-out and baked into
the language, but perhaps we're focusing too much on it and in fact we're
ending up designing the whole syntax for an edge-case!
> 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" ?
>
No, and that is why S-expressions are part of my proposal. I fully believe
that if our syntax is not based on S-expressions we should not allow dashes
in names. My point was about being webby. CSS ids feel webby to me and we
don't have them right now.
> 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.
>
If we allow dashes in names there won't be need for toCamelCase. We can
fix what DOM got wrong :)
> > 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.
>
That's not true. All Lisps can substract :) Arguably, the dash is more
webby: CSS and HTML both support it.
> > - we can use the single colon in references
> > :brandName
>
> I don't believe it's specific to S-expressions.
>
It depends on the character that we use for entity references, but you're
right, it's not specific.
>
> > - 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".
>
Is @os a property or a method? Is @hour a property or a method?
@deviceType? I think we're creating confusion by allowing globals to be
both callable and non-callable. I don't think we'll want to pass things
around be reference, so maybe they should always be callable?
> And I don't see this as a value. "hello-$w|rl:d" IDs are not a huge
> value.
>
Of course not, but using & or | in the future as a special name might be
helpful. C-like syntax forbids a lot of characters, really. Also, naming
bool-returning functions as `person?` instead of `isPerson` is a nice
humanizing aspect that I really like in Lisp and Ruby.
-stas
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
