Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Syntax and backwards compatibility objects.fs revision
21 views
Skip to first unread message
Anton Ertl
Apr 12, 2012, 9:08:32 AM4/12/12
to
I am working on a revision of objects.fs.
One change is that objects2.fs will no longer require that method
selectors are defined for an ancestor class of any class that wants to
be able to understand the selector (this enables duck typing).
As a consequence, the syntax changes, from: (preferredly) first
defining a selector, then methods and binding them to the selector;
to: defining method and defining/overriding the selector in one go.
An obvious candidate for the new syntax is:
m: <selector>
... <code> ... ;m
Unfortunately, objects.fs already has M: and ;M, and they behave
differently.
I now see two options for dealing with this:
1) Use M: and ;M and rename the old M: and ;M to something else; when
transitioning to objects2.fs, existing uses of M: and ;M would have to
be searched and replaced.
2) Use something other than M: and ;M for the new syntax.
In general I favour option 2 (I like backwards compatibility without
ado), but I don't have any good alternative names (:M is also taken in
objects.fs); what would be your suggestsion?
Also, to estimate the impact of option 1, let me know if you would be
affected and how much code you would have to change.
Thanks in advance.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
One change is that objects2.fs will no longer require that method
selectors are defined for an ancestor class of any class that wants to
be able to understand the selector (this enables duck typing).
As a consequence, the syntax changes, from: (preferredly) first
defining a selector, then methods and binding them to the selector;
to: defining method and defining/overriding the selector in one go.
An obvious candidate for the new syntax is:
m: <selector>
... <code> ... ;m
Unfortunately, objects.fs already has M: and ;M, and they behave
differently.
I now see two options for dealing with this:
1) Use M: and ;M and rename the old M: and ;M to something else; when
transitioning to objects2.fs, existing uses of M: and ;M would have to
be searched and replaced.
2) Use something other than M: and ;M for the new syntax.
In general I favour option 2 (I like backwards compatibility without
ado), but I don't have any good alternative names (:M is also taken in
objects.fs); what would be your suggestsion?
Also, to estimate the impact of option 1, let me know if you would be
affected and how much code you would have to change.
Thanks in advance.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
Alex McDonald
Apr 12, 2012, 10:44:14 AM4/12/12
to
On Apr 12, 2:08 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
I have no code that would be affected by this, so my "vote" can be
weighed accordingly. Unless there's something magic about ;M ,
treating this as a standard colon word on the lines of :NONAME and
terminating it with ; seems better.
method: <selector> ... <code> ... ;
If that's not possible, then perhaps ;METHOD . For the minimalist,
there's always ALIAS and SYNONYM to enable shorter forms.
wrote:
weighed accordingly. Unless there's something magic about ;M ,
treating this as a standard colon word on the lines of :NONAME and
terminating it with ; seems better.
method: <selector> ... <code> ... ;
If that's not possible, then perhaps ;METHOD . For the minimalist,
there's always ALIAS and SYNONYM to enable shorter forms.
Doug Hoffman
Apr 12, 2012, 11:48:00 AM4/12/12
to
On 4/12/12 9:08 AM, Anton Ertl wrote:
> I am working on a revision of objects.fs.
>
> One change is that objects2.fs will no longer require that method
> selectors are defined for an ancestor class of any class that wants to
> be able to understand the selector (this enables duck typing).
>
> As a consequence, the syntax changes, from: (preferredly) first
> defining a selector, then methods and binding them to the selector;
> to: defining method and defining/overriding the selector in one go.
> An obvious candidate for the new syntax is:
>
> m:<selector>
> ...<code> ... ;m
>
> Unfortunately, objects.fs already has M: and ;M, and they behave
> differently.
>
> I now see two options for dealing with this:
>
> 1) Use M: and ;M and rename the old M: and ;M to something else; when
> transitioning to objects2.fs, existing uses of M: and ;M would have to
> be searched and replaced.
>
> 2) Use something other than M: and ;M for the new syntax.
>
> In general I favour option 2 (I like backwards compatibility without
> ado), but I don't have any good alternative names (:M is also taken in
> objects.fs); what would be your suggestsion?
For what it's worth, the standard already has :NONAME and ;CODE ,
> I am working on a revision of objects.fs.
>
> One change is that objects2.fs will no longer require that method
> selectors are defined for an ancestor class of any class that wants to
> be able to understand the selector (this enables duck typing).
>
> As a consequence, the syntax changes, from: (preferredly) first
> defining a selector, then methods and binding them to the selector;
> to: defining method and defining/overriding the selector in one go.
> An obvious candidate for the new syntax is:
>
> m:<selector>
> ...<code> ... ;m
>
> Unfortunately, objects.fs already has M: and ;M, and they behave
> differently.
>
> I now see two options for dealing with this:
>
> 1) Use M: and ;M and rename the old M: and ;M to something else; when
> transitioning to objects2.fs, existing uses of M: and ;M would have to
> be searched and replaced.
>
> 2) Use something other than M: and ;M for the new syntax.
>
> In general I favour option 2 (I like backwards compatibility without
> ado), but I don't have any good alternative names (:M is also taken in
> objects.fs); what would be your suggestsion?
perhaps setting a precedent that certain kinds of words should start
with a colon (when beginning a definition) and certain kinds of words
should start with a semicolon (when ending a definition). So :M and ;M
might be viewed as most consistent with existing practice.
-Doug
Alex McDonald
Apr 12, 2012, 1:05:47 PM4/12/12
to
and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
treatment, so why not METHOD?
Doug Hoffman
Apr 12, 2012, 2:00:04 PM4/12/12
to
> I still prefer the full word; :METHOD in leading colon notation
> and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
> treatment, so why not METHOD?
No reason. Actually, :METHOD and ;METHOD might be viewed as even more
> and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
> treatment, so why not METHOD?
consistent with :NONAME and ;CODE. Though :M and ;M are brief.
-Doug
BruceMcF
Apr 12, 2012, 2:10:54 PM4/12/12
to
On Apr 12, 11:48 am, Doug Hoffman <glide...@gmail.com> wrote:
> For what it's worth, the standard already has :NONAME and ;CODE ,
> perhaps setting a precedent that certain kinds of words should start
> with a colon (when beginning a definition) and certain kinds of words
> should start with a semicolon (when ending a definition). So :M and ;M
> might be viewed as most consistent with existing practice.
Specifically, that's:
> For what it's worth, the standard already has :NONAME and ;CODE ,
> perhaps setting a precedent that certain kinds of words should start
> with a colon (when beginning a definition) and certain kinds of words
> should start with a semicolon (when ending a definition). So :M and ;M
> might be viewed as most consistent with existing practice.
:NONAME ... ;
... though as far as what that is a precedent *for*, the terminating
":" shorthand is used in some naming conventions to indicate that the
next token in the sequence is the name of something being defined,
":NONAME" the other way around conveys, rather, "like : but with no
name".
I prefer sticking with the same naming convention as M: and ;M uses,
but writing out method: and ;method ~ or:
method: "name" ... ;
... if the process can be done up front in a way that is compatible
with the ordinary ; compiler operation.
Anton Ertl
Apr 13, 2012, 8:48:49 AM4/13/12
to
Alex McDonald <bl...@rivadpm.com> writes:
>I still prefer the full word; :METHOD in leading colon notation
>and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
>treatment, so why not METHOD?
Method definitions are more frequent than PUBLIC, PRIVATE, or
>I still prefer the full word; :METHOD in leading colon notation
>and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
>treatment, so why not METHOD?
INTERFACE. Writing a METHOD twice for each definition is cumbersome
and discourages factoring. There's a reason why Forth uses ": ... ;"
and not ":definition ... ;definition".
I now lean towards using ":: ... ;;", which also satisfies Doug
Hoffman's requirement. I thank all responders for their input.
Concerning the question of why I don't just use ";" for the end: ";;"
does more, both when compiling the word and at run-time.
Alex McDonald
Apr 13, 2012, 9:57:19 AM4/13/12
to
On Apr 13, 1:48 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
frog :{ and the sinistra amicus }: .
wrote:
> Alex McDonald <b...@rivadpm.com> writes:
> >I still prefer the full word; :METHOD in leading colon notation
> >and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
> >treatment, so why not METHOD?
>
> Method definitions are more frequent than PUBLIC, PRIVATE, or
> INTERFACE. Writing a METHOD twice for each definition is cumbersome
> and discourages factoring. There's a reason why Forth uses ": ... ;"
> and not ":definition ... ;definition".
>
> I now lean towards using ":: ... ;;", which also satisfies Doug
> Hoffman's requirement. I thank all responders for their input.
Eek. I have the same problem with :: and ;; as I had with moustachioed
> >I still prefer the full word; :METHOD in leading colon notation
> >and ;METHOD. PUBLIC, PRIVATE, INTERFACE and so on get the full length
> >treatment, so why not METHOD?
>
> Method definitions are more frequent than PUBLIC, PRIVATE, or
> INTERFACE. Writing a METHOD twice for each definition is cumbersome
> and discourages factoring. There's a reason why Forth uses ": ... ;"
> and not ":definition ... ;definition".
>
> I now lean towards using ":: ... ;;", which also satisfies Doug
> Hoffman's requirement. I thank all responders for their input.
frog :{ and the sinistra amicus }: .
hwf...@gmail.com
Apr 13, 2012, 12:32:24 PM4/13/12
to
On Friday, April 13, 2012 5:48:49 AM UTC-7, Anton Ertl wrote:
> I now lean towards using ":: ... ;;", which also satisfies Doug
> Hoffman's requirement. I thank all responders for their input.
>
I like it.
> I now lean towards using ":: ... ;;", which also satisfies Doug
> Hoffman's requirement. I thank all responders for their input.
>
0 new messages