Earlier quoted context omitted.
> a couple of newlines A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language. > it's much harder to tell the difference between " " and " ". Can't think of any scenario where you'd need to. If you do mix hard tabs with…
> A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language. A code block is *not* the same as a paragraph. It is the same as a part/chapter/section/subsection/subsubsection. (Think about it.) In formal writing, these are…
Erg: a statically typed language that is Python compatible
191–194 of 194 posts
Re: Erg: a statically typed language that is Python compatible
#192Earlier quoted context omitted.
> a couple of newlines A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language. > it's much harder to tell the difference between " " and " ". Can't think of any scenario where you'd need to. If you do mix hard tabs with…
> A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language. A code block is *not* the same as a paragraph. It is the same as a part/chapter/section/subsection/subsubsection. (Think about it.) In formal writing, these are…
Right, but for Markdown they're a difference in output despite the input \n\n being just whitespace, and for the final text they have semantic effect despite being just a gap between text. I don't think the argument was whether the particular semantic meaning of paragraphs exactly matches the semantic meaning of code blocks, just that they do have semantic meaning.
> This has nothing to do with the lack of significant white space and everything to do with terrible language design
It's a problem that illustrates how indentation indicates intent, and would be fixed by semantic whitespace. I agree that if a language is going to disregard whitespace, then {...} should be consistently required to partially make up for it.
> I guess that most humans are used to just automatically write and type semantic white space
My experience has been the opposite: looking over huge blocks of completely unindented VBA/MATLAB code written by people with little prior programming knowledge, and being thankful that data science is moving more towards Python. Likely a different crowd than those being actively tutored in C++.
But yeah there are bigger, often harder to automatically fix, issues with beginner code. PyCharm has PEP 8 lints by default for things like variable name conventions, which help but are still commonly ignored.
Re: Erg: a statically typed language that is Python compatible
#193Earlier quoted context omitted.
Scala is going to get "full" dependent types at some point. It's work in progress for a long time already (and it's actually quite close by now). Besides that your argumentation makes no sens anyway whatsoever: Fully dependent languages are undecidable by type inference alone. So you're forced "to write everything twice" especially in such a powerful language. But that's actually the whole point of it! Like you dupli…
> "full" dependent types From the quotation marks, I surmise that you're wondering what a non-full dependent type system could possibly mean. I added that qualifier because Python, in fact, had one, last I checked, with its `Literal` type ( https://peps.python.org/pep-0586/#rejected-or-out-of-scope-i... ), which is "a very simplified dependent type system", according to the PEP, but "True dependent types" are out of…
That wasn't the point. Scala has a few variants of dependent types but that features are constantly diminished as not being "full" (or sometimes even "real") dependent types. I don't buy that as dependent types aren't defined as being like dependent types in say CoC (the Calculus of Constructions). For example Singleton types match also the definition of dependent types when derived from literals; even such types are still weaker than the usual "full" dependent types à la CoC.
Regarding Python: Python has only one type, the "almighty-python-runtime-type", as it's a "dynamic" (unityped) language. Therefore it does not make much sense to talk about "types" in Python at all…
https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...
Re: Erg: a statically typed language that is Python compatible
#194Earlier quoted context omitted.
Oh, man, have I got a treat for you: go checkout hylang.org - Hy is a lisp that (ab)uses the python AST to give you access to the entirety of python, but gives you a pretty lisp syntax.
I've always been super interested in Hy but couldn't ever get it working. Any suggestions for forums or good installation instructions or tutorials? I live Clojure and also have to deal with a lot of Python at work so would be awesome to use lispy syntax to write my Python stuff