[HN Gopher] The Egison Programming Language
___________________________________________________________________
The Egison Programming Language
Author : ubavic
Score : 63 points
Date : 2023-04-29 18:18 UTC (4 hours ago)
(HTM) web link (www.egison.org)
(TXT) w3m dump (www.egison.org)
| sidkshatriya wrote:
| I really like this language. Very intuitive and simple syntax
| (once you understand the fundamentals). And very powerful too!
| The pattern matching examples get addictive after you've read a
| few.
|
| Egison can be used to build a symbolic math backend and do all
| kinds of pattern matching. But its really niche requirement and
| it's never really occurred to me in all this time "hey, this
| might be a good time to use Egison"
|
| I wonder when it might be a good idea to use Egison and if there
| are some current users in production.
| ink_13 wrote:
| Maybe I'm just a dummy who should stick to scripting, but I had
| exactly the opposite reaction: based on everything I've seen,
| this is wholly uninteresting. I can't imagine a single
| practical application that isn't more comprehensibly written in
| an existing language. But I feel the same way about Haskell,
| too.
|
| The older I get the more I value code that is easy to
| understand and debug by either myself or someone else months or
| years down the line when the original context might be
| forgotten. Ultra-dense syntax like this only makes that almost
| superhumanly difficult.
| wizzwizz4 wrote:
| It looks interesting, but I don't understand the syntax. The only
| documentation is a doctoral thesis, which contains the usual
| padding:
|
| > Interestingly, this basic definition of map has been almost
| unchanged for 60 years since McCarthy first presented the
| definition of maplist in [62].
|
| but it jumps from what looks like standard Haskell, to the new
| syntax, without explanation.
| 082349872349872 wrote:
| try https://www.egison.org/download/pmo-paper.pdf ?
| wizzwizz4 wrote:
| This comment originally said that the link was useless.
| Actually, this is a nearly-complete explanation of Egison's
| syntax. The only difference I've noticed so far is : for
| Egison's ::.
| 082349872349872 wrote:
| Edit: glad it helped!
|
| (This comment originally suggested attempting to reverse-
| engineer the syntax after learning the semantics)
| hyperhello wrote:
| "Egison makes programming dramatically simple!"
| dang wrote:
| Related:
|
| _The Egison Programming Language_ -
| https://news.ycombinator.com/item?id=17524239 - July 2018 (67
| comments)
|
| _Egison - Pattern-matching-oriented Programming Language_ -
| https://news.ycombinator.com/item?id=7992661 - July 2014 (33
| comments)
|
| _Egison: A Lisp Written in Haskell with Advanced Pattern
| Matching_ - https://news.ycombinator.com/item?id=7924168 - June
| 2014 (27 comments)
| pasquinelli wrote:
| > Egison makes programming dramatically simple!
|
| that doesn't mean anything, it should be "Egison makes
| programming dramatically simpler!"
| canadianfella wrote:
| [dead]
| 2h wrote:
| def twinPrimes := matchAll primes as list integer with
| | _ ++ $p :: #(p + 2) :: _ -> (p, p + 2)
|
| why do people do this? this is unreadable to me. what is the
| second line, a comment? then they somehow found a way to cram 11
| symbols in a single line after that. bravo?
| wizzwizz4 wrote:
| | begins a pattern match. ++ is list concatenation. :: means
| "thing-on-the-left is of type thing-on-the-right". That's all
| standard Haskell syntax.
|
| Egison seems to introduce some kind of advanced pattern-
| matching syntax with $ and #. I can't figure out what it is, or
| how it works; but I imagine it's quite simple once you actually
| know what it means.
| kristopolous wrote:
| > I imagine it's quite simple once you actually know what it
| means.
|
| The first part isn't notable. Olympian athletes, for example,
| do the most baffling of intricate movements in grace and
| simplicity. Instead it's the amount of effort and context to
| get to the understanding that's at play.
|
| Maybe this syntax is intuitive for a mathematician, formal
| logician or some other specialist, but as just a mere every
| day programmer, it looks like nothing I'm familiar with.
|
| This is fine. Just let's not pretend that it's low effort to
| get onboard
| kragen wrote:
| it's probably low effort for a 'mere every day' haskell
| programmer; it's just a question of what you're familiar
| with, not actually deep math
|
| (minor correction, as tromp points out, :: is evidently
| list construction, as in ocaml or haskell, not a type
| annotation)
|
| you asked what `matchAll primes as list integer with` meant
| ('what is the second line, a comment?') but apparently the
| person who answered you didn't understand that you didn't
| understand. it means 'evaluate the expression `primes`,
| which should have the type `list integer`, and then attempt
| to match the value resulting from that evaluation against
| each of the following expressions in order'
|
| deep math isn't simple to do even when you know what it
| means; it isn't just a matter of learning what all the
| symbols mean. this is just a matter of learning what all
| the symbols mean, like reading english instead of chinese.
| so to me your complaint reads like someone saying (in
| chinese) 'just a mere every day reader of novels, it looks
| like nothing I'm familiar with' because some text is
| written in english
|
| however, the situation is not quite so symmetric as with
| chinese and english. with a good notation, cramming lots of
| symbols onto a line is a really good lever to empower your
| reasoning ability. consider trying to explain how to play
| the seventeenth measure of pachelbel's canon in words. or
| writing assembly instead of c, even though they're both at
| pretty much the same level of abstraction
|
| pattern-matching really significantly improves the clarity
| of certain kinds of code, and you're missing out if you
| don't know what that's like
|
| i'm guessing that #() (the only weird part) is analogous to
| ${} in `-strings in javascript or #{} in ""-strings in
| ruby: it embeds an expression to be evaluated in a context
| where you wouldn't normally expect expression evaluation,
| in this case a pattern for pattern-matching
|
| (disclaimer, i don't actually know haskell, though i've
| implemented my own programming language featuring pattern-
| matching)
| kristopolous wrote:
| Thanks. As a correction, the comment you are directly
| replying to is the only one that I personally made.
|
| I just happened to agree with the sympathies of the first
| person and was trying to rephrase things in a more
| productive and positive manner.
|
| I appreciate the response not only for myself but for
| others who may be reading it as well. Thank you for
| taking the time.
| pasquinelli wrote:
| it must be simple because this code is, i presume,
| runnable.
| lelanthran wrote:
| > That's all standard Haskell syntax
|
| It's the reason Haskell has remained a niche language.
|
| > I can't figure out what it is, or how it works; but I
| imagine it's quite simple once you actually know what it
| means.
|
| You can't figure it out but you're sure it must be simple?
|
| Newsflash: if you, a 1 in a 500 programmer who knows Haskell
| syntax cannot figure it out just by context, it's nowhere
| near simple.
|
| Simple is when 9 out of 10 programmers understand the thing.
| lgas wrote:
| You're confusing simple and easy.
| lelanthran wrote:
| For the rare occasion when the author doesn't mean easy
| when they say simple, they should probably clarify that
| they mean non complex and difficult.
| kragen wrote:
| words have different meanings; the root sense of 'simple'
| is 'one-fold', that is, only having one layer rather than
| two or four, and that sense is still present in phrases
| like the spanish _hoja simple_ , meaning 'one-ply'
| (toilet paper, for example), but it's had multiple
| meanings for thousands of years including 'mentally
| disabled', 'honest', 'harmless', 'pure', 'unadorned',
| and, as you point out, 'easy'
|
| it's true that using a word with multiple meanings gives
| rise to ambiguity, and avoiding that by choosing a
| different word is desirable
|
| unfortunately there isn't a better term for 'simple' in
| the sense of 'not possessed of much detail' or 'composed
| of very few parts'; saying 'non complex' doesn't really
| help because 'complex' is often used to mean 'difficult'
| for the same reason 'simple' is often used to mean 'easy'
|
| except in hucksters' advertising brochures, i don't agree
| with your implicit assertion that all the polysemic
| complexity of 'simple' is merely historical, leaving only
| 'easy' as a live meaning; i think all the meanings i
| listed above except for 'harmless' have some currency
| today, even merely in english
|
| https://en.wiktionary.org/wiki/simple#Adjective lists
| nine main meanings of which seven are current, though i
| admit i just added the 'easy' one myself; it wasn't
| listed previously (i think because of confusion induced
| by the polysemy of 'complicated')
| stcg wrote:
| Related: the great and timeless talk called "Simplicity
| Matters" by Rich Hickey -
| https://www.youtube.com/watch?v=rI8tNMsozo0
|
| (By the way, _any_ talk by Rich Hickey is worth watching)
| tromp wrote:
| Interpreting :: as a typing judgement makes no sense here.
| What does make sense is interpreting :: as a list "cons",
| i.e. as : in Haskell.
| Avshalom wrote:
| >why do people do this
|
| do what? write programming languages that you don't already
| know?
| pmontra wrote:
| Investing so much creativity into obfuscation of meaning.
| pasquinelli wrote:
| >>> why do people do this
|
| >> do what? write programming languages that you don't
| already know?
|
| > Investing so much creativity into obfuscation of meaning.
|
| that's just saying the same thing in different words. of
| course the meaning is obfuscated to you, you don't know how
| to read it.
| galaxyLogic wrote:
| I'm starting to see the allure of plain Lisp. All it has is
| functions and functions have names which convey a meaning. Plus
| some syntax for creating macros.
|
| Now CAR and CDR don't convey a lot of meaning I agree. But
| that's just a matter of poor naming. They should (in my
| opinion) be called 'first' and 'rest', or something similarly
| meaningful and descriptive.
|
| Of course short-hands and aliases are good for most often used
| functions. But I would prefer those to be aliases, with a
| proper descriptive name available as well.
|
| And operator precedence, that makes code in a different
| language really hard to understand. Parenthesis make it
| explicit. Keep it simple. That makes code more verbose but then
| you can use macros to make it less so.
| msla wrote:
| > Now CAR and CDR don't convey a lot of meaning I agree. But
| that's just a matter of poor naming. They should (in my
| opinion) be called 'first' and 'rest', or something similarly
| meaningful and descriptive.
|
| Some Lisps do that, but I think it's important to remember
| what CAR and CDR actually do, which isn't always related to
| lists: They access what's being pointed to by the pointers in
| a cons cell, which can be used to create multiple data
| structures in a given Lisp, so keeping the names abstract
| prevents the code from having the wrong names all over the
| place. For example, if I'm using cons cells to construct a
| key-value store, CAR isn't "head of list" it's "key" and CDR
| isn't "tail of list" it's "value" especially if the cons cell
| looks like this: (a . b) such that the CDR isn't a list of
| any kind.
|
| In Common Lisp, of course, there are more efficient data
| structures for a lot of what older Lisps used cons cells for,
| so this is less of a concern, but I still think it's
| important to prevent confusion.
| galaxyLogic wrote:
| Good to understand. So maybe key() and value() would be
| good, more descriptive names for them then.
|
| But I do think using a natural-language name like CAR even
| if very specialized, is better than using single-char
| symbols as function names.
___________________________________________________________________
(page generated 2023-04-29 23:00 UTC)