New Post	New Topic
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 18, 19, 20  Next

08 Mar 2012 11:54:54 am by shkaboinka		Quote
merthsoft wrote: shkaboinka wrote: - PROPOSITION: I could allow there to be an uneven number of values in parallel assignments, such that only the right-most values in the LHS of the assignment get the values (the motivation for this is in the previous rule listed). For example, "a,b,c = x,y" would assign x and y to b and c. ... If it's reasonable, we can talk about a rule for the other way around (e.g. "a,b = x,y,z" drops the z?) I don't like this. I certainly would never use it, even if it were available. I was just trying to justify the uneven-ness that would appear for function defualt values; However, since they must be the last values, I have no issue with it anymore. Don't worry, there will be no uneven assignments allowed. Here is what it's looking like: (any concerns)? Code: func foo(byte a,b,c,d = 1,2,3) { ... } // b,c,d have default values do(start) { ... start: ... }while(something); // do "start", then loop a = b = c = d; // THIS IS NOW ILLEGAL! each(a,b,c) = d; // use this instead struct Bar {    ...    func Moo(...) { ... } // methods can be declared INSIDE...    func(...) funcPtr; // ...(not to be confused with variables)...    func(this,...) mth; // ...(or self-"this"ing variables)... } func Bar.Noo(...) { ... } // ... as well as OUTSIDE of structs. // In either case, these methods behave exactly the same way.

08 Mar 2012 12:00:19 pm by merthsoft		Quote
Code: func foo(byte a,b,c,d = 1,2,3) { ... } // b,c,d have default values I don't like this, I'd rather need to be explicit and/or have an equal number of vars as values. Code: a = b = c = d; // THIS IS NOW ILLEGAL! each(a,b,c) = d; // use this instead I don't mind either way. Why not allow both? Code: func(this,...) mth; // ...(or self-"this"ing variables)... Blerg, I hate passing "this" in to things, but it's not so bad--that's how C# extension methods work, and it's not soo bad.

08 Mar 2012 12:30:13 pm by shkaboinka		Quote
merthsoft wrote: Code: func foo(byte a,b,c,d = 1,2,3) { ... } // b,c,d have default values I don't like this, I'd rather need to be explicit and/or have an equal number of vars as values. Would you prefer this?: func(byte a,b,c,d = _,_,_,5) // d has default of 5 merthsoft wrote: Code: a = b = c = d; // THIS IS NOW ILLEGAL! each(a,b,c) = d; // use this instead I don't mind either way. Why not allow both? I proposed "each" as a replacement for chaining because it's cleaner to parse and read (rather than having to match up values into N "sets", when really each set has nothing to do with its constituents; thus, group by value instead). I want the language as simple (minimalistic) as possible without feeling incomplete. merthsoft wrote: Code: func(this,...) mth; // ...(or self-"this"ing variables)... Blerg, I hate passing "this" in to things, but that's how C# extension methods work, and it's not soo bad. If you think of it in C#/Java/etc. terms, then methods are declared in structs as you'd expect, and extension methods are declared like this: func FOO.bar(...) { ... } // bar is an extension method for FOO. Otherwise you have func(...) as a datatype (signifying a function-pointer in the examples from my previous post). Attaching a "this" in there just causes it to apply "this" automatically: Code: struct FOO {    func(*FOO, byte) fPtr; // func-pointer    func(this, byte) mPtr; // SAME TYPE as fPtr... } FOO f; f.fPtr(f,5); // ...except fPtr takes any FOO f.mPtr(5); // ...and mPtr automatically passes its container

08 Mar 2012 12:33:49 pm by merthsoft		Quote
shkaboinka wrote: merthsoft wrote: Code: func foo(byte a,b,c,d = 1,2,3) { ... } // b,c,d have default values I don't like this, I'd rather need to be explicit and/or have an equal number of vars as values. Would you prefer this?: func(byte a,b,c,d = _,_,_,5) // d has default of 5 Nope. I'd prefer func(byte a, byte b, byte c, byte d = 5). shkaboinka wrote: merthsoft wrote: Code: a = b = c = d; // THIS IS NOW ILLEGAL! each(a,b,c) = d; // use this instead I don't mind either way. Why not allow both? I proposed "each" as a replacement for chaining because it's cleaner to parse and read (rather than having to match up values into N "sets", when really each set has nothing to do with its constituents; thus, group by value instead). I want the language as simple (minimalistic) as possible without feeling incomplete. Works for me. shkaboinka wrote: merthsoft wrote: Code: func(this,...) mth; // ...(or self-"this"ing variables)... Blerg, I hate passing "this" in to things, but that's how C# extension methods work, and it's not soo bad. If you think of it in C#/Java/etc. terms, then methods are declared in structs as you'd expect, and extension methods are declared like this: func FOO.bar(...) { ... } // bar is an extension method for FOO. Otherwise you have func(...) as a datatype (signifying a function-pointer in the examples from my previous post). Attaching a "this" in there just causes it to apply "this" automatically: Code: struct FOO {    func(*FOO, byte) fPtr; // func-pointer    func(this, byte) mPtr; // SAME TYPE as fPtr... } FOO f; f.fPtr(f,5); // ...except fPtr takes any FOO f.mPtr(5); // ...and mPtr automatically passes its container I guess that makes sense. Now, two things: 1) Rename the language to Ketchup. 2) Let's get a compiler or something going so this can stop being so unsubstantial.

08 Mar 2012 12:48:44 pm by shkaboinka		Quote
merthsoft wrote: shkaboinka wrote: merthsoft wrote: Code: func foo(byte a,b,c,d = 1,2,3) { ... } // b,c,d have default values I don't like this, I'd rather need to be explicit and/or have an equal number of vars as values. Would you prefer this?: func(byte a,b,c,d = _,_,_,5) // d has default of 5 Nope. I'd prefer func(byte a, byte b, byte c, byte d = 5). I do have to admit that I personally prefer the second form (below). I'm just afraid it would create too much asymmetry in the language and possible confusion :/ (HEY PEOPLE! WOULD ANYONE ACTUALLY FEEL THIS WAY?) Code: func Foo(byte a,b,c,d,e = 1,2,3) // Matches the other rules better...-ish func Moo(byte a,b,c=1,d=2,e=3) // This is SO not allowed elsewhere merthsoft wrote: Now, two things: 1) Rename the language to Ketchup. 2) Let's get a compiler or something going so this can stop being so unsubstantial. Haha, nice ... I actually wouldn't mind a random name like that. I will consider it; but I'll have to really like it later too (remember this conversation). "Soon" is as soon as I no longer find any little holes in the language; but I realize that it might never be perfect first. I am hoping that within the next year from now, there will be some stuff up and running. FYI, the next thing I am probably going to be picky about is "interpreted aspects" ($); and I am although thinking about how gotos would affect the flow-structure of the language (e.g. how to map it nicely in the compiler). Also, I've been thinking that it would be nice to have an array and then name a set index of it as another variable (which would be WAY convenient for my compiler if Java would allow that ... I could store all the tokens in a static array and use binary search, but still just refer to them directly as variables). ... Anyway, once I have a good feel for how that will all work (or rather, that the language is not going to take any more significant turns and that there will be no surprises that I'll have wished I knew about before I coded the compiler as I did) ... THEN I will take the next step and make the syntax-tree-making part of the compiler. Once I start that, it will be on a ROLL; and there's part of me that just wants to be ready to dive into that! ... of course, how it will optimize and resolve to assembly etc. helps me feel more comfortable about actually doing it yet (etc. etc. etc.) .... HOPEFULLY WITHIN THE NEXT SEVERAL MONTHS I will have something at LEAST started

08 Mar 2012 06:04:32 pm by BlakPilar		Quote
shkaboinka wrote: BlakPilar (paraphrased) wrote: I forgot that a,b,c would be split up to x,y,z. I (wrongly) assumed that "each(a,b,c), ... = x,y,z" would assign x to a, b, and c. Um, you assumed correctly. Using "each" groups things together so that they collectively act as one item in a list (e.g. they will share a single value); otherwise they split up: Code: a,b,c = x,y,z; // x to a; y to b; z to c. each(a,b,c) = x; // x to EACH of them (x to a; x to b; x to c). each(a,b,c),d,e = x,y,z; // x to each(a,b,c); y to d; z to e; each(a,b,c),d,each(e,f) = x,y,z; // x to each(a,b,c); y to d; z to each(e,f) ...I'm just going to not respond to this part anymore because it's become too confusing for me and, like merth, I wouldn't use it. It's no offense to you, it's just like I said: I wouldn't use it. It kind of feels almost like overkill to me. Things like this could be much more simply put and understood as "a = b = c = ...;" (at least to me). :/ EDIT: merthsoft wrote: Nope. I'd prefer func(byte a, byte b, byte c, byte d = 5). ^ this.

08 Mar 2012 07:17:34 pm by shkaboinka		Quote
Recent Updates Summary: Gotos - I determined that you can ALWAYS create structures in place of gotos, so long as the gotos are forward and don't jump "in" (at the very worst, you can use a "do...while(false)" as a container to break from) ... and then I determined that it was cleaner just to allow such gotos. The rules for gotos are that you can only jump foward, within the same function, and never INTO another construct (out of is ok). The "do(start) { .. }" is the only exception, which is provided specifically (see previous posts). You can still "break" and "continue" and even "break foo" or "continue foo"; constructs are labeled just by placing a label before them (though I prefer this to be on the previous line so as not to mess up the indentation and to match the format of other labels). "Flattened" Hierarchy - I want to prevent programs/source from getting layered by keeping everything (aside from local and member variables) at the top level. This means two things: (1) No "nested" definitions: Entities such as structs, funcs, etc. cannot be defined inside of eachother (with the exception of methods and cofuncs being defined in structs). (2) Namespaces cannot be "nested" (they are declared at the top of the file, like a package declaration); and no more "using" keyword either (shorter namespace names are preferred). Default values for function arguments - Although it is sort of contrary to parallel assignments, default values are given to function arguments as most people would expect (noting that only the last arguments in a function can have default values): Code: func Foo(byte a, b=2, char x='Y', y='Z') { ... } Foo(1,2,'a','b'); // Normal usage Foo(1,2,'a');   // Short for Foo(1,2,'a','Z'); Foo(1,2);     // Short for Foo(1,2,'Y','Z'); Foo(1);     // Short for Foo(1,2,'Y','Z'); Multiple Assignments - Basically, "each(a,b,c)=d;" replaces "a=b=c=d;". This can get complex with lists of values: Code: each(a,b,c) = x; // Instead of (a=b=c=x;) each(a,b,c),d = x,y; // Instead of (a=b=c=x; d=y;) or (a,_ = b,_ = c,d = x,y;) NOTE: A more likely case than (...=x,y;) is a function which returns multiple values (...=twoValues();). Method Declarations - Methods can be declared directly within structs as an alternative to begin declared with "structName." in front (both forms will be valid). I feel that this more compact syntax is easier to read in many cases. Nevertheless, you can use either form, and they mean the same thing: Code: struct Foo { func Bar(...) { ... } } // declared internally func Foo.Bar(...) { ... } // declared externally Choosing Explicit Variable Addresses - This is done by placing the "@address" after the variable name. Use a string literal to specify an assembly-coded address, or another variable to share memory (overlap) with. Variables can be declared inside of array literals, though I have not chosen a good syntax yet (that might sound bizarre but it's actually very useful): Code: word cursor@"curcol"; // cursor will refer to "currow" in the assembly code. byte curCo1@cursor; // curCol now refers to the leading byte of cursor byte curRow@cursor+1; // refers to the trailing byte of cursor. WE CAN DISCUSS THIS SYNTAX func() f@"routine"; // f() now calls an assembly routine directly // Embedding variables within an array: values := [6]byte{0,1,2,3,4,5}; byte a@values[2]; // a is literally stored at value[2] byte b@values[3]; // b is literally stored at value[3] a = 1; // values[2] is now 1; values[3] = 2; // b is now 2; Though it might seem bizarre, embedding variables within arrays is actually incredibly useful; so I want to provide a syntax to do it all in one declaration; perhaps one of these (EDIT: removed the "ugly" suggestions): Code: values := [6]byte{0, 1, a=2, b=3, 4}; // Looks great, but kinda hides inner variables declarations. values := [6]byte{0, 1, a@2, b@3, 4}; // Jumps out more, though "a@x=n" is becoming "a@n" in here.

09 Mar 2012 11:24:38 am by merthsoft		Quote
Can you explain the namespaces a little more, and what you mean by there being no using or anything? In my mind this says that I can use another person's library, because my namespace will be "MerthsoftsProgram" or something, and there's will be "ShkaboinkasGraphicsLibrary".

09 Mar 2012 01:54:52 pm by shkaboinka		Quote
merthsoft wrote: Can you explain the namespaces a little more, and what you mean by there being no using or anything? In my mind this says that I can use another person's library, because my namespace will be "MerthsoftsProgram" or something, and there's will be "ShkaboinkasGraphicsLibrary". Code: ~~~~~~Banana.opia~~~~~~ namespace Banana; // Choose a common name for your stuff. struct Foo { ... } ~~~~~~Banana2.opia~~~~~~ namespace Banana; // Same namespace (so "Banana.Foo" is just "Foo"). func Foo.Moo(...) { ... } // Adding a method to Foo. ~~~~~~Monkey.opia~~~~~~ namespace Monkey; // This is a different namespace... func Foo(...) { // ...so "Foo" has another meaning in "Monkey".    f := Banana.Foo{...} //...but can still refer to the one in "Banana". } func Banana.Foo.Bar(...) { ... } // Adding method to Banana.Foo. f := Banana.Foo{...}; f.Bar(...); ~~~~~~Yours.opia~~~~~~~ // No namespace used (so everything in this file is GLOBAL) f := Banana.Foo{ ... }; // Use of Banana's "Foo". f.Moo(); f.Bar(); // <-- THIS one might not be allowed here (I will explain). Monkey.Foo(...); // Use of Monkey's "Foo". ~~~~~~Errors.opia~~~~~~ namespace Banana.Tree; // ILLEGAL! (Sorry, no nested namespaces.) using Monkey; // ILLEGAL! (Sorry, you actually have to type "Monkey" each time). Foo(...); // ILLEGAL! (What is "Foo"? There's no "Foo" in this namespace!) Go does not allow you to add methods to something from another namespace. However, I think that's fine; but if you add something to namespace A from namespace B, I might only allow you to use that method from within namespace B.

15 Mar 2012 11:51:45 am by shkaboinka		Quote
As for embedding variables in an array, I am leaning toward the "a=n" version; but how about this?: Code: values,a,b := [6]byte{0,1,@2,@3,4,5};

15 Mar 2012 01:04:54 pm by elfprince13		Quote
shkaboinka wrote: - PROPOSITION: I could allow there to be an uneven number of values in parallel assignments, such that only the right-most values in the LHS of the assignment get the values (the motivation for this is in the previous rule listed). For example, "a,b,c = x,y" would assign x and y to b and c. ... If it's reasonable, we can talk about a rule for the other way around (e.g. "a,b = x,y,z" drops the z?) There are two good reasons why most languages do a = x, b = y, c = z, rather than a,b,c=x,y,z. The former is more explicit about what is going on In most C-derived languages, the comma has a very different meaning as an operator than the way in which you're using it here (which seems to be highly context dependent, rather than consistent across several usages). Even in non-C-derived languages, the only exception to this rule of which I'm aware is Python's unpacking mechanism, which must be able to match the structure on the left to the structure on the right. You can even have something like a, (b, c) = [x, [y,z]], or a, (b,c) = (x, (y,z), but not b,c = (x,(yz)), or a, = (x,(y,z)). If you want to assign things that don't match up, you have to use slices. Both of those notations are actually quite useful, and something that are worth incorporating (in some analogous way). They work as language features because the syntax matches the semantic usage. shkaboinka wrote: As for embedding variables in an array, I am leaning toward the "a=n" version; but how about this?: Code: values,a,b := [6]byte{0,1,@2,@3,4,5}; Good use of @, but terrible use of := (nobody wants that, == for comparison is awkward, but := is more awkward). And the way in which that statement is organized really doesn't make sense. If I were to write that statement in a way that made sense (but borrows some of your syntactic idiosyncrasies), it would look like this: values = byte[6]{0,1,2,3,4,5}; @a, @b = values[2:4], or maybe like this @a, @b = values[2..4]. You could change your upper index in either of those examples 3 if your language's audience is mathematicians/physicists/etc, but if you want CS people to not be totally appalled, you're going to need to go with upper-bound-exclusion (upper-bound-inclusion doesn't make arithmetic or set-theoretic sense). The reason I suggest the python-esque slice notation, as opposed to the ruby-esque one, is that the python version is more flexible and easier to generalize.

15 Mar 2012 02:27:50 pm by shkaboinka		Quote
The parallel assignments have strong reasons for being part of the language (primarily to facilitate multiple return values); but allowing uneven values was a TERRIBLE suggestion (and thoroughly buried now), so please disregard it. The := operator is different from the = operator (declare and infer type). I thought it was ugly at first, but after looking at alternatives and trying it out, I really found it to be much simpler. I am pretty set about declaring variables "at" an address; but embedding them in an array literal really needs the array to be declared as it normally would, just with the variables being tied in somewhere. Anyway, the idea is useful where its better to use variables directly, but also would be very useful to iterate over them all or refer to them directly. It would be like having a Point struct with x,y,z members; but rotation about a cardinal axis can be done without "if"s if you give the index. I'm very glad to have you in this discussion though! Please give my overview a good look and try to get a feel for my design, and I'd love to discuss it in more detail with you -- e.g. why I made the choices I did, etc. I am very open to critique, but I also have made a ton of choices with a ton of thought ... but when I recognize a better choice, I go with it (hence the sudden switch from a C# style to a GO style)

15 Mar 2012 02:36:24 pm by merthsoft		Quote
shkaboinka wrote: As for embedding variables in an array, I am leaning toward the "a=n" version; but how about this?: Code: values,a,b := [6]byte{0,1,@2,@3,4,5}; Can you explain more what this is doing and why you'd want to do it? And also the difference between '=' and ':='?

15 Mar 2012 03:47:53 pm by elfprince13		Quote
shkaboinka wrote: The parallel assignments have strong reasons for being part of the language (primarily to facilitate multiple return values) My suggestion was that you look at the Python unpacking semantic, which is also used to facilitate multiple return values. As far as your multiple assignment goes, the use of each doesn't look bad on paper, but you need to have it clear in your head whether it's a keyword, or whether you're going to provide a mechanism for arbitrary functions to provide L-value iterators and redefine their own assignment behavior. If functions are first-class objects (and/or L-valuedness is an object attribute), and operators (including assignment) can be overloaded, the latter actually makes sense and is probably the more elegant way to implement it. But that requires a lot of linguistic infrastructure and opens the door for some really bizarre code (if you think decorators can provide brainmelting metaprogramming in Python, what until you see the implications of this). Quote: I am pretty set about declaring variables "at" an address; but embedding them in an array literal really needs the array to be declared as it normally would, just with the variables being tied in somewhere. Anyway, the idea is useful where its better to use variables directly, but also would be very useful to iterate over them all or refer to them directly. It would be like having a Point struct with x,y,z members; but rotation about a cardinal axis can be done without "if"s if you give the index. What I suggested would have the same effect - but much cleaner syntax. Quote: I am very open to critique, but I also have made a ton of choices with a ton of thought I can tell that you've given the language features a lot of thought, but what I'm critiquing here is your grammatical constructs for expressing those features. merthsoft wrote: shkaboinka wrote: As for embedding variables in an array, I am leaning toward the "a=n" version; but how about this?: Code: values,a,b := [6]byte{0,1,@2,@3,4,5}; Can you explain more what this is doing and why you'd want to do it? And also the difference between '=' and ':='? I'm pretty sure it's essentially this: Code: byte values[6] = {0,1,2,3,4,5,6} byte *a = &values[2]; byte *b = &values[3];

15 Mar 2012 05:02:27 pm by merthsoft		Quote
elfprince13 wrote: merthsoft wrote: shkaboinka wrote: As for embedding variables in an array, I am leaning toward the "a=n" version; but how about this?: Code: values,a,b := [6]byte{0,1,@2,@3,4,5}; Can you explain more what this is doing and why you'd want to do it? And also the difference between '=' and ':='? I'm pretty sure it's essentially this: Code: byte values[6] = {0,1,2,3,4,5,6} byte *a = &values[2]; byte *b = &values[3]; Ah, well, in that case it feels kind of weird to me. I think I prefer the more explicit way. Does something like this happen enough that it's really worth introducing that?

15 Mar 2012 05:14:19 pm by shkaboinka		Quote
elfprince13 wrote: As far as your multiple assignment goes, the use of each doesn't look bad on paper, but you need to have it clear in your head whether it's a keyword... It would just be a keyword-syntax for giving multiple recipients to a value (and therefor only usable as an L-value in assignment statements). Due to the "a,b, = c,d" nature of assignments, I thought it was cleaner and easier to read than making arbitrary "sets" with blanks mixed in (a blank is used to dump/ignore: "_, a = twoValues()"). elfprince13 wrote: What I suggested [for variables within arrays] would have the same effect - but much cleaner syntax. Perhaps; and you are correct that it's the syntax that I throw all over the place and vomit out immediately for discussion (resulting in some nasty examples and confusion ... sometimes that's better than losing the idea though). merthsoft wrote: I'm pretty sure it's essentially this: Code: byte values[6] = {0,1,2,3,4,5,6}; byte *a = &values[2]; byte *b = &values[3]; ...sort of... The MAIN reason for this is that you can say {byte x@"assemblyCodedAddress"} so that x is stored at "assemblyCodedAddress" (you can even do this with functions instead of giving them a body, so as to refer directly assembly routines or precompiled functions already in memory); but then I expanded the idea so that you could map directly to other variables. Declaring a variable "at" will alias it to a specific memory location rather than creating new storage for a new variable (unlike C++ "reference" variables, which are essentially transparent pointers). I expanded this further because I found it particularly useful have separate variables actually stored in an array, so that you don't have to choose between {having to remember that [0],[1],[2] are x,y,z values} or {sacrificing dynamic access for clarity}. After looking at the syntax, the picture I had in my mind of just encasing separate declarations in an array is bulky and confusing (I prefer the "{0, 1, a=2, b=3, 4, 5}" syntax), but I do want it to be able to be one statement so that you don't have to declare the array and then assign each index to each variable. I do really like the idea of "a[0:2]" being an alternative for "a[0],a[1],a[2]" (e.g. "x,y,z = a[0:2]") (or something close to it); but the "@" syntax (which has been in place long before I tried to introduce them into arrays) would collapse "x@a[0], y@a[1]" into something akin to "x,y @= a[0],a[1]" (that is, the "@" has to associate with the value, because @"blah" refers to an address, but assigning "blah" to @x is backwards to the paradigm of the syntax). I will say though that I am seeing more reason to get rid of parallel assignment in favor of tuples (I actually thought about this recently, but still felt that parallel assignment was "cleaner" ... but now other factors are coming in as per-item rather than per-list, so it's time for some rethinking). ... my wife is starving, so I will have to discuss that more later.

15 Mar 2012 10:55:59 pm by elfprince13		Quote
shkaboinka wrote: It would just be a keyword-syntax This is rarely a good idea. Introducing keywords should be backed by a very strong reason, particularly if they're going to be keywords disguised as functions. I would much rather see something along the lines of either a (tuple-centric) comma-separated unpacking scheme, or that you work out the technical details of the function-based version I outlined above than have you clutter the language definition with another keyword, unless it is very clear that what you want to do can't be done without it (but since other languages do what you want, without a keyword, it's a good sign that this isn't true). Quote: Perhaps; and you are correct that it's the syntax that I throw all over the place and vomit out immediately for discussion (resulting in some nasty examples and confusion ... sometimes that's better than losing the idea though). Basic features/design aside, syntax is what I have much stronger feelings about than specialized semantic constructs. Language features are why I prefer C/C++ to Java, but syntax is why I prefer Python to Ruby, and the latter preference is the much stronger one - most of Java's awkwardnesses and shortcomings can be worked around and hidden pretty well if you design your API correctly, but you can't hide from awful grammar. Quote: I expanded this further because I found it particularly useful have separate variables actually stored in an array, so that you don't have to choose between {having to remember that [0],[1],[2] are x,y,z values} or {sacrificing dynamic access for clarity}. Keep in mind that this is a convenience (and I can think of places where I would use it in programs I've written), but it's also candy - if you can't do it right, don't do it at all. Quote: After looking at the syntax, the picture I had in my mind of just encasing separate declarations in an array is bulky and confusing (I prefer the "{0, 1, a=2, b=3, 4, 5}" syntax) That latter syntax is certainly preferable, but either of your suggestions don't translate easily from static declarations to dynamic ones. Quote: but I do want it to be able to be one statement so that you don't have to declare the array and then assign each index to each variable. Remember that two readable statements are preferable to one impenetrable one. One liners are cute, but you shouldn't design a language around composing them, seeing as their maintainability is inversely proportional to their length (and we can always play a timed "guess what this does" game with one-liners from my own library of code if you want empirical data to back up my claim).. Quote: I do really like the idea of "a[0:2]" being an alternative for "a[0],a[1],a[2]" (e.g. "x,y,z = a[0:2]") (or something close to it); but the "@" syntax (which has been in place long before I tried to introduce them into arrays) would collapse "x@a[0], y@a[1]" into something akin to "x,y @= a[0],a[1]" (that is, the "@" has to associate with the value, because @"blah" refers to an address, but assigning "blah" to @x is backwards to the paradigm of the syntax). x,y,z = @a[0:3]. Don't you dare make it upper-bound-inclusive.

16 Mar 2012 10:10:10 am by shkaboinka		Quote
(I haven't had this much fun since Kllrnohj was involved!) elfprince13 wrote: I would much rather see something along the lines of either a (tuple-centric) comma-separated unpacking scheme... (That was the idea. I've seen "(a,b,c).each" in other languages and thought "each(a,b,c)" was cleaner) elfprince13 wrote: ... unless it is very clear that what you want to do can't be done without it It was just a way to abolish the ugliness of chaining lists of arbitrary "sets" with blanks mixed in to make it work (a "fair trade"); but that's probably when single assignments are better anyway. It's totally doable without "each" (especially if I abolish list-assignments and require explicit tuples like "(a,b,c) = ..." or "<a,b,c> = ..." ... I will have more discussion on this later). elfprince13 wrote: Quote: I found it particularly useful have separate variables actually stored in an array... Keep in mind that this is a convenience (and I can think of places where I would use it in programs I've written), but it's also candy - if you can't do it right, don't do it at all. I don't think that presenting a great idea with unrefined syntax does not mean I can't do it right, just that I want to involve others in deciding on a good syntax (and hey, the {..., var=y, ...} scheme is not bad). elfprince13 wrote: ...but either of your suggestions don't translate easily from static declarations to dynamic ones. That is because they are static declarations: {var@"somewhere"} tells the compiler to literally use "somewhere" as the static address for the variable. Replacing "somewhere" with another variable has them share the same address statically rather than indirectly -- though I admit that targeting other variables was only really useful for picking a static address out of a (static) array (hence the push for just a composite declaration); otherwise a per-variable setup is cleaner/simpler... elfprince13 wrote: x,y,z = @a[0:3]. ...but I will admit that something like that would be nice to have. However, it's currently "byte a@b" instead of "byte a=@b", and "byte a@b = c" is allowed; but perhaps if I make it a choice between giving an initialization value or picking a static address, then we can debate syntax.

16 Mar 2012 02:17:31 pm by elfprince13		Quote
shkaboinka wrote: It was just a way to abolish the ugliness of chaining lists of arbitrary "sets" with blanks mixed in to make it work (a "fair trade"); but that's probably when single assignments are better anyway. It's totally doable without "each" (especially if I abolish list-assignments and require explicit tuples like "(a,b,c) = ..." or "<a,b,c> = ..." ... I will have more discussion on this later). I agree on both counts - as far as use cases and when to use single assignment, and that avoiding each is not only doable, but preferable. Quote: That is because they are static declarations: {var@"somewhere"} tells the compiler to literally use "somewhere" as the static address for the variable. Replacing "somewhere" with another variable has them share the same address statically rather than indirectly -- though I admit that targeting other variables was only really useful for picking a static address out of a (static) array (hence the push for just a composite declaration); otherwise a per-variable setup is cleaner/simpler... If you can't do it dynamically it seems quite like a very odd language feature. Static aliasing isn't any different than a less powerful version of #define macros in C/C++. On the other hand dynamically, I thought it was kind of a neat syntax to make pointers a little more intuitive. Quote: but I will admit that something like that would be nice to have. However, it's currently "byte a@b" instead of "byte a=@b", and "byte a@b = c" is allowed; but perhaps if I make it a choice between giving an initialization value or picking a static address, then we can debate syntax. Then why not (x,y)@a[1:3] or a={0,x@1,y@2,3}?

16 Mar 2012 03:38:32 pm by shkaboinka		Quote
elfprince13 wrote: If you can't do it dynamically it seems quite like a very odd language feature. Static aliasing isn't any different than a less powerful version of #define macros in C/C++. On the other hand dynamically, I thought it was kind of a neat syntax to make pointers a little more intuitive. Sorry about that. No, I don't hide pointers; but the compiler will insert dereferences/addresses to make the RHS suitable for the LHS (e.g. "ptr = nonptr" will convert to "ptr = &nonptr", which makes "by reference" arguments easier) ... see the overview). When I tried providing macros in Antidisassemblage, I came to the conclusion that they cause more problems than they solve. Instead, the compiler uses data-flow analysis to trace values and predetermine as much as possible; but you can also use the $ operator require this (i.e it's an error if it cannot, and it's a hint to be more vigorous -- e.g. "interpreted" loops are unwound without question). Thus, full-fledged functions/variables/constructs can be used as "smart" macros (static checks on everything versus blindly inserting code which can be misused). You'd think that would void the need for any kind of static aliasing (and in most cases, yes); but the "@" is just necessary to attach variables (and functions, etc.) to explicit addresses, so as to (for example) attach a name to where the TIOS's stores the cursor position, and use it directly as a variable! This is a large motivation for the underlying structure of things to be as close to machine representation as possible (so that you can map directly to arrays, routines/precompiled-functions, or even structs designed to match an external storage format). ... So I could technically just forget about aliasing to array indexes, since the compiler will circumvent pointer-dereferencing if it can tell what something is pointing to and just use that directly (unless it is marked as "volatile"); but I figured that if I have @"asmAddress" then I might as well allow @otherVar, and in turn @arr[idx] -- so that you don't have to code the pointers and dereferences (well, a lot of them anyway) and rely on circumvention as an just optimization ...though perhaps a $ variable would require it by definition... elfprince13 wrote: Then why not (x,y)@a[1:3] or a={0,x@1,y@2,3}? That second one (a={0,x@1,y@2,3}) is one of the options I suggested initially, so your suggestion (and response to how it fits the context better) makes me lean toward it. As for the first part, I like the semantics of it, but I am still debating about how tuples might mix into variable declarations (if at all), so how about this: - Allow (a={0,x@1,y@2,3}), so that large lists of values can be mapped directly into arrays. - Allow a[1:3] as to grab a tuple out of an array (as a shorthand; it would be exactly equivalent to (a[1],a[2])) - If we treat a tuple as "one thing" (this paradigm essentially removes lists from assignments, etc.), then we could go off of the current syntax for declaring individual variables: Code: // If tuples were allowed in variable declarations: byte (a,b)@(x,y) = (1,2); byte (a=1, b=2)@(x,y); byte (a@x, b@y) = (1,2); byte a@x=1, b@y=2; // <-- This is standard (e.g. not relating to tuples) // (Of course, any "(1,2)" can be replaced with "array[n:n+2]")

New Post	New Topic
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 18, 19, 20  Next