|
583
|
1 2012-02-24.txt:08:11:00: <zzo38> If I make document new programming language similar Haskell but half of things difference and other things too, then maybe it can be called "Ibtlfmm"? (O, it is like, "Iuckqlwviv Kjugobe", but completely difference except first letter? Also the letter they seem to just put together... but both of these thing have their ways of making the letters)
|
|
|
2 2012-02-25.txt:07:12:30: <zzo38> I was thinking about my ideas for Ibtlfmm programming language (I might eventually write a specification document, and/or a compiler, and/or a tag in Phlogjournal for stuff I occasionally write about it). One thing is that unlike Haskell, a class can be many things; it can be: a type signature of a method, a tag, a type family, a mathematical law, or a combination of classes.
|
|
|
3 2012-02-25.txt:19:56:52: <oerjan> <zzo38> I was thinking about my ideas for Ibtlfmm programming language <-- i'm sorry but elliott will never be able to distinguish that from Itflabtijtslwi.
|
|
|
4 2012-02-25.txt:21:21:25: <zzo38> Do you have any comments about my ideas of Ibtlfmm programming language I was thinking about? (near timestamp 1330153950)
|
|
|
5 2012-02-26.txt:04:33:09: <zzo38> In Haskell channel, someone said I made the same problem of including Int in Prelude. I agree and I realized I made a few other mistakes too, in Ibtlfmm example, so I will write the specification fix these problems. There shall be no Int, but there can be Int8, Int16, Int32, Int64, and Integer. Do you think so?
|
|
|
6 2012-02-26.txt:05:22:04: <zzo38> Is this good so far? So far I have only the main headings. http://zzo38computer.cjb.net/Ibtlfmm/ibtlfmm_specification.tex Perhaps I might change the name; if you can suggest better name ("Ibtlfmm" is not necessarily best name to call it)
|
|
|
7 2012-02-29.txt:21:37:06: <zzo38> I have written some idea too, about some programming language codenamed "Ibtlfmm", where the type system includes implementation of mathematical laws of classes
|
|
|
8 2012-03-06.txt:19:55:42: <zzo38> In my own (codenamed) "Ibtlfmm" one idea include, you might have: type TypeOf (_ :: {t :: k}) :: k = t; type MyLayout = TypeOf {myLayoutHook};
|
|
|
9 2012-03-08.txt:07:16:09: <zzo38> There is the way I have tried to design the "Ibtlfmm" package system; it is better than Haskell's system in my opinion, and does not require web 2.0 or anything else like that; no centralized system is required either, and no internet is necessarily required.
|
|
|
10 2012-03-12.txt:05:13:05: <zzo38> Some people have describe my "Ibtlfmm" idea as something like combine Haskell with Lisp; it is something like that. But really my idea something like a few stuff from Haskell, Lisp, LLVM, and a few others.
|
|
|
11 2012-03-16.txt:23:11:41: <zzo38> Do you like my idea of Ibtlfmm allowing the main to be of any type instead of only IO? (but to make a standalone executable it still has to be either (IO ()) or (unsafe "c_int(c_int,c_char**)"), otherwise you can make a dynamically loadable file but not a standalone executable)
|
|
|
12 2012-03-27.txt:22:58:08: <zzo38> In Ibtlfmm (currently a codename), the uninhabited type is called 0, and Word8 is now called Nat8, and Maybe is now called a successor monad; is it better?
|
|
|
13 2012-03-31.txt:00:45:59: <zzo38> Haskell specifies the Char is Unicode from 0hex to 10FFFFhex, but I think, Ibtlfmm shall go up to FFFFFFhex and the implementation is not required to be Unicode, it can use anything, as long as it is ASCII.
|
|
|
14 2012-04-06.txt:01:35:10: <zzo38> In addition, both hide/override class instances, and a kind for modules, are ideas for my new programming language (called Ibtlfmm currently; if you don't like that name, call it HELLwaPAIN or something else). There is the @ kind which is the kind of program modules, etc. This will solve it too, I think. As well as having macros, that also helps.
|
|
|
15 2012-04-09.txt:04:36:49: <zzo38> Because, if you have anything wrong with Haskell then please write it down we can make the "Ibtlfmm working group" to write everything down together how to make up the new programming language too
|
|
|
16 2012-04-11.txt:20:04:52: <zzo38> I like Haskell but prefer Ibtlfmm. But tell me do you think dvi-processing is programmed in a functional style or not?
|
|
|
17 2012-04-12.txt:05:41:21: <zzo38> Please tell me what your idea of this type system I have idea of (for Ibtlfmm, not for Haskell; but similar). I will describe some of its features so that you can complain about it properly.
|
|
|
18 2012-04-13.txt:21:48:53: <zzo38> Perhaps I could write some phlog journal messages about idea of Ibtlfmm, in case you are interested about that. But maybe the syntax *(x) -> {x} -> * is not so good because of the datakinds kind K x = K * (x -> x); it might use ( for grouping too. Maybe this syntax better? (* =x) -> {x} -> * or something else you have idea?
|
|
|
19 2012-04-13.txt:22:17:44: <zzo38> What is your opinion of the Ibtlfmm's extended kind system? Is crazy? Is good? Is bad? Is you don't know?
|
|
|
20 2012-04-16.txt:20:52:41: <zzo38> These are a few of things stupid with Haskell, so we should make Ibtlfmm it does better. If you want to control such optimization things as memoization more precisely, you could use inline LLVM codes, and attribute pragmas attached to function to control many things if needed
|
|
|
21 2012-04-22.txt:01:09:29: <zzo38> I don't like the way those reflection stuff works; I had a better solution in Ibtlfmm where values can be made into types by {} around it and types into kinds by {} around it but it is not implemented as far as I know
|
|
|
22 2012-04-22.txt:19:53:34: <zzo38> Ibtlfmm could be made to compile into Haskell but it wouldn't work well because of some optimizations which are not allowed in Haskell and that an interpreter would be difficult too
|
|
|
23 2012-04-23.txt:02:41:53: <zzo38> Another programming language I wanted to invent, other than Ibtlfmm, is one which combines C, LLVM, and BLISS. Do you have any suggestion for name? Probably I could implement it more easily, and possibly in Haskell; but it will compile into LLVM
|
|
|
24 2012-05-06.txt:07:50:45: <zzo38> kmc: Myself too, it is why I wanted to make up the working group for new "Ibtlfmm" programming language, to make these and other features; perhaps we can help
|
|
|
25 2012-05-06.txt:07:53:03: <lambdabot> "Ibtlfmm"
|
|
|
26 2012-05-15.txt:20:19:15: <zzo38> Please read gopher://zzo38computer.cjb.net:70/0phlog*c_prog.ibtlfmm-part-i
|
|
|
27 2012-05-18.txt:01:26:50: <zzo38> Did you read the longer message I wrote about Ibtlfmm programming so far? I may write the second message later on too.
|
|
|
28 2012-05-18.txt:01:38:38: <zzo38> Another thing, I would like in Ibtlfmm, possibly a Haskell compiler could implement it too, but I don't know of any way to do this in Haskell, is: You can load a program dynamically (dynLoad :: Typeable x => FilePath -> IO x) and then x is the type of main in whatever file you are loading (you get an error if the types do not match).
|
|
|
29 2012-06-08.txt:21:40:17: <zzo38> The code I posted above is meant for Ibtlfmm rather than Haskell since it won't work in Haskell
|
|
|
30 2012-06-09.txt:04:05:19: <zzo38> With my ideas relating to typeclasses in Ibtlfmm, and local instances, then implicit parameters are the same thing and therefore do not need an extension like GHC's -XImplicitParams. You can simply do: sort :: a. (method cmp :: a -> a -> Bool) => [a] -> [a] So an implicit parameter is the same as a class method.
|
|
|
31 2012-06-22.txt:06:48:28: <zzo38> I have made the idea for Ibtlfmm which you can have two maps or sets of the same type but different ordering, but you cannot union them because these maps are of different types even though their contents are the same. I think this is the way they should be done
|
|
|
32 2012-06-22.txt:19:55:38: <zzo38> I want to make closed/automatic instances in Haskell or Ibtlfmm. In Haskell you might have: auto_instance :: ([Type] -> Q (Maybe [Dec])) -> Q [Dec]; You can use this in a class declaration to make it closed and automatic.
|
|
|
33 2012-06-23.txt:09:10:41: <zzo38> Do you like to have closed classes and automatic classes in Haskell (or Ibtlfmm)? Automatic classes are a generalization of closed classes. In Haskell, it might be done by a TH function usable in a class declaration and having the type: ([Type] -> Q (Maybe [Dec])) -> Q [Dec]
|
|
|
34 2012-06-24.txt:04:59:39: <zzo38> With Ibtlfmm, we would have "kind" and "data kind" declarations (the first for kind synonyms, the second for enumerating the types belonging to it and how many parameters they are required to take; all the parameters are kinds, and there is only one "kind of kinds")
|
|
|
35 2012-07-02.txt:04:47:40: <zzo38> Do you think it should be return and join methods of Monad and then have Functor as superclass and (>>=) is not a method? I have read why you wanted (>>=) a method so I instead proposal (in Ibtlfmm, perhaps) to have (=<<) as a method because that way works better with other categories.
|
|
|
36 2012-07-02.txt:05:16:56: <zzo38> In Haskell you cannot always define these things interrelatedly but perhaps Ibtlfmm may allow it by specifying mahematical laws. And do you understand the reason why I wanted to define (=<<) instead of (>>=) for use with other categories? It is like a functor from the Kleisli category (but represented by the base category) to the base category.
|
|
|
37 2012-07-08.txt:06:28:31: <zzo38> I know overlapping instances is not the best solution but it is what Haskell has. The solutions in Ibtlfmm work better but we don't have that so instead we use what we do have.
|
|
|
38 2012-07-08.txt:07:02:47: <zzo38> I think the type class system how it is implemented in Haskell is just somewhat bad in general; it is why I proposed the Ibtlfmm system which should correct these and other problems.
|
|
|
39 2012-07-08.txt:07:05:49: <zzo38> In Ibtlfmm, it would be possible for types to have annotations. Two types that are the same type but with different annotations are still the same type. The purpose of the annotations is they can be accessed by macros. Since classes will just be type synonyms of some constraint with many parts (the methods, laws, superclasses, etc) then "instance" can also be a macro that takes this into consideration!
|
|
|
40 2012-07-08.txt:07:06:11: <zzo38> Therefore you can have default definition of class methods even though there needs not have this feature built-in to Ibtlfmm.
|
|
|
41 2012-07-08.txt:07:18:06: <zzo38> (It is just that in the case of Ibtlfmm, they are somewhat stronger and the compiler is allowed to attempt to disprove them as long as it does not go into an infinite loop in doing so, and even if it does disprove it you should get a warning. There are other things that make them stronger too such as allowing implied stuff to be assumed too)
|
|
|
42 2012-07-08.txt:07:26:27: <zzo38> How do *you* think Ibtlfmm's class system and Haskell's class system will be compared?
|
|
|
43 2012-07-08.txt:07:27:56: <Taneb> Ibtlfmm?
|
|
|
44 2012-07-08.txt:07:29:23: <Taneb> `pastelogs Ibtlfmm
|
|
|
45 2012-07-08.txt:07:29:41: <lambdabot> "Ibtlfmm"
|
|
|
46 2012-07-08.txt:07:59:53: <ais523> `pastelogs Ibtlfmm
|
