sklogic

78 ms·

871.
by sklogic 11y ago
> The strength of a type system is that there is one. I do not agree. There is no single type system that would fit all the possible use cases. > Probably explains why most Lisps consist of one-man-hobbyist projects, though. No, it do
872.
by sklogic 11y ago
It got some rudimentary macro support only recently, and still they're not the proper macros, more like a TH limited approach. The worst part which makes macros much less useful is that you cannot have a macro definition and use it in
873.
by sklogic 11y ago
Then the entire community got it all wrong. DSLs are much, much more composable than functions. You can easily compose just parts of DSLs, building new DSLs on top by combining semantic properties from the existing DSLs. It's just a
874.
by sklogic 11y ago
This is not any different from a macro. You still translate your DSL into your host language AST, with the only final step different - runtime eval instead of a compile-time macro. All my macros look like (defmacro something (dsl) (compile-
875.
by sklogic 11y ago
For a language with macros it does not matter at all. You can add any type system you like on top of it. Metalanguages are infinitely flexible.
876.
by sklogic 11y ago
> How do you provide typing across modules? With type hints? By only exporting simple functions (which only take DSL commands and return DSL commands) out of the modules - it works well with Racket and some other Scheme implementations,
877.
by sklogic 11y ago
> Most of the macros in libraries were saving a pair of parentheses This is an epic misuse of macros. > and/or I never saw a good eDSL that would have been worse without macros eDSLs should almost never be implemented without mac
878.
by sklogic 11y ago
> In general, I'd advise against them Why? Macros are the single most important productivity feature in Lisps. Macros allow to implement eDSLs trivially, in the most robust way possible. Yes, you need to follow a certain discipline
879.
by sklogic 11y ago
Scala got no macros. Which makes it infinitely less powerful than any language with macros, including even something like Clojure.
880.
by sklogic 11y ago
My preferred approach with the dynamically typed languages is to have statically typed big picture (i.e., static module dependencies) with dynamic typing confined to module scope. Another important thing is to not expose APIs. APIs suck.
881.
by sklogic 11y ago
Speaking about my experience only: I do not refactor that often. See no point in it, Lisp is not Java after all. My code is usually well localised, with only languages being passed in between modules (instead of APIs). And modules are sma
882.
by sklogic 11y ago
Someone filming you in a public place won't immediately commit the recording into a centralised storage accessible to dozens of (potentially corrupt) government agencies, alongside with the face recognition data.
883.
by sklogic 11y ago
> Well, we've solved that. If you really did, you've got much, much more than merely optimising a memory access. Consequences for the static analysis can be enormous. Looking forward to seeing your publication.
884.
by sklogic 11y ago
There are no caches nor DRAMs on most of the microcontrollers anyway, just plain, stupid, small SRAM blocks. > having it managed at compile time Uhm, been there, managing scratch memory statically can only work for very high level (and
885.
by sklogic 11y ago
Would you really prefer to be asked to write a cache-friendly hash map on a whiteboard?
886.
by sklogic 11y ago
> but remaining compatible really is almost always the right thing to do. Luckily, not that much any more. In GPUs, for example, nobody cares, since nobody is carrying binaries around.
887.
by sklogic 11y ago
I'd consider it a kind of revenge. Previously we had to deal with an unwelcome invasion of SQL into the areas it's not suitable for, now the SQL guys have to fence off an invasion of document-, graph-, hierarchical- and whatever e
888.
by sklogic 11y ago
There are some areas where relational DBs simply have no place at all, and never had. For example, CADs always relied on the hierarchical database engines, and it should always stay this way. This new hipster relational model is not nearly
889.
by sklogic 11y ago
This should be easy with the AST-based editors (such as JetBrains MPS).
890.
by sklogic 11y ago
Only if it's a 3-stage pipeline without a hazard detection. Otherwise the area would at least double. But, yes, I'd also like to see a pipelined core in this new HDL.
891.
by sklogic 11y ago
There is a trade-off between performance and area. Pipelined designs are bigger (not least because of all that pipeline registers).
892.
by sklogic 11y ago
Ok, I think I understand now how it works (played with Idris parser a bit). Sort of a simple trick, I'll borrow it for the lower tier combinator-based parsing layer. I was even more interested in handcrafted, custom error messages rath
893.
by sklogic 11y ago
JIT is a totally different beast from a simple pipeline compiler. You should have known better. Anyway, you evidently do not know what you're talking about. Consider you trolling unless you can show your compiler code.
894.
by sklogic 11y ago
There is a bit outdated tutorial in https://github.com/combinatorylogic/mbase/tree/master/misc/d... Also, CLike project was supposed to be a sort of a tutorial. For a more thoroughly documented, pro
895.
by sklogic 11y ago
Thanks! I'll take a look at these projects. By recovery I mean something like "f(x,y,z;" triggering an error message "did you miss ')' here?", with parser recovering and proceeding further, in a hope to re
896.
by sklogic 11y ago
Could you please point at their error recovery functionality (I could not find it by a quick scan)? My gut feeling is that combinator-based parsing is not very well suited for this, but I may be missing something obvious.
897.
by sklogic 11y ago
I am glad you did not list anyone related to GCC and LLVM, because both rely on the static DSLs (and code generation) heavily. As for the rest - yes, compiler construction is not their main research topic. They can all be great language des
898.
by sklogic 11y ago
The features I am talking about are very platform-agnostic. The only requirement for implementing them is a compile-time metaprogramming, which is trivial to add to any language, including C. The only explanation for not using this approach
899.
by sklogic 11y ago
> are even more niche Exactly. Compilers construction is a very specific problem domain, which requires specially tailored DSLs, not a "general purpose" language. Haskell is a way too general purpose for this task. > and n
900.
by sklogic 11y ago
> recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything. In the dynamically typed languages static types are substituted with tons of trivial (stupidly trivial) tests, which is a way m

More ›