OvermindDL1 wrote:> > I know why it was removed, and it does make sense, just would be nice > if there was an option to be able to get two pointer to a specific > llvm::IntegerType, functionally they would be identical, but for user > code (hence, my code) would be useful as I could match it for the > different ones at generate different code for each. >Well a language doesn't need to know whether an int is signed or unsigned if all the operators are aware of the sign of its operands. Such is the case with most assembly languages, and now LLVM. It makes the assembly cleaner (because types are used only for checking, not for overloading operations). And it seems you're going this way with your language (based on what you said in the most recent post). The thing is that high level languages really should encode signed/unsigned into the type system (or simply deal only with signed integers, as many languages do). You don't want your human programmers having to worry about the signedness of an int each time they do anything with it. OvermindDL1 wrote:> > With some discussion with others I think we came up with an acceptable > method (which allows me to completely kill my type duplication system, > thank god). > *snip* > Either way, what do you think of the above style for handling integers > now, think it will work? See any major issues with it? You think > people would have trouble using that style? >Well it will certainly work, but it's a pretty low-level / unsafe feature to have in any language higher than assembly language. I wouldn't like it if I was a user. But at least if I want to I can pretend there aren't any unsigned ints and go about my merry way (so that's OK, the only problem is when I actually want to use an unsigned int). The thing is, practically any language higher than assembly is going to require a type system, and that type system is almost certainly going to be different to LLVM's. (eg. How do you distinguish dynamic arrays from pointers? How do you give names to structure types? How do you distinguish characters from i8s? Strings from arrays of i8s?) LLVM can't possibly provide a rich enough type system for all the front-end languages; its type system isn't designed to be used that way. The cleanest compiler design (in my opinion) will have a completely type-checked program before it touches the LLVM API at all. The compiler should then always generate type-correct LLVM code (so your users should never see LLVM type errors, if your compiler is behaving correctly). -- View this message in context: http://www.nabble.com/Integer-handling-tp19719560p19735288.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
On Mon, Sep 29, 2008 at 8:49 PM, Matt Giuca <mattgiuca at gmail.com> wrote:> /* snip */The language I am making is not a traditional scripting language, it is designed for heavy math work. It has not classes, the basic data structure is a struct, yet even those are only used to pass messages. It is using the Actor-Oriented model, not Object-Oriented. I have been creating it to deal with taking the heavy computations and 'offloading' them from the main program in such a way that it can take advantage of multiple cpu cores, or even multiple computers, in a more transparent way, so I was intending for it to be pretty low-level regardless (it is not designed to be a standard scripting language, if I want a 'pretty' easy-to-use scripting language then I always bind in Python). You still gave me thoughts to munch on though. It could be more widely useful for others if I made the most complex data structures able to be referenced by names instead of types, but that introduces message complexities like requiring the end-points in the system to have the same code loaded (which the Actor model does not require) to be able to link the names with a relevant data structure (might look at Erlang for an interpreted implementation of the Actor model). Looking at it, the Actor model (since it is so ancient) really has no documentation on any higher level types (even strings do not exist, just arrays to store 'string-like' things). I should see about coming up with some 'obvious' higher-level constructs to see if they would fit in well with the system. I do not want anything complex as that just makes message passing more difficult. But for note, in the Actor model there are no global variables (there is no global state at all actually, unlike near every other language in existence), there are no pointers (as you might accidentally try to send a pointer in a message, which 'might' work if the end-point actor was on the same system, but that is not definite). The only 'pointer-like' constructs are in function arguments, and only to local variables on the actor's stack, since those are very controlled. By keeping the type system based on the actual types it allows arbitrary message passing to any other actor without needing to load any code relating to the actors, you can just send a structure with the appropriate ID and format and it will 'just work' as the pattern matching will ensure the other actor handles it correctly, or it gets dumped with a message stating no match. I guess I could have 'message header' files to define message types and allow those to be transfered across systems. A 'name' for a structure would still generally be larger then the type description of that actor when serialized though, which kind of defeats the purpose unless some method was put in to match message struct names with some sort of global identifier database across the whole system that is synced on all machines. Problem with that is if two systems setup a connection between them, that could be a lot of data to have to sync up, which could cause mismatches in the mean time, which again makes it sound like that type matching is safer again. If I did have the message name itself transfered and did not mind it taking up extra bandwidth there could still be issues if another user created a message of the same name but a different type, how would it match it, where-as the Erlang style of ID's and pattern matching of the types is still safer... So many things to consider...
OvermindDL1 wrote:> > It is using the Actor-Oriented model, not Object-Oriented. > /* snip */ > By keeping the type system based on the actual types it allows > arbitrary message passing to any other actor without needing to load > any code relating to the actors, you can just send a structure with > the appropriate ID and format and it will 'just work' as the pattern > matching will ensure the other actor handles it correctly, or it gets > dumped with a message stating no match. >Hm. I don't know much about the Actor model (but I do deal with declarative languages which similarly have no globals or pointers, so I get that concept). It seems like your language is very high level indeed (it almost sounds dynamic). If you can pass arbitrary messages without needing to statically know the type of anything, and pass data transparently from one machine to another. If it's indeed dynamic, then you probably want to implement a minimal dynamic runtime system in LLVM - have each value wrapped up in a struct which also contains some small piece of runtime information which holds its type. For example, along with each int (in an i32), store an i1 (bool) which specifies whether it is signed or unsigned, and have all relevant operations (such as division) depend upon that bool. Obviously this makes the language a lot higher level. -- View this message in context: http://www.nabble.com/Integer-handling-tp19719560p19735721.html Sent from the LLVM - Dev mailing list archive at Nabble.com.