Type-Casting Lists and Procedures

Page: 1 2
ID:134807
 
Aug 30 2005, 8:30 am (Edited on Aug 30 2005, 9:49 am)
This suggestion is about assigning array types to lists, and return types to procedures. I've taken a look at the DM language, and it appears that it was already half-implemented, and then abandoned. I'll explain more as I go on.

As for assigning array types, it would be as simple as defining the list:
var/list/mob/players

Try putting that in Dream Maker, a line to access the variable, and compiling. It compiles without an "undefined type" error! Also, try declaring a new prototype, derived from /list. It doesn't let you! Apparently, the idea was already conjured, and partially implemented.

Now let's talk about procedure definition.
proc/list/turf/GetSpawnTurf()

Oh, look! It compiles perfectly again! One thing I noticed, is that if you have a code-less procedures defined like this:
proc
    list/DeadPeople()

You'll get an "invalid proc definition" error, but never fear! The compiler is young, and a little confused. You can explicitly tell it where the procedure starts and ends be adding a couple braces, as so:
proc
    list/DeadPeople(){}

Compiles just right. That only seems to happen if the procedure is on a line after it's "proc" keyword.

When I was new the DM language, I've always type-casted list variables like that. Don't ask why, I just thought that was the way it SHOULD be done, back then. Here are some more examples of type casting:
var/list/list/job/jobMatrix = list(...) // Multi-dimentional!

mob/var/list/job/jobs = list()

job/proc
    job/NewEmployee() return new/job

proc
    list/mob/GetMobList() {...}

    GenericProcName()
        global.GetMobList()[1].jobs[1] = global.jobMatrix[2][4].NewEmlpoyee()
          // That is scary, but it makes sense.

        world.status = "Players: [global.GetMobList().len]"
          // There's a simpler example.
Aug 30 2005, 9:36 am
Yota wrote:
This suggestion is about assigning array types to lists, and return types to procedures. I've taken a look at the DM language, and it appears that it was already half-implemented, and then abandoned. I'll explain more as I go on.

As for assigning array types, it would be as simple as defining the list:
var/list/mob/players

Try putting that in Dream Maker, a line to access the variable, and compiling. It compiles without an "undefined type" error! Also, try declaring a new prototype, derived from /list. It doesn't let you! Apparently, the idea was already conjured, and partially implemented.

I don't think the idea was partially implemented, rather that DM is not correctly giving you the error it should for that situation.

Adding list typing is a fruitless endeavor for reasons already discussed multiple times (the forum search is your friend).

Assigning a return type to procs is only slightly less inane. It sounds like a good idea until you realize there's nothing you can do with the type, for one of the same reasons it's daft to type a list. The : operator would be ambiguous if it was allowable to access a list item's or proc result's vars/procs directly.

Lummox JR
Aug 30 2005, 9:45 am (Edited on Aug 30 2005, 9:57 am)
In response to Lummox JR
It's better to allocate more memory, and clutter code with countless ambiguous variable names, than to assign return types to procedures?

Not only would it make the processing more effecient, it can serve a good reminder as to what a procedure returns in libraries. (And don't say comments.) You mine as well scrap the type casting of variables.

While on the subject, have you started the petition to remove the ability to assign return types to functions and properties in all the major programming languages? Sheesh. I couldn't even imagine C# without it.

At least, could we have a way to explicity convert a type when used? (Even though this only effects the compiler.)
((/datum)myList[1]).tag = null


Edit: I just remembered another use, accessing members directly from a constructor.
new/datum().AnotherGenericName()
((/datum)new pathVar).AnotherGenericName()
Aug 30 2005, 1:36 pm
In response to Yota
I wrote up a proposal for this sort of behavior a while ago, it can be found here: http://developer.byond.com/forum/ index.cgi?action=message_read&id=328043&forum=1&view=1#32804 3

I feel that this sort of functionality (I prefere the form I suggested, though... yours looks a bit odd to me :/ ) would be very beneficial to the developer community.
Aug 30 2005, 3:18 pm
In response to IainPeregrine
IainPeregrine wrote:
I wrote up a proposal for this sort of behavior a while ago, it can be found here: http://developer.byond.com/forum/ index.cgi?action=message_read&id=328043&forum=1&view=1#32804 3

When linking to a post, you can just use ID: followed by the number: [link] And voila! It magically links to your post.

Hiead
Aug 30 2005, 4:54 pm
In response to IainPeregrine
IainPeregrine wrote:
I feel that this sort of functionality (I prefere the form I suggested, though... yours looks a bit odd to me :/ ) would be very beneficial to the developer community.

I agree, though I have the reverse opinion; Yota's proposal (which is identical to what I proposed back in your thread) looks a lot cleaner to me.
Aug 30 2005, 5:17 pm
In response to Lummox JR
Lummox JR wrote:
Adding list typing is a fruitless endeavor for reasons already discussed multiple times (the forum search is your friend).

I've tried searching, and I can't find any such discussions. Could you point us in the right direction? =)

Assigning a return type to procs is only slightly less inane. It sounds like a good idea until you realize there's nothing you can do with the type, for one of the same reasons it's daft to type a list. The : operator would be ambiguous if it was allowable to access a list item's or proc result's vars/procs directly.

How would this make : ambiguous? I'm confused.
Aug 30 2005, 8:09 pm
In response to Crispy
Because "/" is a path operator, your method suggests that these two code blocks are equivilent:
mob/proc
    obj/item/GetOneOfMyItems()
        dostuff()
    obj/projectile/snatchy()
        dostuff()
    mob/monster/makepet()
        dostuff()


mob
    proc
        obj
            item
                GetOneOfMyItems()
                    dostuff()
            projectile
                snatchy()
                    dostuff()
        mob
            monster
                makepet()
                dostuff()


It seems to me that the obfustication of subtyping procs and lists should be avoided like the plague. A simple 'set' notation, as already implemented for other function attributes, would keep the system simple. Imagin trying to explain either of the above examples to a user in the code problems forum. Now imagin the ease with which you could explain the following:
mob
    proc
        GetOneOfMyItems()
            set value = /obj/item
            dostuff()
        snatchy()
            set value = /obj/projectile
            dostuff()
        makepet()
            set value = /mob/monster
            dostuff()
Aug 31 2005, 6:20 am
In response to IainPeregrine
IainPeregrine wrote:
Because "/" is a path operator, your method suggests that these two code blocks are equivilent:
> mob/proc
>     obj/item/GetOneOfMyItems()
>         dostuff()
>     obj/projectile/snatchy()
>         dostuff()
>     mob/monster/makepet()
>         dostuff()
>


> mob
>     proc
>         obj
>             item
>                 GetOneOfMyItems()
>                     dostuff()
>             projectile
>                 snatchy()
>                     dostuff()
>         mob
>             monster
>                 makepet()
>                 dostuff()
>


They are equivilent. Well, except for the very last line, where you're missing a tab.

var/obj
    var1
    var2
// Works the same with procedures. (Because they ARE type paths.)
proc/obj
    proc1(){}
    proc2(){}
Aug 31 2005, 8:33 am
In response to Crispy
Crispy wrote:
Lummox JR wrote:
Adding list typing is a fruitless endeavor for reasons already discussed multiple times (the forum search is your friend).

I've tried searching, and I can't find any such discussions. Could you point us in the right direction? =)

One such is here: [link]

Assigning a return type to procs is only slightly less inane. It sounds like a good idea until you realize there's nothing you can do with the type, for one of the same reasons it's daft to type a list. The : operator would be ambiguous if it was allowable to access a list item's or proc result's vars/procs directly.

How would this make : ambiguous? I'm confused.

The : operator has 3 uses: For type paths, for member access, and as part of the ?: ternary operator. In current behavior, DM knows that following a closing bracket or parenthesis, the : operator will not be used for member access. (This is unlike in C, but then again C has no : member access operator.) Changing this would break large swaths of existing code, and there'd be little or no way to prevent ambiguity between member access and the ?: operator.

Lummox JR
Aug 31 2005, 8:44 am
In response to Yota
Yota wrote:
It's better to allocate more memory, and clutter code with countless ambiguous variable names, than to assign return types to procedures?

You miss the point. DM is fundamentally incapable of this sort of change. I'm well aware of the difficulties involved because I looked into it way before the more recent forum discussions.

While you could easily find ways to give a proc a return type, and implementing that might not be such a big deal, the problem is there's no way to use that return type directly, thus eliminating any need to have it. To give a return type to a proc you'd basically have to be able to do this:

ClosestEnemy().target


While the . operator could theoretically be rewritten that way, it would have a couple of snags. One is that we can't afford to break existing code which defines a proc thus:

sqr(i).=i*i


I could easily see the parser having difficulty sorting out the two cases, although it's doable. Another problem is that the : operator could never be made to handle member access directly in this fashion, because it would be ambiguous and would break a great deal of existing code. A : following a closing parenthesis or bracket is interpreted as never being a member access operator, which makes it possible to distinguish that from the ternary ?: and the : path operator, although the : path operator should never occur in such places.

Not only would it make the processing more effecient, it can serve a good reminder as to what a procedure returns in libraries. (And don't say comments.) You mine as well scrap the type casting of variables.

This would only be useful, as I mentioned, for cases where it's important to access members of the result directly. In most cases it's still more desirable to get the result in a var and use it more than once.

While on the subject, have you started the petition to remove the ability to assign return types to functions and properties in all the major programming languages? Sheesh. I couldn't even imagine C# without it.

Again you miss the point about design. Those languages were designed with such features inherent. Most of them are also strongly typed, which DM is not. None of them have an equivalent to : member access, and in any case removing return types would be stupid because it'd be removing a major feature that's already there. That's a far cry from trying to force-fit such a feature into a language that was designed with a completely different approach to types. This question is wholly ridiculous.

At least, could we have a way to explicity convert a type when used? (Even though this only effects the compiler.)
((/datum)myList[1]).tag = null


Again probably not, because reworking the . and : operators to work following a set of parentheses or brackets--which they currently don't--would force them to diverge. The : operator could not handle the change, although the . operator can.

Lummox JR
Aug 31 2005, 9:01 am
In response to Lummox JR
Lummox JR wrote:
While the . operator could theoretically be rewritten that way, it would have a couple of snags. One is that we can't afford to break existing code which defines a proc thus:

sqr(i).=i*i


The compiler can already tell the difference between declaration, and script. Why wouldn't it notice that to be code within the procedure?
proc/a() b() c()  // error: c: expected end of statement

proc/a() b()      // error: proc definition not allowed inside another proc
    c()


Lummox JR wrote:
Yota wrote:
((/datum)myList[1]).tag = null

Again probably not, because reworking the . and : operators to work following a set of parentheses or brackets--which they currently don't--would force them to diverge. The : operator could not handle the change, although the . operator can.

I wouldn't really expect an implicit operator such as : to be used after an explicit casting. As for the inline-if, there must be some way for the compiler to get wise. (TRUE ? x():var1:var2 : x():varA:varB) is pretty confusing.

I've been hoping there will be a language (and in this case, grammar) revamp for 4.x DMBs, and if there is, perhapse DM could become a strong-typed language.
Aug 31 2005, 9:39 am
In response to Yota
Woah, this one almost flew right by me.

TRUE ? typelessVar:member : FALSE


How come that is recognized correctly? Could it be because the compiler notices the whitespace after "member?" Why couldn't it do the same when using procedures?

The only problem now is that it recognizes (TRUE ? x():usr:loc) as (TRUE ? x() : (usr:loc)).
Aug 31 2005, 11:11 am
In response to Yota
Yota wrote:
Woah, this one almost flew right by me.

TRUE ? typelessVar:member : FALSE

How come that is recognized correctly? Could it be because the compiler notices the whitespace after "member?"

Aye.

Why couldn't it do the same when using procedures?

Because existing code already has cases where : follows a closing bracket or parenthesis without such a space.

The only problem now is that it recognizes (TRUE ? x():usr:loc) as (TRUE ? x() : (usr:loc)).

And that can never change.

Lummox JR
Aug 31 2005, 11:12 am
In response to Yota
Yota wrote:
I've been hoping there will be a language (and in this case, grammar) revamp for 4.x DMBs, and if there is, perhapse DM could become a strong-typed language.

That will never happen.

Lummox JR
Aug 31 2005, 12:16 pm
In response to Lummox JR
Lummox JR wrote:
Yota wrote:
I've been hoping there will be a language (and in this case, grammar) revamp for 4.x DMBs, and if there is, perhapse DM could become a strong-typed language.

That will never happen.

Lummox JR

Language or grammar? The language will have to be changed if the client's Dream Seeker interface can be altered. For example, I was thinking a client list of /eye datums for each map, and another list for each label, browser, text, stat/verbpanel, etc.
Aug 31 2005, 7:40 pm
In response to Yota
Yota wrote:
Language or grammar?

I suspect he meant this bit: "perhaps DM could become a strong-typed language." And I have to agree with him, I don't see that happening. So much stuff would have to be changed; and in any case, I don't particularly want DM to be a strongly-typed language. =) Weak typing can be quite useful.

Lummox - I see your point about the ternary operator, which was something I hadn't thought of. However, as use of : is discouraged anyway, why not let only the . operator behave like this (at least for procs)? It doesn't have any other meaning except for member access. Sure, having one member access operator be able to operate directly on return values and one unable to would be somewhat inconsistent, but surely that's not a terrible problem.

I'm not saying it'd be easy, and I don't expect that it will ever happen, but I still think it's possible in some form. Theoretically. =)
Aug 31 2005, 7:42 pm
In response to IainPeregrine
IainPeregrine wrote:
It seems to me that the obfustication of subtyping procs and lists should be avoided like the plague. [...] Imagin trying to explain either of the above examples to a user in the code problems forum.

I don't see it as an obsfuscation - it's very easy to understand and explain. The type to the left is the type the proc belongs to; the type to the right is the one it returns. What's so hard about that?
Aug 31 2005, 7:43 pm
In response to Yota
Yota wrote:
Lummox JR wrote:
Yota wrote:
I've been hoping there will be a language (and in this case, grammar) revamp for 4.x DMBs, and if there is, perhapse DM could become a strong-typed language.

That will never happen.

Language or grammar? The language will have to be changed if the client's Dream Seeker interface can be altered. For example, I was thinking a client list of /eye datums for each map, and another list for each label, browser, text, stat/verbpanel, etc.

What you're describing is all interface stuff, though, which is different from totally changing the structure of the DM language. The idea that DM could go from loosely typed to strongly typed is well past ridiculous; it would break almost all existing code. It's like saying Perl would be great if it was only C.

The new interface elements in 4.0 will be based in .dms files, and to my knowledge will not be associated with any datums.

Lummox JR
Sep 1 2005, 6:46 am
In response to Crispy
Crispy wrote:
Lummox - I see your point about the ternary operator, which was something I hadn't thought of. However, as use of : is discouraged anyway, why not let only the . operator behave like this (at least for procs)? It doesn't have any other meaning except for member access. Sure, having one member access operator be able to operate directly on return values and one unable to would be somewhat inconsistent, but surely that's not a terrible problem.

I don't think letting the . and : access operators diverge in this manner is particularly wise, but otherwise I agree it would be a nice thing to be able to do this.

Still, list typing would more or less make lists strongly typed, which is a bad idea. I can definitely see this for procs, not so much for lists.

Lummox JR
Page: 1 2