Some people uses HashSet instead of Set and I don't know the why, is it faster? The description in Dart is unclear for me and I have not found examples about their differences or reasons when to use one or the other.
Related
When writing proofs I noticed that Agda's auto proof search frequently wouldn't find solutions that seem obvious to me. Unfortunately coming up with a small example, that illustrates the problem seems to be hard, so I try to describe the most common patterns instead.
I forgot to add -m to the hole to make Agda look at the module scope. Can I make that flag the default? What downsides would that have?
Often the current hole can be filled by a parameter of the function I am about to implement. Even when adding -m, Agda will not consider function parameters or symbols introduced in let or where clauses though. Is there something wrong with simply trying all of them?
When viewing a goal, symbols introduced in let or where clauses are not even displayed. Why?
What other habits can make using auto more effective?
Agda's auto proof search is hardwired into the compiler. That makes it fast,
but limits the amount of customization you can do. One alternative approach
would be to implement a similar proof search procedure using Agda's
reflection mechanism. With the recent beefed up version of reflection using
the TC monad,
you no longer need to implement your own unification procedure.
Carlos
Tome's been working on reimplementing these ideas (check out his code
https://github.com/carlostome/AutoInAgda ). He's been working on several
versions that try to use information from the context, print debugging info,
etc. Hope this helps!
Data and functions in Rascal can scatter in different source files, and when imported are merged accordingly. In other words, Rascal supports open data and open functions. So Rascal solves the expression problem? Is it designed so as to do?
I think to write that Rascal "solves" the expression problem, is a bit strong, but you could say that you can easily write openly extensible implementations of expression grammars in it. It was designed exactly for this, see http://www.rascal-mpl.org/from-functions-to-term-rewriting-and-back/
On the one hand, one can write programs which do not suffer from the expression problem in Rascal, precisely for the reason you said: both data and functions are openly extensible, and they work together via dynamically dispatching via pattern matching.
On the other hand, It is pretty easy to write non-extensible implementations as well in Rascal. In particular when using the current visit or switch statements, which are not openly extensible. Also if you write a set of mutually recursive functions, it may be pretty hard to extend them in an unforeseen manner. We are also working on language features to cover extending those kinds of designs. That is for the future.
As we know Microsoft introduced the dynamic type a long time ago. And I also applied it in some case in the ASP.NET MVC application. But to me, it is not good for all cases. In specific, it's seen to be violating some basic principals like The Acyclic Dependencies Principle. For example, I have a package A that using package B, then in B I use dynamic and reference to A. It work fine. So the question is how do I use the dynamic type in correct way?
Speaking from experience: don't do it. Seriously, sooner or later you will regret.
Each time I decide to use dynamics I found it was a mistake. Using dynamics makes refactoring a nightmare, and you lose the biggest advantage which is type safety. Errors will show up in runtime instead of during compilation.
It's usually ten times better to refine your design and use oop principles or try to find some common interfaces.
It should be used only to simplify working with dynamic languages such as java script. Otherwise it is bad for your program performance and your mind sanity :)
So the best practice with dynamics is: try avoiding using them
Dynamic is not a type, it's syntactic sugar. The type will be object, but the compiler will put in a lot of code to detect the actual type of the variable at runtime.
It's meant to be used when you don't know the actual type, for example is used by the dynamic languages running on top of .Net.
It can be abused, as a lazy shortcut (but for that use var ) but you'll get a performance penalty in that case. Long story short, it should be used when you can't solve a problem easily with strong typing.
I think the dynamic keyword is good, but we have to using it very careful, like Mike mention as above. I used it on some small examples. When we use it, and we know it, so when somebody call to it, he/she have to know what kind of object that use in dynamic. Hope this help.
I'm looking for an alternative to JMegahal that is just as simple, and easy to use, but yields better results. I know JMegahal uses Markov chains to generate new strings, and I know that they're not necessarily the best. I was pointed towards Bayesian Network as the best conceptual solution to this problem, but I cannot find any libraries for Java that are easy to use at all. I saw WEKA, but it seemed bloated, and hard to follow. I also saw JavaBayes, but it was almost completely undocumented (their javadocs contained little to no information, and the variables were poorly named) and the library was blatantly written in C-style, making it stand out in Java.
You might want to consider extending JMegahal to filter the input sentences. Back in the mid-90s, Jason Hutchens had written a C version of this 4th-order Markov strings algorithm (it was probably used as inspiration for the JMegahal implementation actually). At that time, Jason has added filters to improve on the implementations (by replacing 'you' by 'I', etc...). By doing some basic string manipulation meant to change the subject from the speaker to the system, the output became a lot more coherent. I think the expanded program was called HeX.
Reference 1
Reference 2
I want to build a parser for a C like language. The interesting aspect about it is that I want to build it in such a way that someone who has access to the source can easily modified it to extend the language (a new expression type of instance) with the extensions being runtime configurable (they can be turned on and off).
My current intent is to build a recursive decent parser as an object. Each production will be a method of an object. The method of extension will be to derive classes from this base replacing methods (and production definitions) as needed. I'm still trying to figure out how to mix and match extensions. One idea is to play games with the v-tbl. Objects would be constructed with a v-tbl that is a copy of the base but with methods replaced from derived classes.
Aside from the bit-twiddling nature of the solution the only issues I have with it is
a reasonable way to do the v-tbl mixup
what to do when 2 extensions alter the same productions (as most replacements will end up calling the original having one replacement call the other would work but the mechanics of setting this up are the issue)
how to allow the extension of extensions (this might end up looking like a standard MI system, but I've never got how they work)
Another solution (a slightly more mundane version of the same same approach) would be to use static member variables to store function-pointers and call them for the same effect.
Edit: I have already built a system that lets me build productions from BNF definitions. I can alter it to support whatever I decide on.
These are some of the challenges the Perl 6 design effort has faced. You may find it worthwhile looking into some of the solutions they came up with. Or you may find that to be gross overkill.
I made a configurable parser I uploadei it some time ago at
http://code.google.com/p/compparser/
The project there is not up-to-date but is working fine.
If I recall my university courses correctly, recursive descent parsers have some limitations that might bite you, especially since you're allowing extensions - somebody elses language extension could cause issues.
A proper compiler toolkit - such as the open source ANTLR - might make things easier, and might also provide some different approaches for you.
another option is to express the parsing rules in XML or something, instead of in code; less efficient, but far more dynamically configurable; each language or variant can just use its own (XML) file, and even include/reference other files as 'base' files...
Frankly, I am not even sure I understood everything you wrote... :-)
But when I see parser and flexibility, I think about LPeg - Parsing Expression Grammars For Lua. It might not fit your needs but it is well worth a look... ;-)