Live data from Hacker News

Sylph: the programming language I want

eev.ee

101–110 of 119 posts

Re: Sylph: the programming language I want

#101
post #93
post #27

Earlier quoted context omitted.

Just put two spaces before each line ( https://news.ycombinator.com/formatdoc : "Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)"): import os import random def do_something(x): if x: fd = os.open(x)

Why the downvote?

Because petulant children can downvote here. It was a good comment, and I learned something from it. So thanks!

I wonder how a comment system that made downvotes public would do. And further, if the downvoter was required to give a one line justification. And further yet, if the downvote itself could be downvoted.

Oh, scrap all that. I'd like to see would happen if downvotes were eliminated entirely, so things sorted to the top purely by upvotes.

Re: Sylph: the programming language I want

#102
post #53

Earlier quoted context omitted.

This really assumes that syntax is a purely superficial thing, but in reality syntax reflects the underlying semantics of the language as well. For example, a typical C program (sequence of imperative statements) displayed with lisp syntax will look awful, yes, but so will a typical lisp program (deeply nested expressions) rendered with C syntax. Getting rid of text doesn't change the fundamental issues: Languages wo…

Different semantics can be approached by several different methods though - one can simulate an interpreter for a "guest" language in a host language - or the languages can provide an FFI for interoperability. While we have various means to combine the two different semantics of a language, we have no means to combine their syntax without encountering ambiguity problems. This is why storing code in a structured forma…

Composing a larger program, by combining functions in different languages in a new framework, seems to take things in the direction of large and complicated programs. Would it not be simpler to write smaller, independent, individually named and reusable programs in several languages, according to each language's strengths, and pipe the output from one of these programs to the other? As an added bonus not all the programs need to understand the entire problem domain.

Re: Sylph: the programming language I want

#103

Earlier quoted context omitted.

You're using a double standard, here: if the computer is good at indenting brace based languages, then it is equally good at indenting languages without braces just based on the grammar.

Not at all. In this case, by 'languages without braces' we mean languages where indentation is part of the grammar. Python's grammar includes explicit INDENT/DEDENT tokens. It is impossible to reindent this mangled python: if z: print 'a' print 'b'

Editors know that a python line ending in a colon must be indented and so indent it automatically. It wouldn't be hard to use the same method to reindent it.

Re: Sylph: the programming language I want

#104

Earlier quoted context omitted.

What? Haskell has a base language expressed in terms of braces and semicolons, and a relatively simple set of layout rules defining how the compiler can insert these braces and semicolons automatically.

Right. I meant that Haskell has a whole lot of other weird syntax to consider, that make it hard to read compared to Python. It's use of indentation is not one of the problems.

Charitably speaking, that is very confusing considering you responded to:

> Haskell is particularly guilty of creating several different indenting possibilities, and does require constant intervention

with:

> You really have to design your language around it for it to work well. Haskell has a a lot of syntactic craziness in the name of simplicity.

Where "it" would seemingly be indentation, implying Haskell wasn't designed around making indentation simple.

Re: Sylph: the programming language I want

#105
post #53

Earlier quoted context omitted.

Different semantics can be approached by several different methods though - one can simulate an interpreter for a "guest" language in a host language - or the languages can provide an FFI for interoperability. While we have various means to combine the two different semantics of a language, we have no means to combine their syntax without encountering ambiguity problems. This is why storing code in a structured forma…

Composing a larger program, by combining functions in different languages in a new framework, seems to take things in the direction of large and complicated programs. Would it not be simpler to write smaller, independent, individually named and reusable programs in several languages, according to each language's strengths, and pipe the output from one of these programs to the other? As an added bonus not all the prog…

This line of thinking ignores simple domain specific languages like SQL, which 9 times out of 10 are held in strings in the host language (and thus undergo no static checking because the contents of strings are basically ignored by the compiler. There are other examples too: html files contain nested Javascript, CSS etc. PHP files host HTML. C++ effectively hosts C and assembly.

Haskell hosts a few dozen languages called "extensions" - specified in a {-# LANGUAGE #-} pragma at the top of the file. This one is of particular interest because the language appears to have some kind of extensible syntax which allows these extensions to occur - except when you look under the surface, they're all combined into the same grammar and they all interact with each other, such that other extension developers basically need an entire understanding of all of them to know where conflicts may lie.

Using a framework like LanguageBoxes instead to host these kinds of extensions would allow individual developers to put their own, independant extensions into the language, without having to hack on the compiler and rebuild it.

Also, writing several independant programs and using any IPC to communicate between them is ideal in theory, but in practice is more often unsuitable - because Unix processes are a bloat. They take time to initialize and use lots more memory than necessary for what amounts to running code for a small amount of time and discarding of it. Perhaps if we had a more lightweight model of processes ala Erlang style, this kind of reusability would be practical and not just a good philosophy to follow.

Re: Sylph: the programming language I want

#106
post #74

the section on loops, in particular, really captured a small but ubiquitous frustration in every language I've used. we really should be able to say "this is the first iteration", " this is the last iteration" (though that one might not always be possible) and "did the loop run at all?" without getting into index comparisons or manually setting and modifying flags.

Peel 6 has phasers to do exactly this.

beautiful. i really should take the time to explore perl 6.

Re: Sylph: the programming language I want

#107

Earlier quoted context omitted.

Not at all. In this case, by 'languages without braces' we mean languages where indentation is part of the grammar. Python's grammar includes explicit INDENT/DEDENT tokens. It is impossible to reindent this mangled python: if z: print 'a' print 'b'

Editors know that a python line ending in a colon must be indented and so indent it automatically. It wouldn't be hard to use the same method to reindent it.

No, lines following a line ending in a colon must be indented.

But the OP's point is that you can't know how many lines make up the indented block, since there is no explicit block-end-marker left if the indent is gone.

Re: Sylph: the programming language I want

#108
post #88

Earlier quoted context omitted.

> a machine can look at how the arguments are used and make some educated guesses. The big problem is that humans have to do the same. Why? Just get the machine to do it. It's like when you see programmers doing arithmetic in their heads. "You're sitting in front of a glorified calculator!"

> Why? Just get the machine to do it. I meant the writing stage, not the checking stage. Imagine you don't know which type to pass. So, you'd have to pass something (null or whatever) in order to generate an error which gives you a clue. That doesn't sound very convenient. Well, the machine could check which types match that fingerprint, which might work okayish if the list isn't too long, but it won't tell you anyth…

I'd encourage you to try writing some Haskell. It's a good example of type inference that works.

Re: Sylph: the programming language I want

#109
post #88

Earlier quoted context omitted.

> Why? Just get the machine to do it. I meant the writing stage, not the checking stage. Imagine you don't know which type to pass. So, you'd have to pass something (null or whatever) in order to generate an error which gives you a clue. That doesn't sound very convenient. Well, the machine could check which types match that fingerprint, which might work okayish if the list isn't too long, but it won't tell you anyth…

I'd encourage you to try writing some Haskell. It's a good example of type inference that works.

You didn't answer my questions. I have no doubt that untooled unitypedness can be improved upon.

Re: Sylph: the programming language I want

#110
post #107

Earlier quoted context omitted.

Editors know that a python line ending in a colon must be indented and so indent it automatically. It wouldn't be hard to use the same method to reindent it.

No, lines following a line ending in a colon must be indented. But the OP's point is that you can't know how many lines make up the indented block, since there is no explicit block-end-marker left if the indent is gone.

>No, lines following a line ending in a colon must be indented.

Except if you have, for example, an if statement. if x: y() is valid.

Post reply on HN