Re: Possibility of standardized sprintf() in ES4?
On 15/10/2007, ekameleon <[EMAIL PROTECTED]> wrote:
>
> Hello :)
>
> Yes i prefere too the Strings.format implementation :) For me it's an
> important feature and can be insert in the core String methods :)
>
> EKA+ :)
>
> 2007/10/15, zwetan <[EMAIL PROTECTED]>:
> >
> > Hi,
> >
> > ...
> > >
> > > Is there any other interest in adding a native sprintf() (probably as
> > > String.sprintf()) to the ES4 specs?
> > >
> >
> > I'm interested in string formating, but surely not sprintf
> > I don't find it intuitive at all
> >
> > I prefer something closer to String.format from .NET
> > but more dynamic and being able to use sort of tokens
> > like the ones you can use with E4X ({token})
> >
> > see here for an implementation
> > http://maashaack.googlecode.com/svn/trunk/ES4a/src/system/Strings.as
> > ( public static function format( format:String, ...args ):String )
> >
> > cheers,
> > zwetan
> > ___
> > Es4-discuss mailing list
> > Es4-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
>
>
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
>
Sure. From what I can see of the Microsoft documentation a standardized
String.format() function would meet the need for a standardized way of
formatting a string just as well as a method based on C/Perl/PHP/Ruby
sprintf() and Python's native string formatting, where named parameters are
used instead of positional parameters.
Assuming there are no intellectual property concerns with adopting
Microsoft's specification for this method, it would satisfy my use case for
a string formatting method that accepts explicit positional or named
parameters in support of internationalized text. I would simply be delighted
if ES4 saved me and others from having to roll our own string formatter
classes!
--
Dan Scott
Laurentian University
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Possibility of standardized sprintf() in ES4?
Hello :)
Yes i prefere too the Strings.format implementation :) For me it's an
important feature and can be insert in the core String methods :)
EKA+ :)
2007/10/15, zwetan <[EMAIL PROTECTED]>:
>
> Hi,
>
> ...
> >
> > Is there any other interest in adding a native sprintf() (probably as
> > String.sprintf()) to the ES4 specs?
> >
>
> I'm interested in string formating, but surely not sprintf
> I don't find it intuitive at all
>
> I prefer something closer to String.format from .NET
> but more dynamic and being able to use sort of tokens
> like the ones you can use with E4X ({token})
>
> see here for an implementation
> http://maashaack.googlecode.com/svn/trunk/ES4a/src/system/Strings.as
> ( public static function format( format:String, ...args ):String )
>
> cheers,
> zwetan
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Possibility of standardized sprintf() in ES4?
Hi,
...
>
> Is there any other interest in adding a native sprintf() (probably as
> String.sprintf()) to the ES4 specs?
>
I'm interested in string formating, but surely not sprintf
I don't find it intuitive at all
I prefer something closer to String.format from .NET
but more dynamic and being able to use sort of tokens
like the ones you can use with E4X ({token})
see here for an implementation
http://maashaack.googlecode.com/svn/trunk/ES4a/src/system/Strings.as
( public static function format( format:String, ...args ):String )
cheers,
zwetan
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 Grammar
> Thanks - that update seems like it has moved on in quite a few areas.
Yes, but it should be stabilizing somewhat now. The latest update tries to
bring the grammar in sync with the accepted proposals, which are now frozen.
Using PrimaryName as a NamespaceAttribute allows for the case you¹ve
identified package and namespace qualified namespace identifiers. E.g.:
import flash.utils.*;
flash.utils.flash_proxy function helper ( ) { ... }
Or the analog using namespaces:
namespace Utils;
Utils namespace Proxy;
Utils::Proxy function helper () { ... }
In both cases the qualified name must resolve to a namespace value during
the definition phase (that is before verification or evaluation).
Jd
On 10/15/07 1:09 PM, Michael O'Brien wrote:
> Jeff,
>
> Thanks - that update seems like it has moved on in quite a few areas.
>
> A follow on question: My question is what is the use case for a
> NamespaceAttribute being a PrimaryName. ie. Identifier "." Identifier ...
>
> Given that Global NamespaceAttributes are defined to be:
> public
> internal
> intrinsic
> PrimaryName
>
> This allows Paths in the namespace attribute. e.g. the following are legal
> where debug and release are suitably defined.
>
> debug var x
>
> a.b.c.release var x
>
> My question is what is the use case for a NamespaceAttribute being a
> PrimaryName. ie. Identifier "." Identifier ...
> And how does one create such a "a.b.c.release"?
>
> Are namespaces scoped to packages and thus the "a.b.c" refers to a package
> like "org.mozilla.release"?
> Or are these runtime namespaces where release is a property of "c" in the
> above example?
>
> Or is the grammar incorrect?
>
> Thanks
>
> Michael
>
>
>
> Jeff Dyer wrote:
>>
>> Hi Michael,
>>
>> You might have an old cached copy of grammar.pdf. The first two issues were
>> resolved in a previous version. I had a pending fix to the third issue. I
>> made NamespaceAttribute a PrimaryName. That way you can use namespace
>> qualified references as a namespace attribute.
>>
>> I've posted the latest and greatest, dated 14-oct-2007.
>>
>> Thanks,
>>
>> Jd
>>
>> On 10/14/07 11:25 AM, Michael O'Brien wrote:
>>
>>
>>
>>>
>>> This is probably for Jeff, but I'll send to the list anyway.
>>>
>>> I was doing a scrub through the latest posted grammar and may have a few
>>> small edits.
>>>
>>>
>>> 1. QualifiedNameIdentifier includes the tokens "*" and
>>> OverloadedOperator. However, overloaded operator includes "*" also. Is
>>> the "*' token
>>> therefore multiply resolved?
>>>
>>> 2. AttributeIdentifier in PrimaryExpression (production 110) should be
>>> AttributeName
>>>
>>> 3. The production on 414 under NamespaceAttribute has:
>>>
>>> Path . Identifier
>>> Identifier
>>>
>>> But Path already encompasses this. So you can replace these two
>>> lines with just "Path"
>>>
>>> Same in productions on lines 417+418
>>>
>>> Let me know if I have any of this wrong.
>>>
>>>
>>> Cheers
>>>
>>>
>>> Michael O'Brien
>>> ___
>>> Es4-discuss mailing list
>>> Es4-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es4-discuss
>>>
>>>
>>
>>
>>
>>
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 Grammar
Jeff, Thanks - that update seems like it has moved on in quite a few areas. A follow on question: My question is what is the use case for a NamespaceAttribute being a PrimaryName. ie. Identifier "." Identifier ... Given that Global NamespaceAttributes are defined to be: public internal intrinsic PrimaryName This allows Paths in the namespace attribute. e.g. the following are legal where debug and release are suitably defined. debug var x a.b.c.release var x My question is what is the use case for a NamespaceAttribute being a PrimaryName. ie. Identifier "." Identifier ... And how does one create such a "a.b.c.release"? Are namespaces scoped to packages and thus the "a.b.c" refers to a package like "org.mozilla.release"? Or are these runtime namespaces where release is a property of "c" in the above example? Or is the grammar incorrect? Thanks Michael Jeff Dyer wrote: Hi Michael, You might have an old cached copy of grammar.pdf. The first two issues were resolved in a previous version. I had a pending fix to the third issue. I made NamespaceAttribute a PrimaryName. That way you can use namespace qualified references as a namespace attribute. I've posted the latest and greatest, dated 14-oct-2007. Thanks, Jd On 10/14/07 11:25 AM, Michael O'Brien wrote: This is probably for Jeff, but I'll send to the list anyway. I was doing a scrub through the latest posted grammar and may have a few small edits. 1. QualifiedNameIdentifier includes the tokens "*" and OverloadedOperator. However, overloaded operator includes "*" also. Is the "*' token therefore multiply resolved? 2. AttributeIdentifier in PrimaryExpression (production 110) should be AttributeName 3. The production on 414 under NamespaceAttribute has: Path . Identifier Identifier But Path already encompasses this. So you can replace these two lines with just "Path" Same in productions on lines 417+418 Let me know if I have any of this wrong. Cheers Michael O'Brien ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: Yacc ?
Hi! On Mon, 15 Oct 2007, Jeff Dyer wrote: > Whether or not we could use it as the primary source of the reference > implementation, it would be interesting to implement the current grammar > using YACC to see where it is ambiguous. All I know is that the ES1-3 grammar was hard to squeeze into Bison/Yacc (think of automatic semicolon insertion!) for the KDE JavaScript interpreter. Next version will work without for greater flexibility and better error reporting. That being said, there are of course much more advanced parser generators these days that have more sophisticated input languages. Harri. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Possibility of standardized sprintf() in ES4?
I would be very interested in this. Have a look at our implementation (not called sprintf, but has similar goals). Our implementation has an additional goal of keeping an association between the result string and the objects it represents. Being a dynamic language, I think es4 should aspire to more than just C sprintf. http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/compiler/ LzFormatter.lzs Our source is licensed under CPL. http://svn.openlaszlo.org/openlaszlo/trunk/LICENSE.txt On 2007-10-15, at 08:27 EDT, Dan Scott wrote: > Hello: > > I've been working on a project requiring i18n support in ES > (http://open-ils.org), and it's become clear that a standard sprintf() > implementation in ES would have been very useful. There are currently > some open-source sprintf() implementations written in ES, but all of > the ones I've looked at so far seem to either have unusual licenses or > incomplete implementations (positional specifier support is absolutely > necessary for i18n, for example.) > http://hexmen.com/blog/2007/03/printf-sprintf/ is probably the closest > thing I've found to a solution yet. > > For something as basic as string formatting, it would be great to be > able to count on a core implementation of sprintf() (or something > equivalent) in a future version of ES. Jon Udell made a comment to the > effect that string formatting was a part of the TG1 wiki at > http://weblogs.mozillazine.org/roadmap/archives/2006/02/ > js_and_python_news.html, > but I've been unable to find that section in the wiki (unless that is > limited strictly to String.replace()). > > Is there any other interest in adding a native sprintf() (probably as > String.sprintf()) to the ES4 specs? > > -- > Dan Scott > Laurentian University > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: Yacc ?
This decision is based on our experience that recursive descent parsers are cheaper to build and maintain than their YACC counterparts. Especially for a language whose syntax is complex and still evolving, as is ES4's. Perhaps you have experience that says otherwise. BTW, the lexical scanner started out as an ML-LEX definition, but the tool seemed to be unable to handle a program of its size (or at least SML was unable to handle the generated tables). I wonder if we would encounter tooling issues with ML-YACC too. How portable are YACC definitions across ML implementations? Whether or not we could use it as the primary source of the reference implementation, it would be interesting to implement the current grammar using YACC to see where it is ambiguous. Regards, Jeff > -Original Message- > From: [EMAIL PROTECTED] [mailto:es4-discuss- > [EMAIL PROTECTED] On Behalf Of David Teller > Sent: Monday, October 15, 2007 7:32 AM > To: JS2 > Subject: Yacc ? > > Just a simple question about the reference implementation: why is the > parser hard-coded rather than written with ml-yacc ? I admit that I'm > somewhat tired about converting this parser manually to OCaml with > bunches of regexps + human proofreading, so I'm wondering if I shouldn't > skip this and go directly to Yacc or equivalent. > > Thanks, > David > > -- > David Teller -- > Security of Distributed Systems --- > -- http://www.univ-orleans.fr/lifo/Members/David.Teller > - Laboratoire d'Informatique Fondamentale d'Orleans > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: Arrays with non-integer properties
David "liorean" Andersson wrote: > > At some point of SISR chapter 7, more precisely item 5 in section 7.1, I > > find > > the following wording concerning EMMA (i.e. XML) serialization of ECMA > > arrays: > > "Any other properties of an Array object, for instance the keys of an > > associative > > array (e.g. a["prop"]), are subject to the same transformation rules as the > > regular properties of an object. In a sparse array, only those elements > > which > > hold defined values will be serialized." > > That text is a bit wrong. It's the element and not the value that is > defined or not. A defined element can have undefined as it's value. > Serialisation should differentiate the two, because the elements that > are not defined can be elided in the serialisation while the elements > that are defined cannot be elided. It's yet another example of the sloppiness of SISR standard when it comes to its connections with ECMA... Upon reading, it is indeed unclear whether the spec is simply nonsensical, or whether it's dealing with properties/elements having the special value "undefined"... > > [...] It is thus obviously (at least, that's how I analyse it) not > > the way one should serialize such an array. > > It cannot be serialised using JSON/ES3 literal syntax. Not if you want > to retain both the array-ness and the properties with non-array-ish > names. I find this pretty embarrassing: the standard discusses how to serialize in XML format the "non-array-ish" properties of an array, but it so happens that it's impossible to render them in ECMA format! --Serge No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 14/10/2007 09:22 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Arrays with non-integer properties
On 15/10/2007, Serge LE HUITOUZE <[EMAIL PROTECTED]> wrote: > More precisely, my question is about serialization. > A chapter of the afore-mentionned standard is devoted to serializing an ECMA > object in an XML form (a.k.a." EMMA form" in SISR wording). Along this > chapter, > interrogations come into play as to how some ECMA objects are serialized in > "ECMA" format: It seems it's such an obvious (sub-)problem in the context of > SISR standard that it is not even mentionned what governs this serialisation. > I make the hypothesis that this format is the same as the way one writes a > literal > value in an ECMA program, though I can't get any confirmationon w3.voice > forum... The syntax of literals in ECMAScript 3 is far from capable of representing the full set of object structures ECMAScript can contain. Some examples would include: - Function literals cannot represent the closure of a function object - the scope chain goes missing when serialising. - Host methods, objects and constructors may be serialisable but in practice are not. - Wrappers for primitives have no literal syntax at all. - Circular references on objects are not allowed in literals. (But moz has sharp variables for this.) - Getter and setter functionality is not serialisable. - Enumerability, removability, writability for properties are not serialisable. - Prototype links are not serialisable. - Array literals don't allow for properties with arbitrary non-uint32 names. - Arrays may contain properties whose name is so high (e.g. 0xfffe) that serialising the entire array as a string with comma separated elisions would require all of physical memory and then some. Illustrating this last point - try this example (displaying the results in a text node, so tries to serialise the array as a string): var array=[]; array[0xfffe]=0xfffe; array; On my system it leads to: - Saf eating all RAM, then paging to disk, and then crashing. - Op eating memory up to a point (~1GiB in my test), then silently fails without error. - Ie stringify as "undefined" but otherwise behave reasonably. - Moz... very slowly eats successively more and more ram, pegs the CPU, and is otherwise entirely unresponsive. (Didn't want to wait it out - in a quarter of an hour it's slowly grown from ~100MiB to ~300 MiB without showing any tendency to stop growing. But the growth curve is markedly jagged, one second consuming 50 MiB more than the next second.) > [BTW, I don't know if ECMA's literal syntax is exactly the same as JSON, I'm > interested in any clarification from you on this particular point.] JSON is a subset of ECMAScript literals. It doesn't deal with identifiers, reserved names, hexadecimal literals, optionally octal literals, function literals, regexp literals etc. > At some point of SISR chapter 7, more precisely item 5 in section 7.1, I find > the following wording concerning EMMA (i.e. XML) serialization of ECMA arrays: > "Any other properties of an Array object, for instance the keys of an > associative > array (e.g. a["prop"]), are subject to the same transformation rules as the > regular properties of an object. In a sparse array, only those elements which > hold defined values will be serialized." That text is a bit wrong. It's the element and not the value that is defined or not. A defined element can have undefined as it's value. Serialisation should differentiate the two, because the elements that are not defined can be elided in the serialisation while the elements that are defined cannot be elided. > Though this text describes the XML serialization, it clearly has implication > on > ECMA serialization as well: Indeed, it asserts as perfectly acceptable that an > array object can have non-integer properties in addition to "regular" index > properties. Nothing surprising there. In fact, ECMAScript 3 itself does this: the return arrays from regex matches have named properties. > The question is then: How do you ECMA-serialize an array object having, in > addition > to index properties, non-integer properties? There's no standard ECMAScript serialisation for this. It's not covered by any literal syntax, you need a program snippet to represent it. > >From my (short, but nevertheless painful) search in ECMA reference document, > I was not able to find how you can specify literally an ECMA array with > additional > non-integer properties. You cannot. > The only answer I got on "w3.voice" was one suggesting to use the object > notation to > create "something" that mixes integer and non-integer properties. However, > this "something" > is nothing more than a regular object (though slightly unusual, since it has > integer properites), > not an array object with non-integer properties. > It is thus obviously (at least, that's how I analyse it) not the way one > should serialize > such an array. It cannot be serialised using JSON/ES3 literal syntax. Not if you want to retain both the array-ness and the properti
Yacc ?
Just a simple question about the reference implementation: why is the parser hard-coded rather than written with ml-yacc ? I admit that I'm somewhat tired about converting this parser manually to OCaml with bunches of regexps + human proofreading, so I'm wondering if I shouldn't skip this and go directly to Yacc or equivalent. Thanks, David -- David Teller -- Security of Distributed Systems --- -- http://www.univ-orleans.fr/lifo/Members/David.Teller - Laboratoire d'Informatique Fondamentale d'Orleans ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Possibility of standardized sprintf() in ES4?
Hello: I've been working on a project requiring i18n support in ES (http://open-ils.org), and it's become clear that a standard sprintf() implementation in ES would have been very useful. There are currently some open-source sprintf() implementations written in ES, but all of the ones I've looked at so far seem to either have unusual licenses or incomplete implementations (positional specifier support is absolutely necessary for i18n, for example.) http://hexmen.com/blog/2007/03/printf-sprintf/ is probably the closest thing I've found to a solution yet. For something as basic as string formatting, it would be great to be able to count on a core implementation of sprintf() (or something equivalent) in a future version of ES. Jon Udell made a comment to the effect that string formatting was a part of the TG1 wiki at http://weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html, but I've been unable to find that section in the wiki (unless that is limited strictly to String.replace()). Is there any other interest in adding a native sprintf() (probably as String.sprintf()) to the ES4 specs? -- Dan Scott Laurentian University ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Arrays with non-integer properties
Hello there,
I have a question that I tried to solve on a more applicative mailing-list, but
which
seem not to interest anybody there ;-)
That's why I'll give it a try on this forum.
Sorry if it's not exactly the right forum, I'm not familiar with EcmaScript and
its
various brands, not to mention associated discussion forums/lists.
I'm confident, however, that I will find knowledgeable advice here (or, at
least,
redirection to appropriate discussion).
My questions arise from the last version of the W3C SISR standard
(http://www.w3.org/TR/semantic-interpretation/). It is used to normalize how one
writes (ECMA-327) code to build semantic information from a voice grammar.
More precisely, my question is about serialization.
A chapter of the afore-mentionned standard is devoted to serializing an ECMA
object in an XML form (a.k.a." EMMA form" in SISR wording). Along this chapter,
interrogations come into play as to how some ECMA objects are serialized in
"ECMA" format: It seems it's such an obvious (sub-)problem in the context of
SISR standard that it is not even mentionned what governs this serialisation.
I make the hypothesis that this format is the same as the way one writes a
literal
value in an ECMA program, though I can't get any confirmationon w3.voice
forum...
[BTW, I don't know if ECMA's literal syntax is exactly the same as JSON, I'm
interested in any clarification from you on this particular point.]
At some point of SISR chapter 7, more precisely item 5 in section 7.1, I find
the following wording concerning EMMA (i.e. XML) serialization of ECMA arrays:
"Any other properties of an Array object, for instance the keys of an
associative
array (e.g. a["prop"]), are subject to the same transformation rules as the
regular properties of an object. In a sparse array, only those elements which
hold defined values will be serialized."
Though this text describes the XML serialization, it clearly has implication on
ECMA serialization as well: Indeed, it asserts as perfectly acceptable that an
array object can have non-integer properties in addition to "regular" index
properties.
The question is then: How do you ECMA-serialize an array object having, in
addition
to index properties, non-integer properties?
>From what I understand of ECMA-262 (which is little...) the following SISR
>fragment:
** v1=new Array; v1.push("A"); v1[3]="B"; $.v1=v1;
should yield the following ECMA serialization:
** {v1:["A",,,"B"]}
So would the equivalent ECMA fragment using the literal syntax:
** v1=["A",,,"B"]; $.v1=v1;
This is (hopefully) straightforward.
But then, what would the following SISR fragment yield?
** v1=new Array; v1.push("A"); v1[3]="B"; v1["prop"]="C"; $.v1=v1;
>From my (short, but nevertheless painful) search in ECMA reference document,
I was not able to find how you can specify literally an ECMA array with
additional
non-integer properties.
The only answer I got on "w3.voice" was one suggesting to use the object
notation to
create "something" that mixes integer and non-integer properties. However, this
"something"
is nothing more than a regular object (though slightly unusual, since it has
integer properites),
not an array object with non-integer properties.
It is thus obviously (at least, that's how I analyse it) not the way one should
serialize
such an array.
Comments anyone?
Thanks in advance.
--Serge Le Huitouze
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 14/10/2007
09:22
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
