[Grace-core] Re-defining stuff from the standard libraries

[Marco Servetto]

Yep, I like this, is similar to how is done in 42.
(of course, in 42 I aim to provide some nice metaprogramming to define
your own preludes)
However, this kind of mechanism means, in my terms, that there is no
standard library/standard prelude.
Does it make sense as a terminology?
is it a technical term or a social one?
is the standard prelude just "the most used one"?

Marco.

On 24 February 2015 at 02:10, Andrew P Black <black at cs.pdx.edu> wrote:
> This email is an attempt to clarify my views on what Grace needs to allow
> wrt re-defining stuff from the standard libraries.
>
> For the sake of concreteness, let's assume that my application needs an
> enhancement to String objects.  I might need, for example, a method
> "asHtml" turns a String into an html object.
>
> In Smalltalk,  one does this by changing the class of all of the String
> objects that exist in the image.  They get a new class with the extra
> method. This seems to be the only way to do it in Smalltalk because
> Smalltalk runs in a live image that is a direct descendent of some image
> that was running at PARC in 1980.
>
> In Grace, every program starts in its own, fresh, image.  So enhancing
> string does not require changing any existing strings — it requires changing
> the library code to include the extra method before any user-program code is
> executed.   So the whole business of enhancing libraries can be much less
> dynamic.
>
> In concept, the way that I see this working is that the standard prelude
> will include something like
>
> import "standardString" as string
>
> In my enhanced prelude, I would write something like
>
> import "standardString" as standardString
> import "html" as html
> def string is public  = object {
> inherits string
> method asHtml {  html.fromString(self) }
> }
>
> For this to work, all of the Strings created by the code compiled for String
> Literals would need to call a constructor that's in standardString,
> such as string.fromNativeString().   By redefining the meaning of string in
> my program, I've made this constructor build my strings, the ones with the
> extra method — because all of the code generated by the compiler is
> (conceptually, al least) in the scope defined by my enhanced prelude.
>
> No runtime object mutation is necessary.  In fact, most of this works in the
> language and the Minigrace implementation as currently defined, except that
>
> (1) The language spec says that we can't inherit from a module object,
> because it's not "fresh".  So inherits string has to be inherits
> string.methods, and we have to define string.methods in the standardString
> library.
> (2) in Minigrace, the interface used to create strings from literals isn't
> string.fromNative, but new GraceString.  And the string library isn't
> cleanly packaged as a module.  Neither of these seems to be important, or
> hard to change.
>
> I'm probably missing some details of what would be required to make this
> work, but I don't think that the conceptual outline has changed since we
> discussed on 2-3 July 2012 in the conference room on the ground floor of
> Kim's building.  (The notes from this meeting are in the SVN repo at
> Notes/Grace meeting 2 July 2012.rtf).
>
> Andrew
>
>
>
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
>