Hi Igor,

On Thu, Apr 22, 2010 at 8:23 PM, Igor Stasenko <siguctua at gmail.com> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100422/dee2fbc9/attachment.htm