View topic - Remove MAX_TOKENS limit for array and object declarations • AutoHotkey Community

View unanswered posts | View active topics

Board index » AutoHotkey » Suggestions

All times are UTC [ DST ]

Remove MAX_TOKENS limit for array and object declarations

Page 1 of 1

[ 13 posts ]

Print view | E-mail friend

Previous topic | Next topic

Author

Message

just me

Post subject: Remove MAX_TOKENS limit for array and object declarations

Posted: August 14th, 2011, 7:49 am

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

Look at this thread, please.

Top

Lexikos

Post subject:

Posted: August 14th, 2011, 8:39 am

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

The current limit is also used as the total capacity of the expression evaluation stack. Removing the limit (by making it dynamic) would probably reduce performance and increase code size. Increasing the limit would increase stack memory usage (especially for recursive functions), which would also reduce the maximum number of recursive calls any function can make. (Do you see where I'm going with this?)

Top

just me

Post subject:

Posted: August 14th, 2011, 9:19 am

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

That's why I say "for array and object declarations". This

Code:

   Static H := ["00","01","02","03","04","05","06","07","08","09","0A","0B","0C","0D","0E","0F"
               ,"10","11","12","13","14","15","16","17","18","19","1A","1B","1C","1D","1E","1F"
               ,"20","21","22","23","24","25","26","27","28","29","2A","2B","2C","2D","2E","2F"
               ,"30","31","32","33","34","35","36","37","38","39","3A","3B","3C","3D","3E","3F"
               ,"40","41","42","43","44","45","46","47","48","49","4A","4B","4C","4D","4E","4F"
               ,"50","51","52","53","54","55","56","57","58","59","5A","5B","5C","5D","5E","5F"
               ,"60","61","62","63","64","65","66","67","68","69","6A","6B","6C","6D","6E","6F"
               ,"70","71","72","73","74","75","76","77","78","79","7A","7B","7C","7D","7E","7F"
               ,"80","81","82","83","84","85","86","87","88","89","8A","8B","8C","8D","8E","8F"
               ,"90","91","92","93","94","95","96","97","98","99","9A","9B","9C","9D","9E","9F"
               ,"A0","A1","A2","A3","A4","A5","A6","A7","A8","A9","AA","AB","AC","AD","AE","AF"
               ,"B0","B1","B2","B3","B4","B5","B6","B7","B8","B9","BA","BB","BC","BD","BE","BF"
               ,"C0","C1","C2","C3","C4","C5","C6","C7","C8","C9","CA","CB","CC","CD","CE","CF"
               ,"D0","D1","D2","D3","D4","D5","D6","D7","D8","D9","DA","DB","DC","DD","DE","DF"
               ,"E0","E1","E2","E3","E4","E5","E6","E7","E8","E9","EA","EB","EC","ED","EE","EF"
               ,"F0","F1","F2","F3","F4","F5","F6","F7","F8","F9","FA","FB","FC","FD","FE","FF"]

looks like an expression, but (for me) it is syntax. Commas are field delimiters, not operators, and my simple mind does not recognize, why expression evaluation is used in this case treating the whole as one expression. But I also don't know the cost of change.

Edit: I'd guess the limit will apply to "expressional" continuation sections in v2 too?

Top

Lexikos

Post subject:

Posted: August 14th, 2011, 11:52 am

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

Quote:

Commas are field delimiters, not operands

Regardless of what you perceive a comma to be, the script loader represents it at some stage using a token, which takes up one slot in the infix (token) array and therefore contributes to the MAX_TOKENS limit. Opening and closing parentheses also use one token each at this stage.

Quote:

looks like an expression, but (for me) it is syntax.

That statement makes little sense. For your script to work, your script source code must follow a set of rules which allow AutoHotkey to convert it into a sequence of actions to be carried out. That set of rules is called syntax. More specifically, anything to the right of Static H := is an expression; the source code of your expression is interpreted according to expression syntax.

Quote:

Edit: I'd guess the limit will apply to "expressional" continuation sections in v2 too?

Take a continuation section:

Code:

sum :=
(Join+
a
b
)

Now do the following:

Put the join delimiter "+" at the end of each line inside the continuation section, except the last.
Delete the line "(Join+".
Delete the line ")".
Delete the line endings preceding "a" and "b".

That should leave you with:

Code:

sum :=a+b

That's basically what the script loader does before parsing the expression. So yes, the limit applies to expressions which are written using a continuation section just as much as it applies to every other expression.

Top

just me

Post subject:

Posted: August 14th, 2011, 9:07 pm

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

Quote:

Regardless of what you perceive a comma to be, the script loader represents it at some stage using a token, which takes up one slot in the infix (token) array and therefore contributes to the MAX_TOKENS limit.

And that's what I want to be changed for declarations, because it makes no sense in this context.

Would you please confirm, that

Code:

X := [...] ; and
X := {...}

are not assingnments but functions. And if you think, that's the best way to be implemented, I will accept this ugly alternate "other way to write my script".

Sorry, master!

Top

Lexikos

Post subject:

Posted: August 14th, 2011, 10:35 pm

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

just me wrote:

And that's what I want to be changed for declarations, because it makes no sense in this context.

There's no way to evaluate an expression without passing it through the expression evaluator. Expressions to the right of declarations will continue to be subject to the same limitations as all other expressions.

Quote:

are not assingnments but functions.

That's absurd. Of course they're assignments. Assignments which accept expressions.

Top

jethrow

Post subject:

Posted: August 15th, 2011, 4:15 am

Joined: May 24th, 2009, 5:35 am
Posts: 2099
Location: Iowa, USA

just me wrote:

... I will accept this ugly alternate "other way to write my script".

Actually, IMO, you're code may be cute, but it's a lot of quotes to type out compared to (AHK v2 anyways):

Code:

Static H := StrSplit("00,01,02,03,04,05 ...", ",")

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

Top

just me

Post subject:

Posted: August 22nd, 2011, 3:39 pm

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

jethrow wrote:

Code:

Static H := StrSplit("00,01,02,03,04,05 ...", ",")

Well, but will this initialize objects with pairs of keys and values also?

I guess, one pair needs 4 slots

Code:

Key   -> 1
:     -> 2
Value -> 3
,     -> 4

so we can initialize (511 // 4) keys. That is'nt a lot, is it?

Probably I think to simple, but I'd think that [...] and {...} could be first stored as a whole and then parsed for values or key/values in a second step. Such declarations are most likely used for constant contents. If we'd have a keyword for the declaration of constants, it would only need to be done this way at load time and shouldn't reduce run time performance.

Top

just me

Post subject:

Posted: August 28th, 2011, 11:30 am

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

Well, finally found an acceptable workaround for objects. It can be done using the class syntax:

Code:

Class WINTypes {  ; 149 key/value pairs
   Static ATOM := "USHORT"
   Static BOOL := "INT"
        , BOOLEAN := "UCHAR"
        , BYTE := "UCHAR"
   Static COLORREF := "UINT"
   Static DWORD32 := "UINT"
        , DWORD64 := "UINT64"
        , DWORD := "UINT"
        , DWORD_PTR := "UPTR"
        , DWORDLONG := "UINT64"
   Static HACCEL := "UPTR"
        , HALF_PTR := (A_PtrSize = 8 ? "INT" : "SHORT")
        , HANDLE := "UPTR"
        , HBITMAP := "UPTR"
        , HBRUSH := "UPTR"
        , HCOLORSPACE := "UPTR"
        , HCONV := "UPTR"
        , HCONVLIST := "UPTR"
        , HCURSOR := "UPTR"
        , HDC := "UPTR"
        , HDDEDATA := "UPTR"
        , HDESK := "UPTR"
        , HDROP := "UPTR"
        , HDWP := "UPTR"
        , HENHMETAFILE := "UPTR"
        , HFILE := "INT"
        , HFONT := "UPTR"
        , HGDIOBJ := "UPTR"
        , HGLOBAL := "UPTR"
        , HHOOK := "UPTR"
        , HICON := "UPTR"
        , HINSTANCE := "UPTR"
        , HKEY := "UPTR"
        , HKL := "UPTR"
        , HLOCAL := "UPTR"
        , HMENU := "UPTR"
        , HMETAFILE := "UPTR"
        , HMODULE := "UPTR"
        , HMONITOR := "UPTR"
        , HPALETTE := "UPTR"
        , HPEN := "UPTR"
        , HRESULT := "INT"
        , HRGN := "UPTR"
        , HRSRC := "UPTR"
        , HSZ := "UPTR"
        , HWINSTA := "UPTR"
        , HWND := "UPTR"
   Static INT32 := "INT"
        , INT_PTR := "PTR"
   Static LANGID := "USHORT"
        , LCID := "UINT"
        , LCTYPE := "UINT"
        , LGRPID := "UINT"
        , LONG32 := "INT"
        , LONG64 := "INT64"
        , LONG := "INT"
        , LONG_PTR := "PTR"
        , LONGLONG := "INT64"
        , LPARAM := "PTR"
        , LPBOOL := "UPTR"
        , LPBYTE := "UPTR"
        , LPCOLORREF := "UPTR"
        , LPCSTR := "UPTR"
        , LPCTSTR := "UPTR"
        , LPCVOID := "UPTR"
        , LPCWSTR := "UPTR"
        , LPDWORD := "UPTR"
        , LPHANDLE := "UPTR"
        , LPINT := "UPTR"
        , LPLONG := "UPTR"
        , LPSTR := "UPTR"
        , LPTSTR := "UPTR"
        , LPVOID := "UPTR"
        , LPWORD := "UPTR"
        , LPWSTR := "UPTR"
        , LRESULT := "PTR"
   Static PBOOL := "PTR"
        , PBOOLEAN := "PTR"
        , PBYTE := "PTR"
        , PCHAR := "PTR"
        , PCSTR := "PTR"
        , PCTSTR := "PTR"
        , PCWSTR := "PTR"
        , PDWORD32 := "PTR"
        , PDWORD64 := "PTR"
        , PDWORD := "PTR"
        , PDWORD_PTR := "PTR"
        , PDWORDLONG := "PTR"
        , PFLOAT := "PTR"
        , PHALF_PTR := "PTR"
        , PHANDLE := "UPTR"
        , PHKEY := "UPTR"
        , PINT32 := "UPTR"
        , PINT64 := "UPTR"
        , PINT := "UPTR"
        , PINT_PTR := "UPTR"
        , PLCID := "UPTR"
        , PLONG32 := "UPTR"
        , PLONG64 := "UPTR"
        , PLONG := "UPTR"
        , PLONG_PTR := "UPTR"
        , PLONGLONG := "UPTR"
        , POINTER_32 := "UINT"
        , POINTER_64 := "PTR"
        , POINTER_SIGNED := "PTR"
        , POINTER_UNSIGNED := "UPTR"
        , PSHORT := "UPTR"
        , PSIZE_T := "UPTR"
        , PSSIZE_T := "UPTR"
        , PSTR := "UPTR"
        , PTBYTE := "UPTR"
        , PTCHAR := "UPTR"
        , PTSTR := "UPTR"
        , PUCHAR := "UPTR"
        , PUHALF_PTR := "UPTR"
        , PUINT32 := "UPTR"
        , PUINT64 := "UPTR"
        , PUINT := "UPTR"
        , PUINT_PTR := "UPTR"
        , PULONG32 := "UPTR"
        , PULONG64 := "UPTR"
        , PULONG := "UPTR"
        , PULONG_PTR := "UPTR"
        , PULONGLONG := "UPTR"
        , PUSHORT := "UPTR"
        , PVOID := "UPTR"
        , PWCHAR := "UPTR"
        , PWORD := "UPTR"
        , PWSTR := "UPTR"
   Static SC_HANDLE := "UPTR"
        , SC_LOCK := "UPTR"
        , SERVICE_STATUS_HANDLE := "UPTR"
        , SIZE_T := "UPTR"
        , SSIZE_T := "PTR"
   Static TBYTE := (A_ISUNICODE ? "USHORT" : "UCHAR")
        , TCHAR := (A_ISUNICODE ? "USHORT" : "UCHAR")
   Static UHALF_PTR := (A_PtrSize = 8 ? "UINT" : "USHORT")
        , UINT32 := "UINT"
        , UINT_PTR := "UPTR"
        , ULONG32 := "UINT"
        , ULONG64 := "UINT64"
        , ULONG := "UINT"
        , ULONG_PTR := "UPTR"
        , ULONGLONG := "UINT64"
        , USN := "INT64"
   Static VOID := "PTR"
   Static WCHAR := "USHORT"
        , WORD := "USHORT"
        , WPARAM := "UPTR"
}

But that's not feasible for arrays.

Top

Lexikos

Post subject:

Posted: August 28th, 2011, 11:51 am

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

No?

Code:

SomeArray.Remove("__Class") ; Heh.
for k,v in SomeArray
    MsgBox % v

class SomeArray {
    static 1 := "one"
         , 2 := "two"
         , 3 := "three"
}

Top

just me

Post subject:

Posted: August 28th, 2011, 11:58 am

Joined: May 28th, 2011, 9:03 am
Posts: 464
Location: Germany

Oops, thought to remember that pure numbers aren't valid variable names anymore :roll:

Top

infogulch

Post subject:

Posted: August 28th, 2011, 7:16 pm

Joined: March 27th, 2008, 2:14 pm
Posts: 700

Ooh interesting solution... Subclasses here I come

_________________
Scripts - License

Top

Lexikos

Post subject:

Posted: September 7th, 2011, 4:12 am

Joined: October 17th, 2006, 4:15 pm
Posts: 7503
Location: Australia

I just figured out that even if MAX_TOKENS is increased, just me's example won't work since function calls are limited to 255 parameters, and the example uses 256. Increasing this limit means increasing memory usage by 4 bytes per variable or function reference (e.g. 12 bytes for f(x,y) or for x+x+x). While not much, it's something to consider. There's still also the line length limit of 16,383 characters, which applies after continuation lines are merged.

Top

Page 1 of 1

[ 13 posts ]

Board index » AutoHotkey » Suggestions

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 3 guests

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum