Jump to content
  • Advertisement

Rebooted

Member
  • Content count

    815
  • Joined

  • Last visited

Community Reputation

612 Good

About Rebooted

  • Rank
    Advanced Member
  1. Rebooted

    Higher Kinded Types, Sorts and Birds

    Kinds serve the same purpose as types, but at the level of types rather than at the level of terms. Without kinds or equivalently with only one kind (the kind of proper types, usually called *) you would have trouble writting, say, a generic monad interface. The type of return in Haskell is (Monad m) => a -> m a, where m has kind * -> *. You need to be able to parametrise over not just proper types, but type constructors like Maybe, List, IO, etc.
  2. Rebooted

    Conversations

    Interesting. I don't fully understand how your code works yet, I'll have to read it more closely. Another way to do DSL's that's more commonly used in Haskell and ML is to write them as combinator libraries, using types and higher-order functions as your tools rather than macros. For example, this is WASH (a Haskell web framework) code: html $ do head (do title (text "Title") link $ rel "stylesheet" >> type' "text/css" >> href "style.css") body (do h1 (text "Heading") p (text "Text")) It works by constructing and composing values of a HTML algebraic data type, which has an interface that matches the XHTML DTD. Because of this interface, all constructed documents are statically guaranteed to be well-formed and valid (standards-compliant). Quote:Original post by Daerax Nemerle has macros which allow one to do metaprogramming. Not C style but scheme like hygenic macros. The metaprogramming is in two or three parts. The first is of a style that people who have done C++ template metaprogramming would recognize. Namely various compile time execution of certain code that allow various optimizations and new behaviours. The other type is akin to MetaML or Template Haskell and Scheme. Which is the ability to operate on the language's syntax tree using the language itself and to do various bits and bobs e.g. modify/auto generate code. It also has flexible syntax extension. Actually, MetaML is quite different from macro systems like Scheme's or Template Haskell. Multi-staging systems like MetaML and MetaOCaml are focused around the first style of programming that you mention, except unlike templates and macros they aren't just limited to compile-time construction and execution of code; they can also do this at any arbitrary stage including at runtime. Macros systems are syntactic, like you say, and operate in terms of syntax rather than values. This is ideal when you want to extend the syntax of the language, but less than ideal when you want to optimise and specialise code, or read a configuration file at compile time or something. Multistaging systems are semantic - they work by adding a new type which represents code and supports three operations: building a code fragment, combining two code fragments and executing a code fragment to obtain the result. I think ideally you'd have multistaging support for shifting evaluation of code to another phase and completely separate and safe syntax extension support for adding things like do notation, list notation, etc.
  3. A few practical languages work like this. GHC, for example, compiles Haskell to a variant of C-- and then either directly to an executable, or to C if you set the -fvia-C option. The FFI makes it easy to mix in code written in C, too. People have already had Haskell running on the PS3 this way. There are now GHC binaries avaliable for Yellow Dog Linux on PS3. Another compiler that comes to mind is Gambit-C Scheme.
  4. Rebooted

    Functional Programming on .NET - Part 2

    I wonder what an implementation in Charity would look like.
  5. Rebooted

    Strict or Lazy

    I'm pretty fond of monads in general - Either and Maybe for example provide a very neat way of dealing with errors, and the "DSLs" built with monads for stuff like logic programming and parsing are also very nice. You don't need language support for that though; and Haskell has none, except for the do notation. Clean has type classes so you could easily write a Monad class and write definitions for Either, Maybe, etc. You could do it in OCaml too, using functors rather than type classes. I don't have any love for the special built-in IO monad though, it does feel sort of bolted on. Maybe substructural typing or comonads would be better for effects. BTW, what are monads used for in category theory?
  6. Rebooted

    Strict or Lazy

    Quote:I suspected it would be you who replied. Once again, you enlighten me on my journey to self-learn computer science. I am thankful for your help. Thanks [smile] Quote:Charity. Is that language still being actively developed? There seems to be no community for it, scant documentation and some of the people who are working on it dont seem to have updated their webpage. In 10 years. or more.No, I don't think anyone is still developing it. It had some good ideas that I think will end up in future languages though. Quote:The wiki said something about fold being an initial algebra, so what there is an arrow from fold to every algebraic type?Every algebraic type has a fold/catamorphism which acts as the destructor for breaking down values you have built up from the constructors. For lists, this is foldr. Charity generates the fold for an algebraic type automatically, and pattern matching is just a special case of fold - it is syntactic sugar (if you add general recursion as in Haskell then pattern matching becomes the more primitive operation because you can only write structurally recursive functions as folds). Coalgebraic types on the other hand come with unfold construction operations for building up values you will later break down using the destructors. Quote:Why is this bad? I can see the difference between streams and lists, the difference is glaring even if subtle. Not many things can be the same as their opposite. For programming though, when does this distinction become important?That blog post gives some motivation. Basically when you write a function that works on a list, you're usually writing a function that works on one of lists or streams. Lists and streams have different interfaces. Quote:How does Haskell do coinductive data? I can only guess that Haskell does not quite do both but in fact implements something that is at least a homomorphism of the union of Inductive and coinductive data.I just mean for example it bundles up both streams and lists into one list type. I don't mean you can represent every coalgebraic type in Haskell. Quote:In what kind of situations will lazy evaluation compromise the efficiency of tail recursion? Basically, tail recursion is not optimized out because the tail call is not immediately evaluated. Instead, a thunk is built that makes the call when it is forced. Quote:Also, what are your thoughts on Clean? Cheers!I've not used it but it looks nice, basically the same as Haskell except it uses uniqueness types to support effects and keep referential transparency instead of the IO monad. I don't see a reason to switch to it though. Uniqueness types are a form of substructural types (as in substructural logics, like linear logic), which are another important concept that will probably end up in future languages. Some really impressive stuff -- like type systems which can verify code is free of deadlock -- is possible through substructural typing.
  7. Rebooted

    Strict or Lazy

    Your language does not have to have lazy evaluation to support infinite data structures. You just need to support coinductive datatypes as well as inductive datatypes. Charity does this. The type of finite lists is something like this: data List a where Nil :: List a Cons :: a -> List a -> List a And the type of streams is something like this: codata Stream a where Head :: Stream a -> a Tail :: Stream a -> Stream a An inductive/algebraic type is defined by its constructors and is an initial algebra for an endofunctor. A coinductive/coalgebraic type is defined by its destructors and is a final coalgebra for an endofunctor. The problem with Haskell is that it does not distinguish between inductive and coinductive data. Like false and zero, streams and lists are different concepts and should have different types (here is a recent blog post on this). You could put them in a type class to allow writing code that operates on both, though. The cause for efficiency problems is that a thunk (which is either the value, or a function used to get the value if it has not yet been evaluated) must be associated with each value, causing extra memory use and a decrease in speed. It is also harder to reason about the efficiency of code because of the more unpredictable evaluation order. A tail-recursive implementation is usually the most efficient in a strict language, but it is not always so in a lazy language. Big-oh based reasoning is not as helpful either.
  8. Rebooted

    I Believe in Static Checking II: Tests and Bugs

    The type system I linked to earlier also proves that programs are free of deadlock (in all cases - terms which contain deadlocks are ill-typed, and ill-typed terms are not programs). My objection was to "All this talk of static and dynamic typing is just blind dancing around this simple statement of a rather obvious fact," because it makes it sound like the checking abilities of a dynamically typed/untyped language like untyped lambda calculus, Scheme or Python are equal to the checking abilities of a typed language, just delayed. And it isn't that simple.
  9. Rebooted

    I Believe in Static Checking I: Constraints

    Quote:All* constraints can be dynamically checked. Some constraints cannot be statically checked. In particular, temporary constraints can never** be statically checked. All this talk of static and dynamic typing is just blind dancing around this simple statement of a rather obvious fact. It's not that simple. You need a static type system or some other form of syntactic analysis if you want to verify your code is free of deadlock, for example. Dynamic typing can't do that. Most debates are based upon the false assumption that static and dynamic typing are equivalents. A "dynamic type system", whatever that is, is not the dynamic equivalent of what a type-theorist would call a type system. It effectively amounts to not having a static type system - this is why they would call Python untyped. I'm writing something that would explain all this and explain why I think type systems are a good idea, but for now this does a decent job.
  10. Rebooted

    Bugger

    PENDULUM
  11. It seems that way [smile]. However, I think it is the general consensus that the C++ type system is turing complete.
  12. I'm fairly sure template metaprogramming is turing complete. edit: see here
  13. Rebooted

    Graphs

    Thanks, that uncovered tonnes of stuff I hadn't seen before about categorical semantics. Something I read hinted that because the simply typed lambda calculus is the internal language of a cartesian closed category, in turn you can convert a program written in a lambda calculus to an equivalent program in a combinatory language via mapping between different categories supposedly with different corresponding internal languages. This is very close to what I imagined.
  14. Rebooted

    Dehah

    Quote: Rebooted, I have not had continous internet access for a while but have finally replied here :)Ah, thanks! A belated happy birthday from me too [grin] On coursework: I heard about this on the news, but not in too much detail. Are they just scrapping maths coursework? I don't really understand that. It's unlikely English coursework, as an example, would be scrapped. Some other subjects also depend very heavily on coursework. In these subjects, the problem will still remain, and the only solution is yours. So yeah, this is just the wrong approach. It has to be due to the government wanting to be seen to be doing something, or just misunderstanding of the subject.
  15. Rebooted

    Graphs

    Quote:Would it not be better to start from a more general category and then work downwards?Probably [smile]. I think category theory can be applied because of a link to category theory's key ideas, and because of the already existent link of monads in category theory and in Haskell. Within the language we won't be interested in working with categories of course, but with these abstraction layers. Category theory could be applied to help us decide how to best represent and work with them. I said functor because I see Languages taking the place of Categories in our sub-theory.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!