Need fix for syntax highlight of primitive pragmas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Need fix for syntax highlight of primitive pragmas

Igor Stasenko
Hello,

i thought that to conserve the space, it would be good to use a
symbols for primitive name and module name
in my methods.
Since all of my native-boost enabled methods using same primitive, so
i thought that i can just put following:
        <primitive: #primitiveNativeCall module: #NativeBoostPlugin>
and therefore, save some space , since declaration like following:
        <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'>
adds extra two strings to the pragma, which attached to method.
(What is interesting, that a first literal of compiled method, using
symbols for these names, instead of strings..
While pragma keeps original copies of strings, and therefore wasting
extra space, which i want to avoid).

What i found, that syntax highlighting turns the rest of method's
source in red color (like if there is a parse error),
while parser is perfectly ok with such syntax, and accepts such
methods without any problems.

Moreover, its 100% safe to use symbols instead of strings for prim/module names,
since they seem used by compiler anyways, and i even double-checked it
with VMMaker, that it can handle symbols instead of strings for named
primitives.
>From Interpreter's comment:

primitiveExternalCall
        "Call an external primitive. The external primitive methods
        contain as first literal an array consisting of:
        * The module name (String | Symbol)
        * The function name (String | Symbol)

so, a syntax highlighting is a bit annoying, and i'd like to fix that.
Any clues where to look at?

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need fix for syntax highlight of primitive pragmas

Eliot Miranda-2
Hi Igor,

On Thu, Apr 22, 2010 at 8:23 PM, Igor Stasenko <[hidden email]> wrote:
Hello,

i thought that to conserve the space, it would be good to use a
symbols for primitive name and module name
in my methods.
Since all of my native-boost enabled methods using same primitive, so
i thought that i can just put following:
       <primitive: #primitiveNativeCall module: #NativeBoostPlugin>
and therefore, save some space , since declaration like following:
       <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'>
adds extra two strings to the pragma, which attached to method.
(What is interesting, that a first literal of compiled method, using
symbols for these names, instead of strings..
While pragma keeps original copies of strings, and therefore wasting
extra space, which i want to avoid).

Look at STParserST80>>parsePrimitive.  Abstract the "self failUnless: currentTokenFirst == $'. self parseString"'s to a method or block and make them accept either strings or symbols and email me the fix :)

HTH
Eliot


What i found, that syntax highlighting turns the rest of method's
source in red color (like if there is a parse error),
while parser is perfectly ok with such syntax, and accepts such
methods without any problems.

Moreover, its 100% safe to use symbols instead of strings for prim/module names,
since they seem used by compiler anyways, and i even double-checked it
with VMMaker, that it can handle symbols instead of strings for named
primitives.
>From Interpreter's comment:

primitiveExternalCall
       "Call an external primitive. The external primitive methods
       contain as first literal an array consisting of:
       * The module name (String | Symbol)
       * The function name (String | Symbol)

so, a syntax highlighting is a bit annoying, and i'd like to fix that.
Any clues where to look at?

--
Best regards,
Igor Stasenko AKA sig.




Reply | Threaded
Open this post in threaded view
|

Re: Need fix for syntax highlight of primitive pragmas

Igor Stasenko
Thanks,
here it is.



On 23 April 2010 07:36, Eliot Miranda <[hidden email]> wrote:

> Hi Igor,
>
> On Thu, Apr 22, 2010 at 8:23 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> Hello,
>>
>> i thought that to conserve the space, it would be good to use a
>> symbols for primitive name and module name
>> in my methods.
>> Since all of my native-boost enabled methods using same primitive, so
>> i thought that i can just put following:
>>        <primitive: #primitiveNativeCall module: #NativeBoostPlugin>
>> and therefore, save some space , since declaration like following:
>>        <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'>
>> adds extra two strings to the pragma, which attached to method.
>> (What is interesting, that a first literal of compiled method, using
>> symbols for these names, instead of strings..
>> While pragma keeps original copies of strings, and therefore wasting
>> extra space, which i want to avoid).
>
> Look at STParserST80>>parsePrimitive.  Abstract the "self failUnless:
> currentTokenFirst == $'. self parseString"'s to a method or block and make
> them accept either strings or symbols and email me the fix :)
> HTH
> Eliot
>>
>> What i found, that syntax highlighting turns the rest of method's
>> source in red color (like if there is a parse error),
>> while parser is perfectly ok with such syntax, and accepts such
>> methods without any problems.
>>
>> Moreover, its 100% safe to use symbols instead of strings for prim/module
>> names,
>> since they seem used by compiler anyways, and i even double-checked it
>> with VMMaker, that it can handle symbols instead of strings for named
>> primitives.
>> >From Interpreter's comment:
>>
>> primitiveExternalCall
>>        "Call an external primitive. The external primitive methods
>>        contain as first literal an array consisting of:
>>        * The module name (String | Symbol)
>>        * The function name (String | Symbol)
>>
>> so, a syntax highlighting is a bit annoying, and i'd like to fix that.
>> Any clues where to look at?
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>


--
Best regards,
Igor Stasenko AKA sig.



shparser-fix.1.cs (992 bytes) Download Attachment