Thanks for the pointers. I have looked at Haskell and have some work-related reasons to learn it. I would suggest that you have made a "type error" :) by suggesting "...giving you compile time errors if you pass say an int into something that expects an array. " since arrays and ints are orthogonal to each other.
On Thu, Apr 2, 2015 at 10:34 PM, Aistis Raulinaitis <sheganin...@gmail.com> wrote: > I'm rather agnostic either way! I like J so much because of it's dynamism. > The J does dynamism right, bar none (imo). I only need to say one word, > rank. I haven't found anything that compares to it in any other language. > Not even Factor comes close, and I really really like it's stack > combinators and fried quotations. What I really like about J is that a lot > of the work I do fits right into it, quick, iterative, data exploration, > make a graph and forget about the code forever. No other language lets me > do that entire cycle as quickly as J, the solution can usually fit in a > tweet. What I've been thinking about is that there must be some really nice > underlying way to give J an optional type system, or at make some sort of > toy language that fits the bill. That and there is no implementation for > obverse in Haskell, aka: ^_1 :: (a -> b) -> (b -> a). Although maybe if you > add some constraints on a and b and reified J's AST, maybe it would go > somewhere. My first thought is to do something like: ^_1 :: (JVal a, JVal > b) => JFunc a b -> JFunc b a. > > I know Mr. Iverson really didn't like types, and I completely understand > that. It can absolutely slow down the development of the language, but > giving up sum types in J is a bit sad to me. I think that just that would > be interesting, since nil is horrible and Maybe is bliss, and I think J > would benefit from having the capability. Then my personal bias shows in > the fact that I'm sold on dependent types, which I actually think are > *necessary* for typing some of J's trickier semantics. Such as functions > that dispatch on the type of the argument. My first thought was to use type > level sums, but then I realized that not much work has been done in that > area. Compound that with the fact that I realized that some functions would > require *open* sums, *at the type level*! So that would give up all the > nice things that closed sums give you. So now my best guess is to track the > types with a type level set, and then to dispatch to the proper function > with that information. So the type would contain the possible types of the > arguments that could be passed in, essentially still maintaining 100% of > the polymorphism (if everything goes right), while also giving you compile > time errors if you pass say an int into something that expects an array. > You could go one step further (and I would), and track the dimensions of > the array at the type level. So the type of (2D) transpose would be: > 2dtrans :: [a][b] -> [b][a], where a and b are the length of each > dimension. Generalized NDimensional transpose would be a little trickier, I > think it can be done with enough tinkering. You could then go on and say > that you expect specific sizes: someFunc :: [3][4] -> [5][4] -> [8][4], or > leave some parts polymorphic: otherFunc :: [a][5] -> [6][b] -> > [(a+b)*3][7]. Yes, that is type level computation, welcome to dependent > types! ;) It's like ASSERT but even better! > > This would essentially give you compile time errors for a whole suite of > things that usually go wrong at runtime. It would also probably give better > error messages, at least more verbose ones. > > Very interesting article! > > Devon, I hope some of the above answers a part of your question. If you > already have some experience with Haskell, I would implore you to try a > dive into Agda. http://oxij.org/note/BrutalDepTypes/ <--- My favorite > tutorial on Agda. Install Emacs if you don't already use it and use Agda's > auto proof search feature, it's a completely different way of programming > and it's definitely the future in it's own way. If you want a good example > of Agda's power, I'll shamelessly promote some of my own code, wherein I > use Agda to prove some trivial things in physics: > > https://github.com/sheganinans/Static-Dimensions/blob/master/StaticDimensions.agda#L638 > > On Thu, Apr 2, 2015 at 6:12 PM, Joey K Tuttle <j...@qued.com> wrote: > > > Lots of topics to chat about ;-) > > > > Sorry to say, I don't admire your idealized child - but these things are > > indeed personal. > > > > In general, choice of language is intensely personal -- e.g. in this > > story about a fellow "suing himself" over language license issues... > > > > http://www.forbes.com/sites/ryanmac/2014/06/05/on-the- > > verge-of-ipo-arista-networks-faces-lawusit-from-a-billionaire-cofounder/ > > > > I don't know how that ended - but I thought that it was interesting view > > of passion for a language. > > > > > > > > On 2015/04/02 17:01 , Aistis Raulinaitis wrote: > > > >> Definitely. Thanks. I felt a little sad for the author's distaste for > >> static typing. As a Haskeller I actually see static typing as tool to > lean > >> into when things get tough, instead of a thing you have to work against. > >> To > >> me programs are just data and mappings of that data from input to > output. > >> I > >> may just be one of those weirdos, but for me (at least right now) the > >> perfect language for me would be if J and Idris/Agda had a baby and > made a > >> dependently typed array language. ...and regained back APL's symbolic > >> syntax and left ASCII in the dust. > >> On Apr 2, 2015 4:33 PM, "Joey K Tuttle" <j...@qued.com> wrote: > >> > >> With this interesting article - > >>> > >>> http://www.technologyreview.com/review/536356/toolkits-for-the-mind/ > >>> > >>> > >>> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
