Re: [Factor-talk] Changing global variables at parse time

[Andrea Ferretti]

Wow, that's more than I dared to ask! :-)

2014-12-17 2:35 GMT+01:00 tgkuo :
>
> Quotations are just squeneces -- That's the key point that I not got yet...
>
> So, if I wante to put quotation inside a sequence, I would use:
>
> IN: scratchpad { 1 2 } [ 3 ] 1quotation append .
> { 1 2 [ 3 ] }
>
> test passed.
>
> Thanks.
>
> kuo
>
>
> 於 2014/12/17 上午8:55, John Benediktsson 提到:
>
> You can see what code is generated for both approaches:
>
> SYNTAX: FOO: scan-token '[ _ foo set ] append! ;
>
> IN: scratchpad [ FOO: hello ] .
> [ "hello" foo set ]
>
> SYNTAX: FOO1: scan-token '[ _ foo set ] suffix! \ call suffix! ;
>
> IN: scratchpad [ FOO1: hello ] .
> [ [ "hello" foo set ] call ]
>
> The first is simpler, although the results should be the same as your
> version.
>
> And quotations are just sequences, see this:
>
> IN: scratchpad [ 1 2 3 ] first .
> 1
>
> IN: scratchpad [ 1 2 ] { 3 } append .
> [ 1 2 3 ]
>
> IN: scratchpad { 1 2 } [ 3 ] append .
> { 1 2 3 }
>
> Knowing that, you could also do this, which looks a little weird but works:
>
> SYNTAX: FOO2: scan-token suffix! { foo set } append! ;
>
> IN: scratchpad [ FOO2: hello ] .
> [ "hello" foo set ]
>
>
>
> On Tue, Dec 16, 2014 at 4:17 PM, tgkuo  wrote:
>>
>> Hi,
>>
>> About the parsing using append! as below
>>
>> > SYNTAX: FOO: scan-token '[ _ foo set ] append! ;
>>
>> seemed to have the same effect as this one, which is more understandable
>>
>> SYNTAX: FOO1: scan-token '[ _ foo set ] suffix! \ call suffix! ;
>>
>> As I knew, append! has the stack effect of ( seq seq -- seq ) but the
>> quotation is not a kind of seq, how this works?
>>
>>
>> BR
>>
>> kuo
>>
>>
>>
>>
>>
>> 於 2014/12/17 上午1:00, John Benediktsson 提到:
>>
>> If you want your code to work the way you intend, using a local namespace,
>> then how about this:
>>
>> SYNTAX: FOO: scan-token '[ _ foo set ] append! ;
>>
>> That will set in the namespace that you want.
>>
>> On Tue, Dec 16, 2014 at 8:59 AM, John Benediktsson 
>> wrote:
>>>
>>> Also, I'm not sure why you need a parsing word for that, you can just:
>>>
>>> IN: foo
>>>
>>> SYMBOL: foo
>>>
>>> IN: bar
>>>
>>> foo [ "hello" ] initialize
>>>
>>> ... or
>>>
>>> "hello" foo set-global
>>>
>>> the first will initialize if not ``f``, the second will always set.
>>>
>>>
>>>
>>> On Tue, Dec 16, 2014 at 8:55 AM, Andrea Ferretti
>>>  wrote:

 Hi, I am trying to define some syntax words that should have effect on
 a global (or dynamic) variable. What I am trying to achieve is
 something similar to how the LIBRARY: word affects later occurrences
 of FUNCTION:

 The problem is, it does not seem to work. The simplest example I can
 make is up the following.

 In package foo

 USING: kernel lexer namespaces ;
 IN: foo

 SYMBOL: foo

 SYNTAX: FOO: scan-token foo set ;

 Then in package bar

 USING: namespaces foo prettyprint ;
 IN: bar

 FOO: hello

 foo get .


 This executes the top level form `foo get .` but prints f instead of
 "hello". The same happens if I use run-file directly. If, instead, I
 make the same declaration

 FOO: hello

 in the listener, I can check that foo is modified.

 Is there a way to make this work? I could also avoi the variable, but
 while parsing I do not have access to the stack, and so I do not know
 how to pass any information among parsing words.


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration &
 more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
 ___
 Factor-talk mailing list
 Factor-talk@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>>
>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>
>>
>>
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>>
>>
>> --
>> Download BIRT iHub F-Type - The

Re: [Factor-talk] Changing global variables at parse time

[tgkuo]

While quotations are sequences, in order for the stack-checker to 
infer the proper effect for combinators, you can't call append on two 
quotations, you must call compose instead. Likewise with 
suffix/prefix, you should call curry.


For what I undertood and learned,  "quotations" and  "sequences" are 
equal when used as data, but quotations acted very differenct when used 
as codes.


"quotations"  like anonymous function in function paradigm, are 
executable, so, in factor philosophy, they must be checked for stack 
effects when complied, that requirement ruled out the simple usage of 
sequence operation words on them.


But I wondered if simple usage of append is feasible in Syntax 
definition, that means there is no strong requirement of stack effect 
check when parsing and building the lexer?


Thanks.

To put it all together, look at a parse-time example, SYNTAX: definition:

IN: syntax
SYNTAX: SYNTAX: scan-new-word parse-definition define-syntax ;

: parse-definition ( -- quot ) \ ; parse-until >quotation ;

: define-syntax ( word quot -- )
[ drop ] [ define ] 2bi t "parsing" set-word-prop ;

What's happening here is that, at parse-time, you create a new word, 
parse its definition until the semi-colon, and then convert that into 
a quotation. So all your suffix! and append! are really creating an 
array of code at parse-time and then, since converting between 
sequence types makes sense, you convert that array to a quotation. 
Since this happens at parse-time, it's safe to do this--you do not 
need compose/prepose and curry. Finally, setting the "parsing" 
property tells the parser that your new SYNTAX: is a parsing word.


I hope this helps, and please ask any followup questions!

Doug



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and
Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration
& more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/factor-talk



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk


___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] A stub of a package manager

[Andrea Ferretti]

Hi, following this [small
discussion](https://news.ycombinator.com/item?id=8750720) I thought I
might give a try at designing a simple package manager.

It is inspired by [Metacello](https://code.google.com/p/metacello/)
but delegates to existing source control management software such as
git the actual handling of repositories, similar to
[Bower](http://bower.io/).

You can find the stub of a package manager
[here](https://github.com/andreaferretti/factor-packages) (keep in
mind: this is just the work of a day, and I am still a beginner).

Outline
---

The central concept is that of a *project*. A project has a name and a
version, and contains some vocabularies. It can also depend on other
projects. There are syntax words to define the structure of a project,
which currently look like this (for a hypothetical project):


USING: packages.syntax
IN: example-project

PROJECT: example

VERSION: 0.2.0-alpha

VOCAB: example.thrift

VOCAB: example.main

DEPENDENCY: thrift
  GITHUB{ "factor" "thrift" "0.2.5" }

One can then do the following in the listener

IN: scratchpad
USE: packages.projects
"example-project" activate

This clones the repository for each of the dependencies in a subfolder
of "resource:cache" and switches to the given version. It is expected
that each dependency contains a toplevel file `project.factor` as
above. Then, transitive dependencies are recursively fetched.

After fetching all dependencies, the vocabulary roots are adjusted,
and finally all vocabularies mentioned in the project or in a
dependency are `require`d.

If you import the package manager in your work folder, you can see a
[simple 
example](https://github.com/andreaferretti/factor-packages/blob/master/packages/example/example.factor)
in action. Just do

IN: scratchpad
USE: packages.projects
"packages.example" activate

You will then be able to use, say, the `monoid` dependency, like this

IN: scratchpad
3 5 |+|

I would like to get feedback on the above design, so as to understand
if it is worth the effort to develop this into something actually
usable. While very simplistic, I think this approach has a couple of
advantages:

* it does not require any change to the Factor vocabulary system
* by exploiting existing SCM (git and hg are currently supported, but
it would be easy to add more) one can avoid the need to setup a
repository and to develop a custom protocol.

Issues
--

If the above looks any good, there are a number of things one can
improve. All of those seem easy enough, they just requires some time.

* support other SCM (svn, darcs, bazaar, ...)
* improve the DSL (for instance, should we have VOCABS: ?)
* add support for publishing, as well as consuming packages. This
would allow to do something like `"mypackage" publish` and
  - copy the vocabularies in the cache under the appropriate subfolder
  - copy the definition file as project.factor
  - commit the result
  - tag with the declared version
  - possibly sync it with online repositories
* add error reporting
* add standard stuff: tests, docs...
* general cleanup and refactoring
* GUI tools to support the workflows

There are also some issues one may want to consider:

* Are there any performance problems in supporting a possibly large
set of vocab-roots? (I think not, I see there is a cache for this)
* What about the files `project.factor`? Currently they do not follow
the standard conventions about file placement. Should I change the
directory structure to put them in valid places?
* In every package manager there is the issue of transitive
dependencies that are included multiple times with different versions.
As of now, the result of the above algorithm is that the last version
mentioned wins. What could be a better policy? One issue here is that
other package managers - Maven, for instance - fetch the specification
(in the form of pom.xml) separately from the artifact itself. This
allows them to have the complete picture *before* starting to download
dependencies, hence apply any policy they choose. The way I have
handled it, project.factor files coexist in the same repository as the
vocabularies themselves, which complicates things a bit (I have to
checkout the repositories to even look at dependencies, but later I
may change idea about which versions to use).
* If a package manager was used, what would be the impact on the
Factor ecosystem? After all, the current model of putting everything
in the main repository has some advantages:
  - it is easier to discover libraries
  - we avoid redundancy, which at this scale is important (no need for
anyone to make another json library, as it is already there)
Both points could be partially mitigated having a set of officially
endorsed packages, which are one click away in the listener. On the
other hand, it will not be feasible forever to have everything in the
main repository, and in particular this presents issues when
developing libraries w

Re: [Factor-talk] A stub of a package manager

[John Benediktsson]

Hi Andrea,

I want to look through this and give you a more full response, looks like a
pretty good start. Thank you!

One of the benefits to the "one big tree" that we have right now is that we
guarantee to update your code as the standard library changes or improves.
This prevents bitrot and allows for some flexibility in changing common
words.  That matters less over time as the standard library becomes more
mature, but has been useful at times.  We've wanted ``extra/`` to be very
very easy to contribute to as a way of supporting new contributors and then
involving them as we keep an eye on their code.  Obviously there are
drawbacks to this approach too...

Of course people can have their own repositories, and we should support
them as best we can (like support for adding vocab roots or through a
package manager), but I always want to encourage contributions when it
makes sense for everyone.

Having something simple that encourages re-use of code is pretty great, we
could probably share our testing infrastructure to support easy continuous
integration for a project developed this way.

More to come later when I have time.

Best,
John.



On Wed, Dec 17, 2014 at 6:20 AM, Andrea Ferretti 
wrote:
>
> Hi, following this [small
> discussion](https://news.ycombinator.com/item?id=8750720) I thought I
> might give a try at designing a simple package manager.
>
> It is inspired by [Metacello](https://code.google.com/p/metacello/)
> but delegates to existing source control management software such as
> git the actual handling of repositories, similar to
> [Bower](http://bower.io/).
>
> You can find the stub of a package manager
> [here](https://github.com/andreaferretti/factor-packages) (keep in
> mind: this is just the work of a day, and I am still a beginner).
>
> Outline
> ---
>
> The central concept is that of a *project*. A project has a name and a
> version, and contains some vocabularies. It can also depend on other
> projects. There are syntax words to define the structure of a project,
> which currently look like this (for a hypothetical project):
>
>
> USING: packages.syntax
> IN: example-project
>
> PROJECT: example
>
> VERSION: 0.2.0-alpha
>
> VOCAB: example.thrift
>
> VOCAB: example.main
>
> DEPENDENCY: thrift
>   GITHUB{ "factor" "thrift" "0.2.5" }
>
> One can then do the following in the listener
>
> IN: scratchpad
> USE: packages.projects
> "example-project" activate
>
> This clones the repository for each of the dependencies in a subfolder
> of "resource:cache" and switches to the given version. It is expected
> that each dependency contains a toplevel file `project.factor` as
> above. Then, transitive dependencies are recursively fetched.
>
> After fetching all dependencies, the vocabulary roots are adjusted,
> and finally all vocabularies mentioned in the project or in a
> dependency are `require`d.
>
> If you import the package manager in your work folder, you can see a
> [simple example](
> https://github.com/andreaferretti/factor-packages/blob/master/packages/example/example.factor
> )
> in action. Just do
>
> IN: scratchpad
> USE: packages.projects
> "packages.example" activate
>
> You will then be able to use, say, the `monoid` dependency, like this
>
> IN: scratchpad
> 3 5 |+|
>
> I would like to get feedback on the above design, so as to understand
> if it is worth the effort to develop this into something actually
> usable. While very simplistic, I think this approach has a couple of
> advantages:
>
> * it does not require any change to the Factor vocabulary system
> * by exploiting existing SCM (git and hg are currently supported, but
> it would be easy to add more) one can avoid the need to setup a
> repository and to develop a custom protocol.
>
> Issues
> --
>
> If the above looks any good, there are a number of things one can
> improve. All of those seem easy enough, they just requires some time.
>
> * support other SCM (svn, darcs, bazaar, ...)
> * improve the DSL (for instance, should we have VOCABS: ?)
> * add support for publishing, as well as consuming packages. This
> would allow to do something like `"mypackage" publish` and
>   - copy the vocabularies in the cache under the appropriate subfolder
>   - copy the definition file as project.factor
>   - commit the result
>   - tag with the declared version
>   - possibly sync it with online repositories
> * add error reporting
> * add standard stuff: tests, docs...
> * general cleanup and refactoring
> * GUI tools to support the workflows
>
> There are also some issues one may want to consider:
>
> * Are there any performance problems in supporting a possibly large
> set of vocab-roots? (I think not, I see there is a cache for this)
> * What about the files `project.factor`? Currently they do not follow
> the standard conventions about file placement. Should I change the
> directory structure to put them in valid places?
> * In every package manager there i

Re: [Factor-talk] A stub of a package manager

[Alex Vondrak]

Excited to see where this goes! I like the DSL - reminds me of how it feels
to use [Bundler](http://bundler.io/), where the language for dependency
management is the same as the language you're coding in. (Can you tell my
day job is in Ruby?)

I don't really have anything to add - I can't seem to find the time to
touch Factor these days, and I shy away from the Big Decisions when it
comes to package management (I understand it's a deceptively subtle
problem). But I enjoyed reading about your work, and wanted you to know. :)

On Wed, Dec 17, 2014 at 8:28 AM, John Benediktsson  wrote:
>
> Hi Andrea,
>
> I want to look through this and give you a more full response, looks like
> a pretty good start. Thank you!
>
> One of the benefits to the "one big tree" that we have right now is that
> we guarantee to update your code as the standard library changes or
> improves. This prevents bitrot and allows for some flexibility in changing
> common words.  That matters less over time as the standard library becomes
> more mature, but has been useful at times.  We've wanted ``extra/`` to be
> very very easy to contribute to as a way of supporting new contributors and
> then involving them as we keep an eye on their code.  Obviously there are
> drawbacks to this approach too...
>
> Of course people can have their own repositories, and we should support
> them as best we can (like support for adding vocab roots or through a
> package manager), but I always want to encourage contributions when it
> makes sense for everyone.
>
> Having something simple that encourages re-use of code is pretty great, we
> could probably share our testing infrastructure to support easy continuous
> integration for a project developed this way.
>
> More to come later when I have time.
>
> Best,
> John.
>
>
>
> On Wed, Dec 17, 2014 at 6:20 AM, Andrea Ferretti  > wrote:
>>
>> Hi, following this [small
>> discussion](https://news.ycombinator.com/item?id=8750720) I thought I
>> might give a try at designing a simple package manager.
>>
>> It is inspired by [Metacello](https://code.google.com/p/metacello/)
>> but delegates to existing source control management software such as
>> git the actual handling of repositories, similar to
>> [Bower](http://bower.io/).
>>
>> You can find the stub of a package manager
>> [here](https://github.com/andreaferretti/factor-packages) (keep in
>> mind: this is just the work of a day, and I am still a beginner).
>>
>> Outline
>> ---
>>
>> The central concept is that of a *project*. A project has a name and a
>> version, and contains some vocabularies. It can also depend on other
>> projects. There are syntax words to define the structure of a project,
>> which currently look like this (for a hypothetical project):
>>
>>
>> USING: packages.syntax
>> IN: example-project
>>
>> PROJECT: example
>>
>> VERSION: 0.2.0-alpha
>>
>> VOCAB: example.thrift
>>
>> VOCAB: example.main
>>
>> DEPENDENCY: thrift
>>   GITHUB{ "factor" "thrift" "0.2.5" }
>>
>> One can then do the following in the listener
>>
>> IN: scratchpad
>> USE: packages.projects
>> "example-project" activate
>>
>> This clones the repository for each of the dependencies in a subfolder
>> of "resource:cache" and switches to the given version. It is expected
>> that each dependency contains a toplevel file `project.factor` as
>> above. Then, transitive dependencies are recursively fetched.
>>
>> After fetching all dependencies, the vocabulary roots are adjusted,
>> and finally all vocabularies mentioned in the project or in a
>> dependency are `require`d.
>>
>> If you import the package manager in your work folder, you can see a
>> [simple example](
>> https://github.com/andreaferretti/factor-packages/blob/master/packages/example/example.factor
>> )
>> in action. Just do
>>
>> IN: scratchpad
>> USE: packages.projects
>> "packages.example" activate
>>
>> You will then be able to use, say, the `monoid` dependency, like this
>>
>> IN: scratchpad
>> 3 5 |+|
>>
>> I would like to get feedback on the above design, so as to understand
>> if it is worth the effort to develop this into something actually
>> usable. While very simplistic, I think this approach has a couple of
>> advantages:
>>
>> * it does not require any change to the Factor vocabulary system
>> * by exploiting existing SCM (git and hg are currently supported, but
>> it would be easy to add more) one can avoid the need to setup a
>> repository and to develop a custom protocol.
>>
>> Issues
>> --
>>
>> If the above looks any good, there are a number of things one can
>> improve. All of those seem easy enough, they just requires some time.
>>
>> * support other SCM (svn, darcs, bazaar, ...)
>> * improve the DSL (for instance, should we have VOCABS: ?)
>> * add support for publishing, as well as consuming packages. This
>> would allow to do something like `"mypackage" publish` and
>>   - copy the vocabularies in the cache under the appropri

Re: [Factor-talk] A stub of a package manager

[Andrea Ferretti]

By the way, there are some cleanups under
https://github.com/andreaferretti/factor-work

But still, I am leaving
https://github.com/andreaferretti/factor-packages untouched, so that
it works as described in the previous email, in case someone wants to
try it.

Moreover, notice that https://github.com/andreaferretti/factor-work
also contains the two vocabularies that are fetched in the example, so
cloning factor-work and then trying the example will not work as
expected.

2014-12-17 17:57 GMT+01:00 Alex Vondrak :
> Excited to see where this goes! I like the DSL - reminds me of how it feels
> to use [Bundler](http://bundler.io/), where the language for dependency
> management is the same as the language you're coding in. (Can you tell my
> day job is in Ruby?)
>
> I don't really have anything to add - I can't seem to find the time to touch
> Factor these days, and I shy away from the Big Decisions when it comes to
> package management (I understand it's a deceptively subtle problem). But I
> enjoyed reading about your work, and wanted you to know. :)
>
> On Wed, Dec 17, 2014 at 8:28 AM, John Benediktsson  wrote:
>>
>> Hi Andrea,
>>
>> I want to look through this and give you a more full response, looks like
>> a pretty good start. Thank you!
>>
>> One of the benefits to the "one big tree" that we have right now is that
>> we guarantee to update your code as the standard library changes or
>> improves. This prevents bitrot and allows for some flexibility in changing
>> common words.  That matters less over time as the standard library becomes
>> more mature, but has been useful at times.  We've wanted ``extra/`` to be
>> very very easy to contribute to as a way of supporting new contributors and
>> then involving them as we keep an eye on their code.  Obviously there are
>> drawbacks to this approach too...
>>
>> Of course people can have their own repositories, and we should support
>> them as best we can (like support for adding vocab roots or through a
>> package manager), but I always want to encourage contributions when it makes
>> sense for everyone.
>>
>> Having something simple that encourages re-use of code is pretty great, we
>> could probably share our testing infrastructure to support easy continuous
>> integration for a project developed this way.
>>
>> More to come later when I have time.
>>
>> Best,
>> John.
>>
>>
>>
>> On Wed, Dec 17, 2014 at 6:20 AM, Andrea Ferretti
>>  wrote:
>>>
>>> Hi, following this [small
>>> discussion](https://news.ycombinator.com/item?id=8750720) I thought I
>>> might give a try at designing a simple package manager.
>>>
>>> It is inspired by [Metacello](https://code.google.com/p/metacello/)
>>> but delegates to existing source control management software such as
>>> git the actual handling of repositories, similar to
>>> [Bower](http://bower.io/).
>>>
>>> You can find the stub of a package manager
>>> [here](https://github.com/andreaferretti/factor-packages) (keep in
>>> mind: this is just the work of a day, and I am still a beginner).
>>>
>>> Outline
>>> ---
>>>
>>> The central concept is that of a *project*. A project has a name and a
>>> version, and contains some vocabularies. It can also depend on other
>>> projects. There are syntax words to define the structure of a project,
>>> which currently look like this (for a hypothetical project):
>>>
>>>
>>> USING: packages.syntax
>>> IN: example-project
>>>
>>> PROJECT: example
>>>
>>> VERSION: 0.2.0-alpha
>>>
>>> VOCAB: example.thrift
>>>
>>> VOCAB: example.main
>>>
>>> DEPENDENCY: thrift
>>>   GITHUB{ "factor" "thrift" "0.2.5" }
>>>
>>> One can then do the following in the listener
>>>
>>> IN: scratchpad
>>> USE: packages.projects
>>> "example-project" activate
>>>
>>> This clones the repository for each of the dependencies in a subfolder
>>> of "resource:cache" and switches to the given version. It is expected
>>> that each dependency contains a toplevel file `project.factor` as
>>> above. Then, transitive dependencies are recursively fetched.
>>>
>>> After fetching all dependencies, the vocabulary roots are adjusted,
>>> and finally all vocabularies mentioned in the project or in a
>>> dependency are `require`d.
>>>
>>> If you import the package manager in your work folder, you can see a
>>> [simple
>>> example](https://github.com/andreaferretti/factor-packages/blob/master/packages/example/example.factor)
>>> in action. Just do
>>>
>>> IN: scratchpad
>>> USE: packages.projects
>>> "packages.example" activate
>>>
>>> You will then be able to use, say, the `monoid` dependency, like this
>>>
>>> IN: scratchpad
>>> 3 5 |+|
>>>
>>> I would like to get feedback on the above design, so as to understand
>>> if it is worth the effort to develop this into something actually
>>> usable. While very simplistic, I think this approach has a couple of
>>> advantages:
>>>
>>> * it does not require any change to the Factor vocabulary system
>>> * by exploiting exi

Re: [Factor-talk] A stub of a package manager

[mr wzrd]

On 12/17/2014 09:20 AM, Andrea Ferretti wrote:

Hi, following this [small
discussion](https://news.ycombinator.com/item?id=8750720) I thought I
might give a try at designing a simple package manager.

Neat idea.

One of the benefits to the "one big tree" that we have right now is 
that we guarantee to update your code as the standard library changes 
or improves.


Regardless of whether a package manager is necessary or proper at the 
moment, it demonstrates that the complex trappings of modern software 
can be implemented in our "simple" stack-based-language.


  - mrw

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] A stub of a package manager

[Jon Harper]

Is a DSL better than a standard configuration data format ?

For example, I worked on yaml serialization/deserialization  (
http://docs.factorcode.org/content/article-yaml.html) because jckarter was
using it in https://gist.github.com/jckarter/3440892 so now this is
available.
Jon

Jon

On Wed, Dec 17, 2014 at 7:13 PM, mr wzrd  wrote:
>
>  On 12/17/2014 09:20 AM, Andrea Ferretti wrote:
>
> Hi, following this [small
> discussion](https://news.ycombinator.com/item?id=8750720) I thought I
> might give a try at designing a simple package manager.
>
>  Neat idea.
>
> One of the benefits to the "one big tree" that we have right now is that
> we guarantee to update your code as the standard library changes or
> improves.
>
>
> Regardless of whether a package manager is necessary or proper at the
> moment, it demonstrates that the complex trappings of modern software can
> be implemented in our "simple" stack-based-language.
>
>   - mrw
>
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] A stub of a package manager

[Andrea Ferretti]

I thought to use factor itself, as most package managers I have seen use an
internal dsl for configuration (sbt, lein, bundler, metacello). Npm uses
json, which is both a separate language and valid js. The only exception I
know is maven.

Of course, using yaml would be fine for me as well. Another possibility
would be to avoid the syntax words and write configs with normal words. In
fact this works right now, but the required words are currently private.
Il giorno 17/dic/2014 19:41, "Jon Harper"  ha
scritto:

> Is a DSL better than a standard configuration data format ?
>
> For example, I worked on yaml serialization/deserialization  (
> http://docs.factorcode.org/content/article-yaml.html) because jckarter
> was using it in https://gist.github.com/jckarter/3440892 so now this is
> available.
> Jon
>
> Jon
>
> On Wed, Dec 17, 2014 at 7:13 PM, mr wzrd  wrote:
>>
>>  On 12/17/2014 09:20 AM, Andrea Ferretti wrote:
>>
>> Hi, following this [small
>> discussion](https://news.ycombinator.com/item?id=8750720) I thought I
>> might give a try at designing a simple package manager.
>>
>>  Neat idea.
>>
>> One of the benefits to the "one big tree" that we have right now is that
>> we guarantee to update your code as the standard library changes or
>> improves.
>>
>>
>> Regardless of whether a package manager is necessary or proper at the
>> moment, it demonstrates that the complex trappings of modern software can
>> be implemented in our "simple" stack-based-language.
>>
>>   - mrw
>>
>>
>>
>> --
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> ___
>> Factor-talk mailing list
>> Factor-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/factor-talk
>>
>>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk