3 ms·

Hmm, interesting. I just had a slow look through http://kittenlang.org/intro/ http://kittenlang.org/intro/. In all honesty my stupid ADHD decided to conk out p

Hmm, interesting. I just had a slow look through http://kittenlang.org/intro/ http://kittenlang.org/intro/. In all honesty my stupid ADHD decided to conk out precisely at the Lambdas section, I'm not sure why. Up to that point, the only thing that I'd note is that "match (xs head)" is not described anywhere (on the page at all). But I think it's interesting you posit Kitten as a systems language. Huh. (What's a "traditional" tokenizer?! Ah; I assume you mean "not pure Forth" as opposed to "buy APL keycaps here" (heh).) I guess the only advice I can think of right now is, offer batteries included, and include the batteries you're most passionate about, because it'll mean the implementations are complete and well-tested. If that's web templating (random top-of-my-head thought), do that; if it's image processing, do that. It'll raise the chances the language becomes $thing-heavy because nobody contributes other code, but you can always stop advertising and spend time rounding things out if that happens. I meant to install Kitten, but that didn't quite work this time around due to problems on my end. (First git was silently segfaulting due to inconsistently-upgraded shared libraries on my Slackware box, then I realized I needed Haskell and switched to Arch, then I was reminded that pacman doesn't really know how to resolve dependencies properly ("if you install something that needs the newest version of glibc, maybe I shouldn't need to have to upgrade glibc (and reverse-resolve its dependencies) myself?!"), then after half-installing Haskell I discovered (/) only had 19MB free, so now I have to go figure out what caused that... (I argue it's my 80KB/s ADSL2+ upload speed :P)) I'll definitely be looking at Kitten at some point though. Thanks for the reply! EDIT: Got past the previous issues, now Haskell is sad. https://github.com/evincarofautumn/kitten/issues/206 https://github.com/evincarofautumn/kitten/issues/206

evincarofautumn 8y ago
> "match (xs head)" is not described anywhere (on the page at all). “A ‘match’ expression takes an instance of an ADT, matches on its tag, and unpacks its fields (if any) onto the stack so they can be manipulated.” (Under the “Algebraic Data Types” section.) By a “traditional” tokenizer I mean “a tokenizer more like what you’d expect from a mainstream C-like programming language, not just splitting on whitespace like Forth does”. It has some superficial similarities to Forth (postfix by default), but overall has more in common with the ML and C families (Haskell, OCaml, Rust, C, C++). The reason I decided to start labeling it a “systems” language recently is to get the attention of the people from C++ and Rust who I’d like to try it out eventually. The implementation isn’t nearly close to this, but the language itself is designed to be easy to implement efficiently (strict evaluation, guaranteed tail call elimination, unboxed data types, no GC or nontrivial runtime required) and has a lot of static structure available for the compiler to do optimisations (static type and effect system). Kitten’s docs are perpetually in an awkward state because I’m the only one working on it regularly—they’re usually slightly behind the compiler version I’m actually working on, and occasionally describe language features that aren’t yet implementation features (i.e., they should work but are known to be buggy/incomplete in the current version). I’m focusing on the next major round of changes to the compiler, which I hope is the last before a release, and I plan to go through all the docs and flesh them out as part of the eventual release process.
- exikyut 8y ago
  (Sorry for late reply, woops) Hm, thanks for the manual reference (heh, should have gone and looked). Now to go figure out what "xs head" means... I think the tokenizer choices are pragmatic and interesting. They make the language less simply annoying and irritating, and thus more accessible to learn. The idea of a systems language with Kitten's focuses sounds good - oddball alternatives always serve to (slowly) influence the mainstream, let's hope that happens here :D The approach to documentation is reasonable too, if unintuitive at first glance; providing a language that implements the 95th percentile of what is advertised is actually not that bad of an approach.
  - evincarofautumn 8y ago
    “head” has the type: <T> (List<T> -> Optional<T>) (“For any type T, function from list of T to optional T.”) So assuming “xs” is a list, “xs head” is either a full Optional (“some”) containing the first element of the list, or an empty Optional (“none”) if the list was empty—typed, of course, according to the element type of the input list, so if “xs” has type “List<Int32>” then “xs head” has type “Optional<Int32>”.

evincarofautumn 8y ago

> "match (xs head)" is not described anywhere (on the page at all). “A ‘match’ expression takes an instance of an ADT, matches on its tag, and unpacks its fields (if any) onto the stack so they can be manipulated.” (Under the “Algebraic Data Types” section.) By a “traditional” tokenizer I mean “a tokenizer more like what you’d expect from a mainstream C-like programming language, not just splitting on whitespace like Forth does”. It has some superficial similarities to Forth (postfix by default), but overall has more in common with the ML and C families (Haskell, OCaml, Rust, C, C++). The reason I decided to start labeling it a “systems” language recently is to get the attention of the people from C++ and Rust who I’d like to try it out eventually. The implementation isn’t nearly close to this, but the language itself is designed to be easy to implement efficiently (strict evaluation, guaranteed tail call elimination, unboxed data types, no GC or nontrivial runtime required) and has a lot of static structure available for the compiler to do optimisations (static type and effect system). Kitten’s docs are perpetually in an awkward state because I’m the only one working on it regularly—they’re usually slightly behind the compiler version I’m actually working on, and occasionally describe language features that aren’t yet implementation features (i.e., they should work but are known to be buggy/incomplete in the current version). I’m focusing on the next major round of changes to the compiler, which I hope is the last before a release, and I plan to go through all the docs and flesh them out as part of the eventual release process.

exikyut 8y ago
(Sorry for late reply, woops) Hm, thanks for the manual reference (heh, should have gone and looked). Now to go figure out what "xs head" means... I think the tokenizer choices are pragmatic and interesting. They make the language less simply annoying and irritating, and thus more accessible to learn. The idea of a systems language with Kitten's focuses sounds good - oddball alternatives always serve to (slowly) influence the mainstream, let's hope that happens here :D The approach to documentation is reasonable too, if unintuitive at first glance; providing a language that implements the 95th percentile of what is advertised is actually not that bad of an approach.
- evincarofautumn 8y ago
  “head” has the type: <T> (List<T> -> Optional<T>) (“For any type T, function from list of T to optional T.”) So assuming “xs” is a list, “xs head” is either a full Optional (“some”) containing the first element of the list, or an empty Optional (“none”) if the list was empty—typed, of course, according to the element type of the input list, so if “xs” has type “List<Int32>” then “xs head” has type “Optional<Int32>”.