|
The lack of enthusiasm for a breakthrough in anonymity seems to spell doom for Monero and Zcash.
Seems people were only excited about JAMBOX, not anonymity. So that is good to know. Thanks.
|
|
|
|
|
Lack of feedback seems to indicate the enthusiasm that was displayed before I wrote the prior post, does not exist if following the posited plan in the prior post.
That has been my feeling all along. There is apparently only one way for me to proceed which is impoverished alone, since I refuse for legal reasons and also for the CC's ideal distribution, to be directly involved in any ICO and developers are not willing to join an unpaid project.
So don't complain about the pace of progress. I am still only a human with 14 hours of work a day.
If there no significant change, I ask SOMAcoin to kindly close this thread. We don't need it cluttering the Altcoin Discussion forum.
|
|
|
|
Is it an ico ?
Sorry, i see now mining mentioned. Ok, well sounds interesting.
One particular question: does it mean JAMBOX is a seperate project from this?
I am writing this after being awake for 18 hours nonstop work. So this is sloppily written. I am rushed. I don't want to lie. I will give it to you frankly. I did not vet the following statements with HONCHO. So he may have clarifications and I will notify you later if he does. Okay the good and the bad news. Everything below is subject to change.Let me try to lay everything out and get the feedback. I haven't made any final decision yet, so you can possibly influence with your replies, but please pay close attention to every detail below and the logic of my circumstance. 1. I did not plan to launch a CC now. My plan was to finish my work on the programming language I am in the midst of designing, then go launch JAMBOX, then after that launch a CC distributed to the users of JAMBOX who I was hoping would number in the 100,000 minimum or quickly rising to a million+. I have a detailed plan on that, and I have not abandoned it. I want to emphasize that the CC for JAMBOX will not meet my goals on distribution if it is not distributed to the actual users of the network. If it is distributed to investors, then the CC will never widely circulate and nothing will have been achieved. You will never never get a CC to widely circulate if you have the investor hoarding the coin. Period. 2. I stumbled onto a clever way to improve anonymity technology to add some potential benefits which I already enumerated in a post over in my thread: Here are the potential advantages my co-developer and I quickly enumerated today in chat:
Co-dev: "so ours is less bloat, prunable, more anonymous, quantum-computing resistant, more performant, and IP shielding"
myself: "and our anonymity sets are huge, potentially 1000s per mix"
Note that ours will have the weakness compared to RingCT/Zcash that we won't hide values so the mixing will be limited to transactions that people choose to mix with specific denominations (which is the way the current Monero works). I don't think we plan to mix every single transaction and have a complex wallet like Monero. Monero will simplify that when they implement RingCT. But RingCT can never scale to every (micro) transactions of the masses.
Any way I am talking off the top of my head and too prematurely. I need to go write some of these specs down.
3. I did not expect to stumble onto that discovery now. So I decided to offer the technology for that for sale to the highest bidder. I was expecting maybe I could sell it to Dash or other existing altcoin for some token amount (maybe a couple thousands), and get some money and then proceed on my work mentioned in #1. The highest bidder thus far is my angel investor (who we will name HONCHO) who also happens to be a prolific developer in crypto. And it turns out that he is ready and willing to launch a new anonymous coin which we will name ACOIN. So I wanted to just sell the technology to him and/or consider it full payment for the angel investment, so I no longer owe him anything. But he said that he is very interested in JAMBOX and he said that he doesn't want to launch a coin with my anonymity technology unless I will also somehow tie my JAMBOX to the coin we would launch now. Also he wants to do an ICO, and that is one way he can offer to pay me the most. But I told him that I don't want to sell vaporware and also I can't be involved in any ICOs because I am a US citizen. Please note that I am not against an ICO if it doesn't involve me legally, and also if the ICO does not represent the future distribution of the JAMBOX coin. I would not create a CC for the millions and then ICO it. I wouldn't allow it to be professionally mined either. I would make sure that that only people that can mine it are the social networking users, so that the distribution is as wide as possible. How will I do that? Don't ask me now, but I have a way. Also I had long said that I don't want to launch my coin here on Bitcointalk, because I feel I need to be able to market it to millions of users in order to achieve my goal so marketing a CC to speculators here on this forum is not going to reach the goal. So what can I do? 4. HONCHO offered to pay me to add my anonymity, ASIC resistent proof-of-work (which I think is better than Monero's), and some other work on the coin he will create. In exchange, he wants me to exclusively contract him to implement the DE (decentralized exchange) on any CC I will create for JAMBOX. So what this means is that there will be new op codes in ACOIN and in any JAMBOX CC not supported initially by any other CCs. So this means that for some period of months after I would launch any CC for JAMBOX, it is very likely if not certain that only ACOIN could be used to buy coins cheaply from social networking users that want to dump their coins which they mined for free. The social networking users will perceive that they are mining these coins for free because they won't even realize they are mining when they are using the social network. So from their perspective, they will never count the electricity because it will be too minute for them to notice on their electric bill. So it is quite likely many of them will dump these coins for peanuts. But not all of them will (else I will have failed in my responsibility to make many ways for them to spend this JAMBOX CC). So what I am saying to you is that I have an offer to do some contract work on a new ACOIN. And users who buy that ACOIN, then have apparently first dibs on buying cheap JAMBOX CC because in return I will contract HONCHO to implement the DE between both of these CCs. Note of course that over time the free market will make other ways to exchange but for some months it will not be very easy for the free market to go around the exclusive contract because just think about it. Social networking users are not going to go register in some exchange like Poloniex just to sell $10 worth of coins each. Over time the holdings between users and investors will balance out to a market equilibrium and then centralized exchanges will be come viable. Over time others will reverse engineer our op code and make other DE. But that won't happen the day the DE is launch. Competition takes time. 5. So ACOIN would be a way for me to emphasize the anonymity/privacy technology that I probably will not get around to adding to JAMBOX CC at least not in the initial release of JAMBOX CC, and to add other features to ACOIN that I want to put in any JAMBOX CC such as the improved PoW ash function. So I see ACOIN as a viable coin by itself that will have some features the JAMBOX CC won't have. And the ACOIN will have the aforementioned access to the JAMBOX CC. But the ACOIN won't have the scaling that I want to put in the ACOIN CC, because I need to totally rewrite the source code for that. I can't start with the Bitcoin source code and achieve the radical scaling changes. And I am not ready to totally rewrite a CC source code until I complete my new programming language (or abandon the idea of creating a programming language although it is very important for my plans for replacing the web browser with an app browser). 6. The funding I would hopefully gain from ACOIN would enable me to hire a full time top developer (from outside of CC) to help work on both JAMBOX and JAMBOX CC. Most of the money raised for ACOIN, I presume would go to the development of ACOIN. It is possible that the development of ACOIN will mirror the development I do on the JAMBOX CC, but I can't promise that since it won't be my coin. I will be a paid developer on it, but not the only developer on it. The point is I will not go launching my own coin here on Bitcointalk. ACOIN would not be my coin, although I would be having a strong influence on it. And it would be the way for me and others to acquire JAMBOX CC. So you can bet I will hang on to some of my ACOIN (assuming I was paid some in ACOIN and some in BTC)! 7. Let me emphasize that I would not approve of this plan if it involves any vaporware. Any ICO must be for a coin that is already in testnet and ready to launch with all the features as stated. And any ICO must be open to everyone first-come, first-served with a limit on total coins. Or something like that, but any way I am not in control of any ICO. And I am only stating that which I would refuse to be paid to work on. I will tell you that of course HONCHO will make a statement but not yet. And I will also tell you he was involved in all the recent big ICOs. So apparently he knows what he is doing. Because I don't know a damn thing about that and I don't want to know. 8. The person who is helping to set the W3C standard for IoT is asking me to be the co-author of the standard. He and I had conversations in the past. I don't know if I can manage to fit that into my schedule. And I don't know if HONCHO wants to try to target IoT. There are many other ideas that might come into play. We are only 24 hours into this idea so far. If the community approves, I can continue. If the community doesn't like, then perhaps I will decline the offer and continue working impoverished as I am at my slow pace. You tell me? Spoetnik I know you don't approve. Try to read what I wrote above. Think about my situation. I have negative net worth. I have only a small cash reserve which isn't even my own money. I been giving everything of myself to CC research and development. I have been ill for 4 years but doing better now with sublingual oregano oil daily. So which direction does this community think I should go? |
|
|
|
I m a bit astonished about you (TPTB) not knowing bad apples are equally distributed and always need biggest self control, just don t care. (Put on ignore)
I m more eager to see code & ideas. Only this matters.
Cheers!
If I didn't care, I wouldn't produce work with passion. You either want passion or you don't. Greatness only comes with passion. I will guarantee you that. Look at all the greats, they have tremendous passion for their goal. And they were also ruthless in taking revenge on their critics by proving them wrong. How many examples do you need? Go listen to Kobe Bryant talk about what motivated him to work so hard. He used the criticism to drive the fire in his belly. That is my personality. I am intense. Don't expect me to be bland and level. If you want bland and level go hire the Bee-Gees to make your altcoin. |
|
|
|
Slockit (the only smart contract killer app ?
Which we explained upthread can't pass the Nash equilibrium mustard. No decentralization here folks. You might as well just use a server. There is no point nor technology at all here. It is all bullshit for gamblers. Enjoy. Buy more! I tried not to repeat, but this all are hints to me that some top guys are cashing out and seek some more working/profitable invesments / positions for their ICOed money now.... Yap that is why I wrote to the greater or lesser sage phools, "buy moar!". |
|
|
|
Ceti, it is scumbags like you that create threads like this claiming that I bribed TPTB to keep quiet when I claim that I didn't, TPTB claims that I didn't, and the original poster has no evidence all contradicting either of us. It is nothing but a made up smear tactic, that that is quite pathetic. So yes, someone has something to hide here, but it isn't us, it is the people creating threads like this, or like yours, that make a lot of bogus claims to attack people (such as the nonexistent "Monero marketing team") with no evidence. I am staying out this argument. Somehow I feel I'll be dragged into it. I'll step on somebody's toes. Welcome to Altcoin Roller Ball. |
|
|
|
Follow-up: Its no good knowing the types that 'may' be in the collection, when I read the head of the list what can I do with it?
Perhaps I need to expand that? If I don't know whether the element at the head of the list is a String or an Int I cannot do anything with the value.
That is true even if you use a nominal enum, a trait object, or even your HList. There is no way to avoid branching in software unless you only have one type () (unit) in the entire program. Effectively you are arguing you don't want a program. You want a brick. Even though there might be more than one data type of the trait bound dictionary, it can be possible to optimize this selection by for example keeping branches nearby in instruction cache and pipelines. What I am saying is an optimizing compiler can receive these dictionaries at compile-time so it can fiddle with them to optimize the branching performance. Rather than having them in some vtable that entirely breaks pipelining. There is nothing you can do to avoid branching. It is part of software. Sorry can't help you there. Lol. Any way thanks for the point. You indeed drove this issue straight to the point which is why I really appreciate you. I couldn't have seen those issues immediately without you raising the issue. Btw, I just realized that we could actually count the number of each data type in the collection using typing and then compiler would know which cases are likely to occur most often. Or a hotspot VM can attempt these profiling low-level optimizations with run-time profiling. If I know all elements in the collection implement the X trait, then I know I can call any method of the X trait on the value of unknown type safely.
I can do that because I know that all elements in the collection must implement trait X, because I know the memory layout of the vtable for trait X, and I can then indirect function call to the vtable to access the method no matter what the type is at the head of the list.
Knowing which trait implementations are possible not just which trait bounds, can enable optimizations as I mentioned above. If you can't limit which trait implementations, you can't make the above optimizations and you'll be stuck with indirecting to a vtable and stalling the CPU pipeline. So the important thing is to know what traits all elements in the collection must implement, I don't care about their types, and I cannot know their types at runtime. knowing that the collection is Int \/ String does not help me do anything with the value at the list head, because I don't know if that particular value is a String or an Int .
Incorrect as explained above. All my performance work is based on benchmarking and profiling. Unfortunately not all algorithms parallelise well. One of my monte-carlo simulations gains so much information from a single run, anything in parallel is useless (because you now have much better parameters, all your parallel runs are no longer relevant).
Okay that is I guess true in some or even many cases. But I think for most what I would refer to as "mobile apps" and server apps (which is my first use case) that concurrency is vital. Parallelism also maybe to some degree. Afaik, HKT are necessary when we need to abstract over the type constructor of ourself (speaking from the perspective of a data type). So for example, Self is a HKT when it is an result type in a trait, because this means any application of that trait requires to know which data type implemented that trait. We can see this more clearly in Scala, where we would write: trait Foo[Self <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Bar];
I am not sure that the Scala is saying? The type parameter of Foo must be a subtype of Foo with the parameter Self? It doesn't really make sense to me. Yes it is saying that Foo[Self] takes a parameter Self. Then it also constrains the parameter Self to be a subtype of Foo[Self]. So then means that Self must extends Foo[Self]. So this makes Self a HKT because it is a type parameter that over the type instance construction operator of Foo. When we declare an instance (not data but declare a type) of Foo[Self], we also set the parameter Self to that instance that was declared. So that is HKT. How do you think about and visualize HKT? |
|
|
|
smooth himself is one who tells everyone that they are a piece of s*** and delusional meglomaniacs and what not.
Not everyone no, but some people are pieces of shit, and when they are I call them out and reference the evidence documenting it. If you want a nice fun time gambling on nonsense, with no one being challenged (other than maybe some friendly ribbing) when they fuck up or held accountable for their own actions, stick with your Friday night poker game or office betting pool. I understand smooth's feeling. He has worked very hard to try to produce a quality open source, decentralized methodology (i.e. not necessarily the current result) for improving crypto-currency. In short he and I both believe in meritocracy. And the principles of open source. I also got frustrated seeing others get so much for so little effort or technological accomplishment. But I also started to remember that nature isn't fair. Nature has its own way of annealing to the fittest result over time. It doesn't always take a straight path. The difference I think may be the degree of religion. I am not quite yet sure of the difference in our personalities. Every man is unique. I am very flexible to aberrations, paradigm shift, and serendipity. I reinvent myself often. Some people thought I was dipolar because I am so apt to take a sudden right turn without warning. It is not dipolar. I just have a very highly elevated level of dopamine. |
|
|
|
rarely and almost always about the community he is managing). Seriously though, smooth is an ethical person.
Good reply overall except for that part. I'm not "managing" any community, I'm part of one (actually many, some overlapping). I have no say over what people do, nor who supports Monero and what they say or do about it. People are responsible for their own actions. This is that "we are doing it decentralized" philosophies that is very important to your ethics. Okay but I just want to remind you that you are the dicktator in chief of the Monero Speculation thread that is bumped every 6 seconds. Dicktator != decentralized. |
|
|
|
What I think funny is that the same day TPTB_need_war (as sockpuppet1) calls Monerian's communists a real sock puppet calls smooth an imperialist who bribed TPTB_need_war to say nice things about Monero. Too weird.
This can only happen here on Bitcointalk!  Lol. Do you know what it feels like when you have a eureka moment, then share it and have noobtrader and MoneroMoo tell you that you are piece of shit that never accomplished anything and you are delusional meglomaniac and other kinds of other nice words. And then when I refute ArticMine's Communist defense of Copy-left licenses, smooth protects his community by deleting my posts. I mean I am in the middle of a debate and he censors it. I understand the dilemma he has. But I would never, never had put up with a community like that. <joke>If I end up with a community like that, I will disown them! I'll kick them out on their ass to go join my competitor. Even Linus knows troublemakers are not worth it. You keep the people who can help you succeed. Let your competitor have the riff raff, lol.</joke> Seriously though the altcoin scene is a rollercoaster of male menstruation cycles. Basically the community I am shooting for are those who are helpful, pleasant, insightful, critical in an amicable way, and of course the big prize is the huge community of 6 billion people. I don't expect to get them all into a forum. I have to reach them with technology. So this forum is kind of irrelevant in a way. |
|
|
|
Doesn't come unexpected to be honest but still quite a SHOCKER I like smooth. He has been very fair with me and helped me also. He even paid/donated a few BTC one time to me.
´smooth´ is the anonymous front face and imperialist of the controversial Monero Club. ´AnonyMint/TPTB_need_war´ is an independent Cryptopioneer who is on the forefront of crypto auditing. Evidently, smooth has deliberately bribed AnonyMint/TPTB_need_war in order to silence him on Monero's severe flaws.LOL no. We offered him a bounty for identifying weaknesses in Monero in 2014*, which I paid him and he has written about on the forum many times since. Nothing has been kept secret. Nice FUD though. * This was in connection with the alleged coin-stealing vulnerability in the crypto BCX claimed to have, and which TPTB claimed to have found, but which turned out to be nonexistant FUD. What TPTB found had nothing to do with BCX but was still a valid contribution so I paid him anyway. Yes smooth paid me out of his own pocket. I thought I had an agreement with Monero but I guess there isn't really any official "Monero" so it wasn't quite clear who would judge if I deserved any bounty. It was a mess. And smooth out of the kindness of his own heart, paid me afair 2.5 BTC. The BCX incident is difficult to explain. I thought I was helping and as smooth says I did find one insight, but in another way I unwittingly perhaps helped BCX short Monero or whatever he did. I am not really even clear what happened. Any way smooth never bribed me. Smooth knows he doesn't own me. Lol. I flip him middle finger in PMs sometimes (rarely and almost always about the community he is managing). Seriously though, smooth is an ethical person. Your issue with smooth is not his ethics. The issue is smooth believes in community very much. I just want to point out to smooth that a community of Linux developers is not the same animal as a community of gamblers who are not communing about coding. Smooth and I would be happy campers in a forum of like-minded programmers talking tech shop. My guess is Smooth seems to believe in enforcing ethics and creating a community for Monero. I think this is where the boundaries get blurred. It is not that smooth is incorrect in his logic. But there are different perspectives and feelings in play. And different vested interests and all valid from their own right. I think perhaps we just need to admit the altcoin arena is a Wild West that doesnt want a Sheriff. Any way, he is free to do it his way. Smooth has very little influence over me. He has influence over me in terms of explaining realities in the altcoin scene that I wasn't focused on. But I also work through the logic on my own and eventually perhaps come to a different perspective over time. |
|
|
|
Has your co-developer ever been involved with development of the Bitcoin protocol?
Afaik, no. But I think he knows enough to do a reliable fork since he has forked Bitcoin before. But he wants to fork the latest version. I need him because I have not invested the effort to become knowledgeable about the Bitcoin source code. He may be asking me to help though on the Qt wallet modifications. I may also help on the op code changes we need. |
|
|
|
Maybe this is indeed the continuation of Bitcoin itself unfolding to areas not deemed possible in the past.
You are a man of little faith, it is not maybe. Rejoice, brothers and sisters, we're saved! This time for sure. I am not close to destroying Bitcoin. Millions of users is still many months or more away from now (and no promises of that of course, just my goal). Baby big steps first. I will explain more soon. I had many times promised I am not going to launch and endorse my own coin here on Bitcointalk.org. So I will need to explain how I am going to keep that promise. P.S. we are thinking of forking Bitcoin 0.12 and making the modifications for anonymity on that. And then we will add the advances I want for my ultimate coin in stages.[/size]
Very interesting approach! And it's not because of anonymity, which in a way or another some coins provide. The interesting part is imho that this is based on a (recent) version of Bitcoin. Maybe some day Bitcoin devs will make themselves an upgrade of Bitcoin to make it anonymous. It gives Bitcoin a good chance to make the first steps into implementing some of the things altcoins proved that's good and needed directly into Bitcoin. It would mean the evolution quite some of us hope for... But maybe I dream too far...Yes I could see this also potentially making it easier to get this anonymityprivacy tech adopted into Bitcoin, but yeah maybe that is just dreaming. I think people who control Bitcoin now (China) may not want anonymity. But also realize this technology is more about privacy. Absolutely anonymity will never exist. Ever. In any design. Period. You can use it to attempt to be anonymous to the NSA but just like Monero and Zcash, you will probably fail but YMMV. You might succeed if you are very careful about your meta data. As for privacy, that should achievable for just about everyone who uses decent anonymity technology such as this one we want to create, Monero, or Zcash. The difference is the scaling and other advantages I mentioned. Lol I was talking my angel investor and he said his computer locked up for 15 minutes because he was syncing only 1 days worth of the Monero block chain on a computer with just a regular HD not a SSD. So maybe TPTB will embrace this technology. I don't know. But there are other reasons to want to have this coin, if you are concerned that Bitcoin could just take the anonymity technology and leave this new coin with no USP (unique selling point). I will explain more on this soon. Privacy that can scale to the masses is IMO more important than delusions of anonymity that can give you absolute guarantee of hiding from the NSA. No design for anonymity can ever give you such an absolute guarantee. Even I can explain to you how Monero can be unmasked by the NSA. |
|
|
|
Sometimes I think I wish it was. But I really don't yet know smooth's coding and productivity. Based on our conversations, I assume he is at or above my level of capability in terms of knowledge of programming (but I might be on a different level of creativity that is hard to quantify, I dunno). But I don't have verification. I should study his Aeon commits but I don't have time. I like smooth. He has been very fair with me and helped me also. He even paid/donated a few BTC one time to me. It pains me that smooth is the leader for the community that has a few bad apples who have to be so acrimonious. Having said that, I like iCEBREAKER's humor. He is not the problem for me. I feel debt of gratitude or even a real debt to smooth. I like smooth, but I think he is going about this community and open source thing the wrong way. Crypto-currency is not Linux. I may be wrong. Any way, I am not feuding with smooth. I just wish he wouldn't delete my posts. I don't make many posts in the Monero Speculation thread. Any way, no he is not my "co-developer". Smooth may know things about my plans that others don't know. Not because I told him lately, but because I told him a lot last summer, so he may be able to deduce certain things. I trust him to not reveal to anyone for another month or less. Soon all will be public knowledge. And no deal is final yet. So there is a chance I don't proceed. |
|
|
|
I can't tell you how old he is. I swore to never tell. Obviously it isn't Vitalik. And it also isn't David Zimbeck, nor Charles Hoskinson, nor anyone from Bitshares.
I trust you'll keep us informed.  BTW, to everyone: I myself am uniformed with regard to the technical issues, but TPTB's description of his flash on inspiration - aftter a lot of work - rings true to me, at least in terms of how real inspiration-flashes come about. So to the extent to which the following is credible given my lack of technical expertise, I vouch for him. The anonymity tech will be well explained for layman. I won't release some technobabble without clear explanations that you can explain to your teenage son. If we proceed with this project, I think we will hold the explanation secret until very near to launch for obvious reasons that we would want first mover advantage. I'll be composing a long post shortly to address your question about distribution. Please note nothing has been fully negotiated yet. I am speaking hypothetically about potential deal that hasn't been signed yet. I am also working programming language design today which is another very deep technical topic, so my time is spread all over. @Mr. Moore
I'm extremely interested in how you will solve the mining centralization issue that is destroying Bitcoin as we speak?
IMO this Bitcoin fork will redefine Bitcoin probably.
I will say something about this in my next post. |
|
|
|
Slockit (the only smart contract killer app ?
Which we explained upthread can't pass the Nash equilibrium mustard. No decentralization here folks. You might as well just use a server. There is no point nor technology at all here. It is all bullshit for gamblers. Enjoy. Buy more! |
|
|
|
Another major advance for programming language design from me! I am starting to fire on all of my cylinders as I used to do when I was prolific. Damn illness the past 4 years held me back. I am feeling pretty good. I need to backup this info some where, in case every Rust forum private threads disappear. So I am putting this here so others can read about my design progress. I think we should first enumerate the cases where anonymous (as opposed to nominal enum and nominal trait A: B + C) unions and intersections would be useful to eliminate boilerplate and enable expression, before discussing whether and how to integrate them. 1. Intersections on nominal trait bounds. Rust already has this. 2. Unions of nominal data/function types and/or type parameters for function arguments and result types. 3. Unions for data/function types for the element type of first-class heterogeneous collections (avoids the alternative HList-style boilerplate and conflation of semantics). Subtyping subsumption or trait bound subsumption are not extensible in both directions of the Expression Problem. 4. Unions as the locally (not principle typings) inferred type of an expression, e.g. an if-else. Otherwise all branches of a code block must have the same type or we must employ the boilerplate of a nominal enum (which obviously can't be inferred). Can you think of any other use cases? Especially any for intersections? We do not want intersections of data/function types because that puts the anonymity on the outside of the type, i.e. it is no longer a data/function type and thus we introduce structural typing! Intersections of trait bounds can only be written on type parameters. Rust matches closure functions on structure, but the structure is always on the inside of a nominal trait bound. We don't want to introduce structural typing because it causes inference divergence and perhaps also unsoundness. My current thinking is that you can simply leave intersection and union types out of inference, so all inferred types are monomorphic, that way the type inference can look like HM.
Exactly my thought too as evident by my prior post wherein I think I enumerated all the use cases for first-class unions and intersections and they are all explicit annotations and/or local expression inference that is constrained by the annotated function signatures, so no need to involve first-class unions and intersections in principle typings inference. The question then would be how to introduce them. You could have first-class-polymorphism and introduce them in a datatype.
I am not thinking this is necessary, but if you can show an example where it can only be sound that way, I am interested to see it. Really type-annotation is necessary. We can stick to the 'only infer HM' types rule, and then it would be up to the programmer to annotate as appropriate.
Yes that is what I have always been thinking I wanted. The inference would only be for the expressions within the function body. I just don't see global inference as desireable. I understand there are some cases where local expressions require annotations due to failure of inference, but that failure will be less like with first unions. For example, in that Scala example that required needless type annotation of casting a None to Option[Int], the Option would not be a nominal type in my proposed language. Instead the type would be Int \/ (). So thus combining an Int and () in the same expression would produce an Int \/ () inferred type. To keep it simple, I probably would not have traits as well, nor would i have structs and enums, as these can all be constructed from intersection types.
I have explained that we need nominal types as that is how we differentiate from the structural types, so the structural types are never inferred as principle typings (instead only function signature annotations or as intra-function body expression types). I am trying to basically have Rust but with unions, GC, and async runtime. Will be a better Rust for high-level programming. Then I'd like to explore our mutual idea for minimizing the need to use GC for temporary objects lifetimes correlated with the program stack. 1. I've just glanced at your cited references and of course reminded that System F isn't generally decidable for principle typings inference. If I understand correctly, all your concerns with first-class unions and intersections is due to the need to have principle typings inference. If we annotate all free standing function declarations (lambdas in function argument expressions excepted), then the concern would be vanquished. Correct?
2. You are concerned that function annotations could become very noisy because for example intersections of trait bounds could become quite large. For example, a function needs certain trait bounds for the operations it performs in the function body, plus it needs to require all the trait bounds for any functions it calls. I have an idea for a solution to this if we (or I) were to decide to abandon principle typings inference. We could have each function only declare the trait bounds that it needs in its function body, and the additional trait bounds required by functions called within the function body, would be inferred onto the calling function's trait bounds. Since those called functions explicitly declare their trait bounds, then this is decidable. It is a tree structure.
3. Afaics, the ability to exclude certain traits is inherent in my complete solution to the Expression Problem, because the dictionaries are supplied to the function orthogonal to the objects that contain the data types; thus it is impossible to cast a polymorphic data type downstream to any trait bound that wasn't annotated on the function declaration. Thus to specify NoIORead, then simply don't add a IORead trait bound to the function. But you wanted to infer the function's types, because of #2 above. Apparently one of the reasons you think the intersection of types would be so large, is because you want to infer the fully generality of the principle typings, thus you allow for a larger set than the function even desires, e.g. if the append method is employed within the function, you would infer any trait bounds with any append method. But this seems to dangerous. I prefer for the programmer to be explicit about his semantics. So if the programmer must constrain the append method, then he might as well just write that constraint as a trait bound annotation on the function signature. So really I am failing to see the benefit of principle typings inference?
4. The interaction of HRT (and I presume HKT) with first class intersections and unions complicates principle typings inference, and likely makes it undecidable if not just incredibly complicated. Another reason to abandon principle typings inference, because first-class unions and intersections are essential from my perspective in order to make the code more elegant and less boilerplate.
One of my other goals is to make the compiler as fast and as simple as possible. So not having complex inference unification solvers would be advantage. I am thinking also there is a better chance of not having corner cases in the type system and bugs in the compiler.
These points were made upthread and I am thinking they still apply. Btw, you mentioned Ceylon but it doesn't have type classes. Afaik, HRT (higher-ranked types) are necessary when we need to input a polymorphic function, then resolve the function application polymorphism within the function body, i.e. not monomorphic. Instead we enumerated other solutions which are monomorphic:
1. Making that polymorphic function a method of nominal trait Foo and inputting Foo.
2. Or inputting a separate function for each polymorphic variant of application in the function body.
3. Or inputting a function employing unions for the variants, when the semantics are acceptable.
Afaik, HKT (higher-kinded types) are necessary when we need to abstract over the type constructor of ourself (speaking from the perspective of a data type). So for example, Self is a HKT when it is an result type in a trait, because this means any application of that trait requires to know which data type implemented that trait. We can see this more clearly in Scala, where we would write: trait Foo[Self <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Bar];
We can see that Self is abstracted over the construction of a type instance of Foo by the class ... extends, which is sort of analogous (not really) to an imp ... : in Rust. I don't see how HKT breaks monomorphism? I think the unsoundness in the interaction with unions or intersections would only be occurred if we try to put them in the declaration of the definition of a HKT: trait Foo[A, Self /\ A <: Foo[Self]] {
def myself: Self = this;
}
class Bar extends Foo[Int, Bar];
But can't even see the use cases where that capability would be useful. Do you? I am thinking of only allowing HKT on Self. |
|
|
|
I can say that my co-developer refused to allow the masternodes have the ability to unmask the anonymity. I was arguing for a simpler design but his standards of ethics on the technology are even higher than mine. Then apparently we were able to devise a solution so the masternode could not unmask.
Evan DuffieldNow I'm curious as to how, and to whom, this goes.... I can't tell you how old he is. I swore to never tell. Obviously it isn't Vitalik. And it also isn't David Zimbeck, nor Charles Hoskinson, nor anyone from Bitshares. |
|
|
|
awe come on, don't tease
Give us a month (or two so we can launch) please before spilling all the technological beans. I don't know how long it will take to launch. S/w development always takes longer than estimated. Also I am not 100% sure yet if we are proceeding. I am still reviewing all these details. |
|
|
|
|
Show Posts
