mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#233674 03/09/11 01:51 AM
Joined: Apr 2011
Posts: 14
O
Onions Offline OP
Pikka bird
OP Offline
Pikka bird
O
Joined: Apr 2011
Posts: 14
mIRC Supporting the use of arrays would make several scripts tons easier to do, instead of having to do long things with $gettok or however you script around it.

Onions #233675 03/09/11 03:58 AM
Joined: Jul 2011
Posts: 5
G
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
G
Joined: Jul 2011
Posts: 5
And what would the syntax be?

Onions #233676 03/09/11 04:00 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
mIRC supports arrays, use hash tables. The API would be the same anyway, in that the only sane syntax would be to have some kind of $array(name,index) identifier, which is equivalent to $hget(name,index)


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233677 03/09/11 11:26 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Arrays and hash tables aren't equivalent, for reasons we've been over before. I would like to see arrays in mIRC.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
starbucks_mafia #233686 04/09/11 04:05 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Yes, this was discussed before. The fact remains that most users aren't concerned about the efficiency differences in deleting items in an Array, and access is nearly equivalent. Finally, if the minor API differences are really that scary, it's trivial to wrap the /hadd and $hget identifiers into a /array and $array combo which hides all of the "confusing" hash specific functionality.

Just to be clear, arrays and hash tables might not be theoretically equivalent, but a few very popular languages do fine without array implementations. I'm speaking of course about Javascript and PHP, which both implement "arrays" through associative arrays (or hash tables). For all intents and purposes, they are equivalent in the practical sense for a huge population of real world programmers and code. Practical and historical evidence suggests that using an associative array as a "true" indexed array is virtually indistinguishable to the programmer and at least functionally equivalent, so maybe we should drop the theoretics in the argument and focus on practical benefits.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233689 05/09/11 01:33 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
The fact remains that most users aren't concerned about the efficiency differences in deleting items in an Array

You're basing that on what exactly? That's insane. The inefficiency of using hash tables that way is ridiculous.

Quote:
if the minor API differences are really that scary, it's trivial to wrap the /hadd and $hget identifiers into a /array and $array combo which hides all of the "confusing" hash specific functionality.

They're two fundamentally different concepts. It isn't a "minor API difference". It isn't just "hash specific" functionality, there'd also be "array specific functionality", because the two things only marginally overlap which is why it's stupid to try and combine the two at all.

Quote:
a few very popular languages do fine without array implementations. I'm speaking of course about Javascript and PHP

PHP's conflagration of lists and mappings into a single "array" is one of the major flaws in the language. And Javascript has (mostly) proper arrays. The associative array behaviour available in Javascript is inherent to all objects as another means of accessing their properties. The consequences of that lead to some of the most broken parts of the language (eg. being unable to prototype new Array methods because they'll appear as items on any for loops).


Spelling mistakes, grammatical errors, and stupid comments are intentional.
starbucks_mafia #233690 05/09/11 04:20 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: starbucks_mafia
You're basing that on what exactly? That's insane. The inefficiency of using hash tables that way is ridiculous.


Immutable data structures are common. Would you be opposed to immutable arrays in mIRC? If you treat them as such, the structures themselves are fine. In any case, the "inefficiency" of using hash tables is not due to the hash tables themselves, but mIRC's god awful parsing slowness. That's not really an issue with using associative arrays. Adding extra syntaxes to get around flaws in the language isn't a good solution, it's just a workaround. There's nothing fundamentally wrong with using associative arrays themselves, so it's misleading to claim that the inefficiency is in the hash table-- it's not. There are things mIRC could do instead to optimize these slow points without adding in new syntaxes.

Originally Posted By: starbucks_mafia
They're two fundamentally different concepts.


This is another pointless computer science theoretics discussion, and quite wrong. The fact is that "associative arrays" are a generalization of indexed arrays, conceptually speaking. An associative array is a collection of objects in a mapping of one key to a value, usually in a one to one relationship. An indexed array is just a subset of an associative array whereby the keys are all indexed positive integer values. This is why the two types of arrays map so seamlessly together in languages like PHP/JS. There is no fundamental difference, except for the key type restriction in indexed arrays. All of the operations on associative arrays carry over for indexed ones, the only difference being that insertion/deletion involve changing other keys. I don't consider that "fundamentally" different.

But that's all besides the point-- I'm not interested in the theory. The fact that you can trivially create an array API based on hget/hadd (and even hdel, though we agree it's inefficient) proves that the APIs have minor differences. Here it is, for immutable(ish) arrays:

Code:
; Add a value to an array
alias aadd { hadd -m $+(array,$1) $calc($hget($+(array,$1),0) + 1) $2- }
; Get a value from an array
alias aget { return $hget($+(array,$1),$2) }

; USAGE:
; //aadd myarray foo | aadd myarray bar
; //echo -a $aget(myarray,1) == foo
; //echo -a $aget(myarray,2) == bar


Seems like a rather trivial API difference to me. Again, insertion/deletion could be wrapped in a similarly trivial way, with the efficiency caveats, of course.

Originally Posted By: starbucks_mafia
PHP's conflagration of lists and mappings into a single "array" is one of the major flaws in the language. And Javascript has (mostly) proper arrays.


This double standard doesn't actually make sense. Javascript and PHP share the exact same API and conceptual implementation of the "array". If PHP is "flawed" because of this decision, then so must Javascript be. In any case, this is a hugely subjective debate-- many would argue that it's one of PHP's most powerful features-- this same API is certainly one of JS's most powerful features. The efficiency might vary between the two implementations, but that is an implementation detail, not a conceptual one, and we're not here to discuss implementation details. How can assoc arrays be a flaw in one language but a "mostly ok" feature in another, conceptually? I think associative arrays make plenty of sense in a high level weakly typed scripting language like JS, PHP and even mIRC. Conceptually speaking, using hash tables as the associative arrays of the other languages makes perfect sense. I've used them in mIRC with little issue many times before.

Just FYI, mIRC could always optimize a hash table for insertion/deletion if a switch was supplied during creation. This is why I had previously suggested the -i switch in the thread you linked, to tell mIRC to optimize the keys as indexed integer values. Using such a switch, mIRC could collapse/shift indexes during insertion/deletion-- or even just store the internal structure as a pure array for super-duper-efficiency, if Khaled wanted. This would give you the power of associative arrays in one single interface that scripters are already used to, rather than splitting it up into an API to manipulate associative arrays with indexed integers and associative arrays for anything else. I think a unified interface would be easier.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233696 05/09/11 08:49 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
No. Just... no.

Last edited by starbucks_mafia; 05/09/11 09:01 PM.

Spelling mistakes, grammatical errors, and stupid comments are intentional.
argv0 #233723 06/09/11 09:16 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
No matter how many optimisations Khaled makes to the scripting language, a built-in array implementation is going to be far superior to any possible scripted alternative in terms of speed. It will also mean that scripts which use array functionality will be more portable; you can copy/paste a small script rather than having to provide the entire scripted array implementation along with it.

I'm not sure why you're so against this feature being added. mIRC has no built-in sorted data type; we have to script our own using the, in your own words, "god awful parsing slowness" of mIRC (with hash tables).

I haven't seen a good reason from you against arrays being implemented. Note: the fact that they can be scripted is not a good reason.

hixxy #233749 08/09/11 03:51 PM
Joined: Jul 2006
Posts: 4,180
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,180
That's because he isn't against array implementation, he is only discussing the syntax.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #233751 08/09/11 08:54 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Wims
That's because he isn't against array implementation, he is only discussing the syntax.


Two of his posts in this thread:

Originally Posted By: argv0
mIRC supports arrays, use hash tables. The API would be the same anyway, in that the only sane syntax would be to have some kind of $array(name,index) identifier, which is equivalent to $hget(name,index)


Originally Posted By: argv0
Yes, this was discussed before. The fact remains that most users aren't concerned about the efficiency differences in deleting items in an Array, and access is nearly equivalent. Finally, if the minor API differences are really that scary, it's trivial to wrap the /hadd and $hget identifiers into a /array and $array combo which hides all of the "confusing" hash specific functionality.

Just to be clear, arrays and hash tables might not be theoretically equivalent, but a few very popular languages do fine without array implementations. I'm speaking of course about Javascript and PHP, which both implement "arrays" through associative arrays (or hash tables). For all intents and purposes, they are equivalent in the practical sense for a huge population of real world programmers and code. Practical and historical evidence suggests that using an associative array as a "true" indexed array is virtually indistinguishable to the programmer and at least functionally equivalent, so maybe we should drop the theoretics in the argument and focus on practical benefits.


These seem to be arguing against their implementation by suggesting that existing features suffice, when they're not the same in my opinion.

hixxy #233753 08/09/11 11:03 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I am quite simply arguing that associative arrays can and do successfully abstract indexed arrays in other languages, and can therefore be implemented in the same fashion in mIRC, ie., without changing any external script APIs / syntax (well, with no major syntax adjustments anyway).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233755 09/09/11 12:13 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Nobody ever suggested syntax changes; merely appropriate identifiers and commands to access an array structure.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
starbucks_mafia #233757 09/09/11 01:40 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Right, but I'm also saying that the API shouldn't need to change either (as it also isn't necessary in other languages to support both arrays and hash tables in one unified API).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233758 09/09/11 02:23 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
One language made the mistake of believing that indexed arrays and associated arrays are the same. Javascript does not; the array-like syntax for accessing properties in Javascript is not in any way affecting an actual array. And versus that one language there are a thousand that realize you shouldn't put your apples and oranges in a single structure. PHP's associative arrays aren't the same as mIRC's hash tables anyway, for one thing they're sorted. Not that makes the design any less flawed...

In any case, the simple fact is that arrays and hash tables are not the same, so trying to shoehorn them into using the same commands and identifiers is ridiculous.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
starbucks_mafia #233759 09/09/11 10:31 AM
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
As for syntax:
Code:
/amake <aname> <1dem 2dem ... nDem>
/aset -i<dem1[,dem2,demN]> <aname> <value>
/aset <aname> {{value,value,value},{value,value,value},....}

/echo -a $aget(name,dem1,dem2,....)


Plus the add, remove, freeing, etc commands

Last edited by FroggieDaFrog; 09/09/11 10:32 AM.

I am SReject
My Stuff
FroggieDaFrog #233762 09/09/11 01:39 PM
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Although we are used to using {}'s with arrays, I don't think that's a good idea in mIRC because {}'s have their own meaning and I think it could become a problem if we use them for arrays. I'd stick with just ()'s like any other command. It would be fairly easy to parse the following without needing to use {}'s.

Code:
/aset <aname> ((value,value,value),(value,value,value),....)


Or ;'s can be used between them (with or without the ()'s as shown above)...

Code:
/aset <aname> (value,value,value;value,value,value;....)


I just think it will be better overall to avoid trying to use {}'s for this when it will require a lot of changes (I believe) to the parser to know how to properly treat them and when to change indenting.


Invision Support
#Invision on irc.irchighway.net
FroggieDaFrog #233764 09/09/11 06:06 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Does -i insert at an index (and therefore shift)? Or does it just set the element at the index. This is a fairly important distinction.

Also how would you shift indexes on a multi dimensional array? Which indexes shift? Note that if multi-dimensional arrays don't shift then you can just use hashes for multi-dimensional structures and simplify array commands to single dimension lists only-- drastically simplifying, at that.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233765 09/09/11 09:00 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Fair enough.

I don't really care about the implementation, would just like the feature.

It doesn't really make a difference if we have to use:

Code:
amake blah 100
aadd blah one
aadd blah two
aadd blah fourty three thousand


Or:

Code:
hmake -i blah 100
hadd blah one
hadd blah two
hadd blah fourty three thousand


Does it?

hixxy #233766 09/09/11 10:39 PM
Joined: Jul 2007
Posts: 1,129
T
Hoopy frood
Offline
Hoopy frood
T
Joined: Jul 2007
Posts: 1,129
hixxy, what does the -i switch stand for with the hmake?

Page 1 of 2 1 2

Link Copied to Clipboard