Live data from Hacker News

The Earl Grey programming language

breuleux.github.io

51–60 of 137 posts

Re: The Earl Grey programming language

#51

Earlier quoted context omitted.

There's plenty of precedent. It's just rare for a reason. I'm not sure allowing slightly easier access to CSS syntax justifies it.

Out of curiosity, what's that reason?

Because a hyphen is also the subtraction operator. It's extremely weird if a+b is valid syntax but a-b is not.

This language may require whitespace around all operators, though. It's not clear to me.

Re: The Earl Grey programming language

#52
post #17

Hyphens in variable names. It's a bold strategy for a scripting language, Cotton.

I think a lot of lisps use hyphens in variable names

Yes, because Lisp uses prefix notation and hence there is no ambiguity: a-b cannot be interpreted as subtraction in lisp but in EG ...?

Re: The Earl Grey programming language

#53
post #15

fact(match) = 0 or 1 -> 1 n -> n * fact(n - 1) why not simply fact(0 or 1) -> 1 fact(n) -> n * fact(n - 1)

I think the first one is a single function that has pattern matching for the parameter while the second one is defining the function twice and relying on the language to call the right one based on the parameter.

I think in Erlang the function identification is the name and the arity and this is as close I know of what you would like to have.

Re: The Earl Grey programming language

#54
post #45
post #38

Earlier quoted context omitted.

I think it's unfortunate that this is currently the top comment on this post. Someone puts hundreds of commits of work into a nifty language with a nice feature set (including compile-to-js) and awesome integrations, and this is what they get on HN... I think this looks like a great project, we can never have too many programming languages to play around with.

>we can never have too many programming languages to play around with. Wait until we start having legacy code in all those languages. >we use 30 different compile-to-js languages used in our projects(that are no longer being developed) and you have to maintain it.

Shouldn't the tech leads in that case be picking one well maintained variant, then?

Re: The Earl Grey programming language

#57
The "fact(match)" is very strange. In Haskell you have "lambda-case" and in Ocaml you have "fun" as syntaxes to define lambdas that pattern-match on the argument.

That said, I really like the inclusion of async and a DSL for documents. These two are things that benefit a lot from having language support.

Re: The Earl Grey programming language

#58

Earlier quoted context omitted.

There's plenty of precedent. It's just rare for a reason. I'm not sure allowing slightly easier access to CSS syntax justifies it.

I'd love to hear why people prefer underscores over hyphens. I think I grew out of syntax fanboy-ism, but C and python __private__, _special_variable are everything but readable to me. They break the visual line too much. Even historically it was a weird symbol, originally a line break that made it into non-space separator in PL/1, then almost everywhere. Before that it was pure formatting, a typewriter glyph to be o…

> I'd love to hear why people prefer underscores over hyphens.

Because I like subtraction.

Re: The Earl Grey programming language

#59
post #57

The "fact(match)" is very strange. In Haskell you have "lambda-case" and in Ocaml you have "fun" as syntaxes to define lambdas that pattern-match on the argument. That said, I really like the inclusion of async and a DSL for documents. These two are things that benefit a lot from having language support.

"fact(match)" is just making use of a generic feature: the "match" keyword in a pattern dictates that the body defines a sequence of sub-patterns to match at that position. An argument uses pattern syntax, so it works there, but it works in other situations, for example this contrived example:

    f(x, y) =
       match x:
          {m, n} ->
             match m:
                 n + y
                else -> m + n + y
          n -> n + y
Can be rewritten:

    f(match x, y) =
       {match m, n} ->
           n + y
          else -> m + n + y
       n -> n + y
So you can match hierarchically like that (sorry if the example is strange, it's not supposed to mean anything).
Post reply on HN