131–140 of 212 posts
Earlier quoted context omitted.
Thanks for the kind words! Zortech was indeed a great compiler for its time.
Years ago IIRC you put out a request for original Zortech C++ disks and packaging, if anyone had some. I was sorry that I had just disposed of mine six months earlier. .. That was my one-and-only C++ in the early 90's, and I am still programming in D. Sorry I couldn't help!
Author here. AMA!
Hi Walter, I've been thinking for a few years that it might be fun to fork the C toolchain and create a modernized version of C which is 80% backwards compatible with standard C but fixes the most egregious issues of C. Do you think this is a worthwhile project?
Earlier quoted context omitted.
Ruby has a nice convention where impure functions like those have a "!" appended to the name. For example String#gsub takes immutable string arguments and returns a new string, but String#gsub! operates on a String instance and mutates it. I guess if you write a new programming language, it would be nice to establish that convention early on, when it's still possible to be done.
The problem with Ruby’s approach, if I recall correctly (been 10 years) is that it’s inconsistent.
https://chromium.googlesource.com/v8/v8.git/+/ba5bac8cebe91c...
I wanted something similar in LuaJIT but it's pretty non-trivial to accomplish. I guess it's one of those mildly useful innovations you can only have with a lot of developer time.
Earlier quoted context omitted.
Other languages (such as python) have install-time code execution. When you pip install a library, the library can run arbitrary code and of course has access to anything and everything via the python interpreter. The only thing protecting you is faith in pypi. How is compile-time code execution any different?
> How is compile-time code execution any different? I don't know the Python ecosystem and so can only speculate. PIP install is not compiling the code, it's an installation program. Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source. But I'm not going to restrict D to compile only source code from a trusted source.
Nope, unfortunately not, anyone can publish anything to pypi as long as the name isn’t taken. Plenty of room for abuse with typo-squatting, etc.
Earlier quoted context omitted.
> Mixtures of the two tend to have syntax problems. My gripe isn’t the syntax, it’s the lack of guarantees/constraints. When I’m working in a language with immutable data structures, I know what to expect. A language like Python with some added functional sugar is much harder for me because I make stupid assumptions. Spent a half hour once chasing down a bug just because I was carelessly assuming list.pop() didn’t al…
You make a good point in general, but I'd be upset if a function called 'pop' didn't mutate anything. That is not the right name to use for returning an element without side effects.
Earlier quoted context omitted.
Sure. You can see it in action at http://darklang.com/launch/demo-video (also, we've gone through our waiting list, so we're pretty much adding new folks who sign up immediately, if you want to try it out). The main idea is that you when you make a change (let's say, you type a key in the editor), that change happens directly on the AST (the internal set of objects that represent the program). So for example, if you'…
You have a grammar... you're just enforcing the rules when data is entered. The same as if my editor stopped accepting input if I miss typed a line until it was fixed.. or if I was required to select one of it's autocomplete suggestions. let x = 5 "hi " ++ name DB::set{} Are you saying these lines from the video are not consistent throughout? Like in one part I'll type "x = 5" to assign 5 to x, but somewhere else I'l…
To get to the root of the issue though, there is not a parser.
Well, one could consider the function that takes each keystroke to be a parser - though I don't know if that's technically correct either. So perhaps the more accurate thing to say is there is not a step that takes a textual source file and parses it.
Earlier quoted context omitted.
The problem with Ruby’s approach, if I recall correctly (been 10 years) is that it’s inconsistent.
Actually I was thinking about how to determine function purity in a static analysis manner for a good while, spurred on by how the Chrome developer console sometimes gives "lazy previews" of typed Javascript statements, but only ones that have no side effects. As it turns out V8 has a feature which can guess if an expression is pure or impure, erring on the side of impure due to undecidability and other random issues…
Way too many years ago, I did that.[1], starting at line 204.
Knowing that a function is pure has many uses. You can optimize, using that x=y => f(x)=f(y). Pure functions can safely be used in assertions and conditional debug code.
[1] https://github.com/John-Nagle/pasv/blob/master/src/CPC2/p2tr...
+1 on writing parser by hand. I've done it once with java (https://github.com/tanin47/javaparser.rs), and I switched my own programming language from a parser generator to a hand-written one. Once you know how to write a parser by hand, it's a much better approach (e.g. easier to test, modularizable).
My programming language is a bit strange in a way that I drop the performance requirement. Performance distorts other aspects. I focus on making the language featureful and beautiful instead. I hope I'll achieve this dream of making a usable programming language one day.
Earlier quoted context omitted.
The two top answers are in conflict. The second answer with 43 points is closer to right: There are hardly any real-world programming languages that are context-free in any meaning of the word. The first answer with 41 points is totally wrong: The set of programs that are syntactically correct is context-free for almost all languages ----- A better source is this whole series by Trevor Jim, which has nice ways of rel…
Thank you very much for the references. They are very good reads! In the article about Python, the author said: > Most languages of interest are context sensitive, and yet we are trying to use inappropriate tools (context-free grammars and context-free parser generators) to specify and parse them. This leads to bad specifications and bad implementations. Then what do you think is a better tool to specify and parse la…
That's unfortunately an open problem. As I mentioned here, lexing is "solved" but parsing isn't:
https://github.com/oilshell/oil/wiki/Why-Lexing-and-Parsing-...
Here are what some recent languages do:
Go: Maintain a written spec [1], with multiple hand-written parsers. (I think the main one is in Go, while gccgo has one in C++?) I believe Go used to be parsed with yacc, but they moved to a hand-written parser for error messages. It looks like [2] was an early attempt to keep it generated.
[1] https://golang.org/ref/spec
[2] https://research.swtch.com/yyerror
-----
Rust: The parser is hand-written, like Go. There's a grammar in the spec, but like Go's, it's not used to generate code, so it isn't tested. They also have an LALR(1) grammar which was suppoed to be an executable specification, but as far as I can tell that effort has not made progress recently.
It used to be done with GNU yacc but it looks like they moved to a Rust-based tool [3]
[1] https://doc.rust-lang.org/grammar.html
[2] https://github.com/rust-lang/lang-team/tree/master/working-g...
[3] https://github.com/rust-lang/wg-grammar/tree/master/grammar
-----
So basically the state of the art is fairly laborious. It's basically write down the grammar, implement it by hand, and try not to make any mistakes. If you need to implement it again, which is extremely common (e.g. for gccgo, for Rust's language server), also try not to make any mistakes.
When you need to change the language, update the spec, and change all the parsers by hand.
I've written multiple recursive-descent parsers based on grammars, and it's not hard if you have examples to test with, but mistakes can easily creep in.
Rely on users to report bugs. There is a "long tail" of programs that will tickle various corner cases.
-----
Here's the approach I took with Oil:
How to Parse Shell Like a Programming Language http://www.oilshell.org/blog/2019/02/07.html
which is basically to do as much work as possible in the lexer, use a high-level programming language translated to C++ for the parser, and to use a DSL for specifying the AST. This approach keeps the mistakes and tedium down because shell is an extremely large language syntactically. (It could be the biggest of any language except for perhaps Perl. Shell is relatively small semantically, but huge syntactically (which is why I'm preoccupied with parsing :) ).
Earlier quoted context omitted.
The two top answers are in conflict. The second answer with 43 points is closer to right: There are hardly any real-world programming languages that are context-free in any meaning of the word. The first answer with 41 points is totally wrong: The set of programs that are syntactically correct is context-free for almost all languages ----- A better source is this whole series by Trevor Jim, which has nice ways of rel…
what is context free language anyway? context free grammar had a clear definition in parsing, not sure i understand how that can be extended to languages.
Context free grammars. What this really means is the code should be parseable without having to look things up in a symbol table
That's NOT what context free means. That's a narrow view from someone designing a C-like language and trying to avoid a very specific property of C.
Another example of being context-sensitive, which has nothing to do with symbol tables, is that resolving LALR(1) conflicts in a yacc-style grammar can make the language not context-free. To resolve ambiguity the parser is doing stuff "outside" the grammar.
----
"Context free" is a mathematical term with a precise definition. It's a class of languages that's part of the Chomsky hierarchy [2], which was discovered and described by linguists and mathematicians before any programming language existed, and has applications outside programming languages. Wikipedia does a good job:
https://en.wikipedia.org/wiki/Context-free_grammar
A formal grammar is considered "context free" when its production rules can be applied regardless of the context of a nonterminal. No matter which symbols surround it, the single nonterminal on the left hand side can always be replaced by the right hand side. This is what distinguishes it from a context-sensitive grammar.
Simple examples of languages that's are context-sensitive (not context-free): Lua string literals, Rust raw strings (see other comments in this thread), and shell here docs:
http://lua-users.org/wiki/StringsTutorial
Yes:
[[ mystring ]]
[=[ mystring ]=]
[==[ mystring ]==]
[=[ mystring ]] # mismatched
The C language is also not context-free.
[1] http://www.oilshell.org/blog/2017/12/15.html#appendix-lexing...